Currently we have more or less 6 non-standard extensions to represent PHP files with. This is most certainly a Drupal-ism.
This issue proposes that PHP files should always have the extension: .php
Newcomers not only have to learn Drupal, they need to configure their IDE and/or OS to open a file with the correct program and get some syntax highlighting working. This is a DX win that makes drupal more out of the box accessible for development. (see #4, #18) And it helps us get off the island :)
Not all sites run on apache or IIS where we have config files to stop them from serving those files displayable directly to the browser. Many people store sensitive info in PHP files, like API keys, or passwords and we can’t add configuration files for every web server that currently exists (or ever will exist). (see #17)
As Crell points out (#20) PSR-0 mandates that classes end must end in .php for autoloader interoperability. Drupal is becoming more OO so most of the code will be in .php files. Why not all of the code?
We have thousands of modules, themes, and profiles on drupal.org and countless more bespoke modules on sites... every current Drupal developer will have to do things differently, and all the contrib projects with D8 branches will need to rename files.
Files with non-standard extensions are not executable and some people might rely on this behavior. (see #12, #67 and below)
We have two options...
In order to proceed with option 2 we have to complete
#1292284: Require 'type' key in .info.yml files →
See #28
Update: There seems to be a clear consensus for Option 1.
Bulk renaming files in a directory using bash:
for f in $(find . -name "*.module" -o -name "*.profile" -o -name "*.theme" -o -name "*.install" -o -name "*.inc" -o -name "*.engine"); do mv $f ${f}.php; done
There shouldn't be .inc files.
.inc.php is better since webservers won't allow users to view their content.
Just in case someone modifies one with confidential information.
Active
11.0 🔥
extension system
Enhances developer experience.
It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I think am easier way around this is to deprecate and replace the things inside the files.
.module has very few things that are required in it. We can make this oop then just deprecate .module entirely.
Crediting discussion from #243, although this issue seems to keep coming back from the grave.
📌
Road to deprecating .module files
Active
has us a lot closer, but still leaves .install, plus themes and profiles.