Use modern PSR-4 autoloading

[szepeviktor]

While writing a WPCS-compliant autoloader today I've realized how beneficial PSR-4 is! https://github.com/szepeviktor/debian-server-tools/blob/856dfc4e19a0cbb39103e1e442ce7f8e73de7989/webserver/wp-install/wordpress-autoloader.php

Please use PHP 5.3 compatible namespaces and class autoloading. See for example WooCommerce.

[raaaahman]

Hello @szepeviktor , we had the starting of a conversation about it during August 24, 2020 Office Hours. Let me give you a recap:

schlessera: So the function could stay global, but all the OOP implementation would be cleaner in a namespace WP\Notifications. Also, I'd suggest assuming the presence of an autoloader, at least during development when everything is still in flux. You can always add hardcoded includes later on if they are needed for a Core merge, but using an autoloader makes development faster and easier.

aristath: I don't think there's lots that will need done for php5.6... If we don't go with namespaces then it's minimal changes. And tbh I'd be hesitant to go with namespaces 'cause chances are it will be a waste of time and we'll be asked to remove them later on

Could we think of a classmap based autoloader for development purposes?

(Also, could you please change the issue's title to something more specific about PSR-4/autoloading, as there are other PHP features to be modernized as well. I recall @schlessera mentions 'variadic arguments' ...)

[szepeviktor]

I know - I know: namespace is strange to a WordPress user/developer.

[jonathanbossenger]

I'm going to play devil's advocate here, not because I don'[t want to see this, but because we need to remember that eventually, this needs to be mergable into WordPress core, where we may not have the ability to use an auto loader.

So as long as what we build can easily be replaced if needed, I'm all in

[jonathanbossenger]

I know - I know: namespace is strange to a WordPress user/developer.

I would also add that one of the goals of this project is to introduce these concepts to the WordPress world, so we might need to take a "baby steps" approach.

[johnhooks]

@Sephsekla rather than create a new issue, picking up where this one leaves off shows there is an history of support for refactoring to use namespaces and autoloading.

Can this please be added to the project board? Also can we add a tag for "Coding Standards"?

Edit: @Sephsekla before you do that, read the next comment, and let me know you opinion.

[johnhooks]

As I'm looking through the existing php code and file structure, to use PSR-4 autoloading the file structure and file names are important and should match the namespace structure.

If the goal is for this to be adopted by core, as sad as I am to say it, I think we shouldn't go down the PSR-4 autoloading route. I am considering how this would integrate into core, specifically the REST controller (I'm working on that now), and if it is to be eventually in the /wp-includes/rest-api/ folder of a WordPress install, it seems like a tall order to convince core to have a single controller be different from the all others a use namespaces rather than prefixes.

[johnhooks]

I heard of the possibilities of adding plugin dependency management to WordPress. If that is the case, it could be the path to using new PHP techniques along side core. Even if the functionality of this plugin were adopted by core, perhaps it would just become a listed dependency, and this project can use a different file structure, PHP namespaces, and PSR-4 autoloading.

CC: @Sephsekla @erikyo

[Sephsekla]

@johnhooks honestly I only ever use composer for plugin installation these days, it frustrates me that WP hasn't adopted it wholesale. I'd be interested to see if we can implement autoloading, but it's also something we can update down the line.

[johnhooks]

It frustrates me that WP hasn't adopted it wholesale.

It is odd.

@Sephsekla I'm trying to figure out what style of code I should be writing. Should it use namespaces or prefixes? Should the file structure be compatible with PSR-4 or not?