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

WordPress Trac noreply at wordpress.org
Wed Dec 4 05:13:01 UTC 2024


#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 dd32):

 Replying to [comment:35 jorbin]:
 > I think any autoloader needs to make it so that files can not be
 overloaded and if that's not possible, this ticket should be closed as
 `wontfix`. Allowing extenders to override core files means:

 I think those are very reasonable concerns to have, however, I disagree
 that it's a blocker to this moving forward.

 There are a lot of things you '''can do''' in WordPress that is not
 recommended, supported, or otherwise guaranteed to work.
  - Filters often completely change the behaviour of core
  - actions can be completely unhooked (Or having a custom function hooked
 earlier)
  - `pre_*` filters allow you to run something entirely unrelated to the
 original function
  - Pluggable functions exist that change the behaviour of the function
 entirely ''(And can't be filtered, and can only be overridden once per
 request)''
  - Pluggable Classes - Examples are `WP_Site_Health`, `WP_Debug_Data`, and
 `WP_REST_Posts_Controller` through `rest_controller_class`.

 Plugins & Themes likewise have free reign over the disk and database, they
 can install drop-ins that override core functionality (object-cache.php,
 db.php), they can alter PHP files on disk, they can add a backdoor to the
 site.  Of course, they shouldn't.

 None of those things has ever been a reason for why we shouldn't add an
 action or filter to a function, why should it be a blocker for this?

 `_doing_it_wrong()` and `Warranty Void!` phrases are commonplace for code
 that doesn't play ball with WordPress.

 Instead of just saying "That's dangerous! A plugin might do something
 silly!" I think it should be rephrased as "How can we mitigate any future
 issues caused by this?".

 One shortcoming that immediately comes to mind with the current
 autoloader, is that it only allows for wholesale-replacement of a class,
 it's not possible to extend the core class in any way. That's potentially
 dangerous, as it requires whatever has decided to replace the core class
 with it's own to keep up-to-date. We've already experienced this problem
 with WP_Object_Cache and wpdb.

 For example, I don't see how I'd be able to "replace" the `WP_Locale`
 class without duplicating the entire class. To make it safer, I'd prefer
 to be able to do something like..
 {{{#!php
 class WP_Locale extends WordPress\WP_Locale {
   .... add my specific functionality and inherit core ....
 }
 }}}

 That could be implemented by namespacing classes, and adding a class_alias
 to the file for back-compat.
 {{{#!php
 namespace WordPress;
 class WP_Locale {
   ....
 }
 // Export the class to the global namespace.
 if ( ! class_alias( 'WP_Locale', '\WordPress\WP_Locale' ) ) {
     // Keep a record of replaced classes.
     $overridden_classes[] = 'WP_Locale';
     _doing_it_wrong( 'WP_Locale has been overridden' ); // This probably
 isn't needed, but is included for example purposes.
 }
 }}}

 Even without tracking what classes are overridden, you could use that to
 detect replacements ''if needed''.
 {{{
 if ( ! ($wp_locale instanceof WordPress\WP_Locale) ) { ... }
 }}}


 Of course, I feel like it would be 100% appropriate that no plugin/theme
 hosted on WordPress.org would be allowed to replace a core class like
 this, except for those who are flagged as a special edge-case, ie. those
 that have been opt'd in to it.

 tl;dr: I don't see this as necessarily a bad thing that classes can be
 "overridden" I consider it a feature even, it would just be nice to be
 able to maybe mitigate future problems by letting plugins extend classes
 rather than just replacing them, causing problems for others in the
 future.

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


More information about the wp-trac mailing list