[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