Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why are there PHP files in the JS packages on npm? #33241

Open
azaozz opened this issue Jul 7, 2021 · 6 comments
Open

Why are there PHP files in the JS packages on npm? #33241

azaozz opened this issue Jul 7, 2021 · 6 comments
Labels
npm Packages Related to npm packages [Type] Enhancement A suggestion for improvement. [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes. [Type] Question Questions about the design or development of the editor. [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked.

Comments

@azaozz
Copy link
Contributor

azaozz commented Jul 7, 2021

Been wondering about this for a while. Seems these PHP files were added as a "quick fix" during the first merge of Gutenberg to WP 5.0, but not sue anybody has ever looked at "how to" and "why" since.

As far as I see it is not a good idea to (auto)add PHP code from the Gutenberg plugin to core as some of that code serves a bit different purpose in the plugin. There are certain, sometimes significant differences when a function or a class is included in core compared to when it is added by a plugin. For example a plugin may want to be backwards compatible with previous versions of WordPress, etc. Such code would be "dead" in core.

I understand some of that PHP code is generic and may be needed by third parties. Perhaps those files are okay to include in the packages, as long as they are not WP specific. On the other hand WP specific PHP code, especially code that is needed for the plugin to work in older WP versions, should not be part of the npm packages. It is useless for third parties and not suitable for core. Seems such "compatibility" PHP code should be in /lib and loaded conditionally on the WP version or function_exists(), etc.

@azaozz azaozz added [Type] Enhancement A suggestion for improvement. [Type] Question Questions about the design or development of the editor. [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked. [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes. npm Packages Related to npm packages labels Jul 7, 2021
@gziolo
Copy link
Member

gziolo commented Jul 7, 2021

It's the simplest way to keep the PHP files for core blocks in sync with WordPress core:
https://github.com/WordPress/wordpress-develop/blob/73e24c997c1182ac48856c1546cf4719b51ae27d/tools/webpack/packages.js#L174-L181

The thing is that all core blocks that contain PHP code can be used only in the context of WordPress. We can always extract all general blocks that work in the standalone block editor like Paragraph, Heading, List, etc.

The only exception is @wordpress/block-serialization-default-parser/parser.php that could be as well moved to the WordPress core and maintained there.

@azaozz
Copy link
Contributor Author

azaozz commented Jul 7, 2021

It's the simplest way to keep the PHP files for core blocks in sync with WordPress core

Yeah, on first look it seems that way. Looking a bit more, what happens when the (PHP) code needed for the Gutenberg plugin is different from the code needed for core? Who "wins", the plugin or core? :)

There have been few related bug reports recently:
https://core.trac.wordpress.org/ticket/53610
https://core.trac.wordpress.org/ticket/53410
https://core.trac.wordpress.org/ticket/53432

Seems that for now the plugin "wins". That benefits some of the ~300,000 plugin users, but may cause errors or is "dead code" for the (potential) ~60,000,000 WP sites. Don't think it is a good solution, and it looks like there will be more and more similar cases in near future.

There seem to be two options to improve that:

  1. Stop including the PHP files in npm packages and merge them "by hand" if/when there are any updates. That will allow removal of the dead code and other adjustments that may be needed when moving PHP code from a plugin to core.
  2. Ensure that all the PHP that is included in npm packages is strictly intended for the current core trunk. That may make some of these files not usable in the plugin. In these cases any compatibility code should go in /lib.

There are some other concerns too. Newer version of the plugin running in older version of WP would probably work properly. However older version of the plugin in a newer version of WP may run into difficulties and/or conflicts with other plugins.

One way to try to prevent such problems before they happen would be to never use in Gutenberg the PHP files that are intended for core and are included in the npm packages. Instead, when the plugin is released, all the PHP needed for it should be "forward-compatible" with fewer versions of the code that may already be loaded and preferably be in /lib.

@youknowriad
Copy link
Contributor

Thanks for raising this, I think it's an important subject that deserves some improvements. Personally, I think we shouldn't stop sharing files, I think we should actually share more files. If you've been involved with backports to WordPress you know how much painful non-js painful are already and stopping the blocks from sharing their code will just make it worse.

That said, I think it's be good to find better alternatives to what we already do, and for me there's another alternative worth that wasn't mentioned ... packages (like in php packages) :)

Backporting JS packages automatically has been working great for some time now, why not do the same for php ones. Organising the php code in packages forces the developer to think about third-party (aka core) usage and not just the usage in the context of Gutenberg, meaning the code could become more reusable and easier to integrate. (Not everything need to be a package though in php obviously)

For me there are things that could clearly be easily shared without too much effort:

  • block server-side registration and rendering.
  • block supports.
  • block patterns.
  • REST API endpoints.

Historically, WP didn't load any external php package to its code base and it might be an issue but why not start with WP's own packages.

@oandregal
Copy link
Member

I'd like to share a use case that would benefit greatly from an improved mechanism to reuse PHP code across codebases: we have a piece of code to extract strings for translation from the theme.json file. It's the same in 3 different codebases: WordPress core, the Gutenberg plugin, and the wp-cli. Doing this copy over manually has proved very time-consuming to maintain and update.

@azaozz
Copy link
Contributor Author

azaozz commented Jul 11, 2021

backports to WordPress you know how much painful...

Yeah, it is in some cases. The pain mostly comes from the differences in the PHP code between core and the plugin.

packages (like in php packages)

Hmm, in theory packages should work, but there will be only one "consumer": WP core. As far as I see they won't be reusable in the plugin (in most cases), and some (many?) will be compatible only with a specific WP version. Wouldn't it be cleaner and easier to just commit them to core trunk?

there are things that could clearly be easily shared without too much effort

True, if the PHP code is quite generic, it may be possible to reuse it in different WP versions. However not in the plugin where "forward compat" will probably still be a problem in some cases.

improved mechanism to reuse PHP code across codebases...
...WordPress core, the Gutenberg plugin, and the wp-cli

Sharing that should work as long as the piece of code is generic and doesn't depend on other WP functions. At the same time if it exists in core, both the plugin and cli will likely be able to use it.

Doing this copy over manually has proved very time-consuming

Hmmm, copying and pasting of some code, testing it, and releasing it may be time consuming, but not sure there will be any significant difference if it was a package. The only thing would be that the code from the package is "copied" and "pasted" automatically. That would probably take no more than few seconds to do "by hand" :) Testing the changes locally and releasing the update is the bulk of the work.

WordPress had something like a package many years ago. The WP_Dependencies classes and functions were reused in couple more places as far as I remember. Eventually that was abolished as the changes needed for core were not needed elsewhere, and started to introduce bugs.

@azaozz
Copy link
Contributor Author

azaozz commented Jul 11, 2021

There are some other, more "drastic" options:

  • Merge the codebases. That would be ideal. Gutenberg is part of core, should be developed together with core. However seems that would be the end of the Gutenberg plugin. It will likely be even harder to extract new code from core trunk and release it as a plugin for previous WP versions.
  • Do not "merge" the Gutenberg code to core. Keep it organized as a plugin/separate component, in its own sub-directory. That would probably require some revamping of the way plugins work, and perhaps some "low level" changes that may be tricky.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
npm Packages Related to npm packages [Type] Enhancement A suggestion for improvement. [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes. [Type] Question Questions about the design or development of the editor. [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked.
Projects
None yet
Development

No branches or pull requests

4 participants