Make WordPress Core

Opened 6 years ago

Last modified 6 months ago

#48962 new enhancement

Start using namespaces in Core

Reported by: taraschr's profile taraschr Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: General Keywords: dev-feedback 2nd-opinion
Focuses: Cc:

Description

After moving WordPress minimum PHP version to 5.6 with plans for 7.x there was a big reason to upgrade core to modern PHP-development approaches.

The biggest advantage of namespaces is autoloading. Nowadays many plugin developers using Composer or their own autoloaders in every plugin. Some part of developers just "include(_once)" everything. And Composer is more preferable solution.

But it is a big problem. Many plugins are using their local directory autoloader/composer. And that can be easily solved by using Composer in WordPress distibution. Composer can simplify work with dependecies and plugin updates or even WordPress updates.

I don't think that WordPress need own autoloader when in PHP-world exists de-facto standard in face of Composer. But it is just my personal opinion.

There are no extraordinary problems to upgrade code to namespace basis. It can be done by some script. To avoid BC changes we need just use \class_alias() for namespaced classes to make copy in global namespace. Old class-files can be marked as deprecated.

Change History (7)

#1 @taraschr
6 years ago

  • Keywords dev-feedback added

#3 @callumbw95
6 months ago

  • Keywords 2nd-opinion added

Hi everyone,

After reviewing this ticket, the path forward is clear. I think we can all agree that using namespaces has been a great change within PHP and implementing this would be a great way to modernize WordPress' code stack.

However, I don't believe we can simply change all the old functions, as doing so could potentially break millions of sites, and protecting backward compatibility is a top priority. This change would also create a very clear divide between themes and plugins that work with the current set up, and those that would only work with namespaces.

Therefore, from my understanding, the established plan is:

  • Existing Functions: All current functions will remain as they are to ensure sites don't break.
  • New Code: Namespaces should be used for new, self-contained features going forward, and we have seen a rise in this in various components within WordPress.

I am not sure what else, if anything can be done on this ticket as this feels more like a discussion piece as opposed to an actionable task at this stage, but it would be good to get more feedback from others in the community as well as from the core team. 😃

This ticket was mentioned in Slack in #core by benjamin_zekavica. View the logs.


6 months ago

#5 @dmsnell
6 months ago

Related: There’s discussion in PHP about prefixing all global-namespaced function calls in an effort to improve the language performance when dealing with namespaces.

That is, should every call to global functions be like \get_post() rather than get_post() (without the leading backslack).

https://wiki.php.net/rfc/global_function_parser_directive

#6 @jorbin
6 months ago

@dmsnell Looking through the discussion on that RFC, I am not confident it is going anywhere any time soon. There is also a previous RFC that is related which was declined.

#7 @taraschr
6 months ago

The OP is still here 😃
I would say it is not a BC change for the core by itself.

I've revisited my proposal, and I believe the better approach is to create existing functions and classes aliased in namespaces (e.g., a PSR-4 compatible structure) and then gradually start migrating the internal codebase to namespace-based functions and classes, leaving the old ones as a global fallback.

Such an approach would allow us to avoid critical BC changes.

Note: See TracTickets for help on using tickets.