[wp-trac] [WordPress Trac] #60414: Core PHP autoloader proposal

[WordPress Trac]

#60414: Core PHP autoloader proposal
-------------------------------------+-------------------------------------
 Reporter:  aristath                 |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  General                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-unit-      |     Focuses:  performance,
  tests early                        |  sustainability
-------------------------------------+-------------------------------------

Comment (by aristath):

 Are we saying that we don't want to do something in WordPress Core,
 because there's a ''possibility'' a plugin ''might'' do something bad?
 Plugins already have access to the filesystem and the database. They can
 already do whatever they want. They can even overwrite Core code and
 classes if they want - as demonstrated in a previous
 [https://make.wordpress.org/core/2024/02/01/proposal-implement-a-php-
 autoloader-in-wordpress-core/#comment-46192 comment in the make post].

 Thankfully, we have rigorous plugin reviews that guard the community
 against such things and malicious behaviors.
 It would be relatively easy to add an automated check to the plugin-
 checker, and simplify checking for plugins overriding a Core class.

 We can't prevent bad things, but we can warn users if we detect a plugin
 doing something we consider bad. With that in mind, this
 implementation/PR/patch includes a new check to the health screen,
 throwing a critical security issue in case a plugin does something like
 overriding a Core class.


 > 1) Core can't rely on functionality existing from one version to another
 in a different file. This will cause sites to break on upgrade.
 > 2) Since a core file can be overridden once, it makes it harder for
 multiple plugins to extend the same functionality.

 If a plugin does something bad, it can break a site. OK... How is that
 different from what we have now? To quote a
 [https://make.wordpress.org/core/2024/02/01/proposal-implement-a-php-
 autoloader-in-wordpress-core/#comment-46143 comment] from @joostdevalk,
 "''That’s like not going from petrol to electric cars because you can
 still have an accident with an electric car.''"
 Plugins breaking on Core update, or breaking each other, is nothing new.
 It's the de-facto reality of any open system like WordPress. As long as
 people build plugins, there will always be a chance they'll do something
 wrong.
 We can limit the possibility by not allowing plugins on .org to override
 Core classes.
 We can guard users by throwing a critical security warning when we detect
 such behavior so they are aware of the danger of the plugin they're using.
 What we can't do, is change the reality that if someone wants to do
 something bad with WordPress, they'll do it - especially since they
 already have access to the filesystem & db.

 > 3) Instead of encouraging collaboration and making WordPress better,
 plugins will just override core files to fix a bug they are facing since
 it will be easier for them.

 That's not going to happen for plugins hosted on .org. For non-org
 plugins, there's no way to check what they do, and as I mentioned above,
 they can already do whatever they want - including overwriting Core
 classes.
 If a developer feels that they can't collaborate or contribute and they
 resort to releasing a plugin not hosted on .org, then that won't be
 because we added an autoloader... It will be because we've made
 contributing and collaborating an unpleasant and hostile experience.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60414#comment:41>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform