PSR compatibility

[fale]

The PHP-Fig have published lately 4 different PSRs:

• ​PSR-0 Aims to provide a standard file, class and namespace convention to allow plug-and-play code.
• ​PSR-1 Aims to ensure a high level of technical interoperability between shared PHP code.
• ​PSR-2 Provides a Coding Style Guide for projects looking to standardise their code.
• ​PSR-3 Describes a common interface for logging libraries.

I think WordPress should:

• Become a Voting Member of PHP-Fig
• Implementing all the PSRs.

The PSR1 and PSR2 can be partially implemented without breaking anything.
The PSR0 and the completition of PSR1 and PSR2 will need a breaking version, so a X.0 version can be a good moment (4.0 maybe?)

Even if the argument has already been touched in the ticket #21300, I think that a wider discussion was needed.

[rmccue]

PSR-0 would be nice, and can probably be done without breakage, but autoloading is not something that the core team wants to do for performance reasons (from memory). Also as nacin mentioned in #21300, we require PHP 5.2 which can have SPL disabled.

PSR-1 requires PSR-0, plus requires some major refactoring in places to avoid "Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both." (Such as default actions/filters). In addition, "Method names MUST be declared in camelCase" goes against the well-defined WordPress coding standards.

PSR-2 uses spaces instead of tabs, something I personally hate and something that goes against the WP standards. Likewise for braces and mostly everything. This is the least likely to get adopted.

PSR-3 is somewhat useless, since WP does no logging internally apart from the standard PHP error_log(). All errors are passed as WP_Error objects, similar to exceptions.

---

While it would be nice, and I'm the first to agree that WP shouldn't be a silo (I believe I'm the only active person on the PSR and php-internals mailing lists that can talk about WP), it's realistically not going to happen. Most of it would be against existing coding standards which WP developers are well aware of, and cause huge backwards compatibility breakage. I can see us moving possibly towards PSR-0, but the others don't seem like they're that useful.

It breaks my heart to say, but: not going to happen, so recommending wontfix.

[wonderboymusic]

WordPress is too far away from OO to even consider this, I don't think it's not necessarily a bad thing that it will never be like Java or one of the MVC libraries for PHP. Plus, let's say we did change everything to camelCase and move the opening brace down to the next line, we will have changed zero functionality and fixed zero bugs while dramatically altering the codebase and renaming every file and breaking the folder structure for anyone who had used it. For anyone who has a jones for this, fire up Symfony, right?

[nacin]

PSR-0: If/when we move toward SPL autoloading (which does not benefit us much right now, given WordPress is relatively small, procedural, and tightly-coupled), there is not a doubt in my mind that we would look at PSR-0 when doing so. Given that two-thirds of all WordPress sites run PHP 5.2 still, namespaces are not something I am wasting my time on considering how or if we will implement them.

PSR-1: Some of this is already applicable. We only use <?php and have no plans for <?=, because it can get turned off with short tags on servers until 5.4 (1% of all WordPress sites). We use only UTF-8 and avoid BOM. rmccue expressed difficulty in the side-effect guideline, but this is something we actually just naturally strive for anyway. (Moving a bunch of add_action() calls into default-filters.php isn't a big deal.) But, our coding style is underscores. We're never going to use StudlyCaps or camelCase. Like a number of FIG projects, there are simply going to be some coding and interoperability standards that we will ignore.

PSR-2: Most of this goes against our style guide and is not something we will adopt. Opening braces do not go on their own line. Tabs, not spaces, for indentation. We use spaces liberally, for function calls, control structures, and such.

PSR-3: Not applicable, as rmccue stated.

Some changes would significantly alter the shape of WordPress's codebase, and that's not something we care to do. Not just that, but many of these changes — including something as simple as StudlyCaps and camelCase — would be a backwards compatibility nightmare. We do not break userspace. When we do so (which, despite not having "breaking" versions, we do so rarely), we better have a damn good reason, and the PSRs aren't even close to it.

For the version number X.Y.Z, major is X.Y, while minor is Z. There is no difference between 3.9 and 4.0 and 4.1 — all are major versions.

[nacin]

I'm closing this out, though discussion is welcome to continue.

[rmccue]

Replying to nacin:

rmccue expressed difficulty in the side-effect guideline, but this is something we actually just naturally strive for anyway. (Moving a bunch of add_action() calls into default-filters.php isn't a big deal.)

Definitely, but there are places where we seemingly intentionally have those in the file next to the function (the various login functions come to mind). In addition, all of pluggable.php would break this rule.

We use spaces liberally, for function calls, control structures, and such.

Some would say too liberally. ;)

[lucasbustamante]

Hi,

It's been 6 years. How's this issue in PHP 7 era?

Best,
Lucas.

[desrosj]

Some changes would significantly alter the shape of WordPress's codebase, and that's not something we care to do. Not just that, but many of these changes — including something as simple as StudlyCaps and camelCase — would be a backwards compatibility nightmare. We do not break userspace.

I think that this sentiment still applies here. WordPress still supports PHP 5.2 (At least until April 2019), and will not raise the minimum version to 7.0 until at least December 2019 (​more information on that plan)

The main concern, though, is the massive backwards compatibility breaks that would be caused. WordPress is still committed to backwards compatibility as much as possible.