Giters

roots / wordpress

Automatically updated WordPress Composer package

Home Page:https://roots.io/composer-wordpress-resources/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

RFC: roots/wordpress package switching the "no-content" WordPress release

swalkinshaw opened this issue · comments

commented

Existing issue: #3

This is an RFC, and proposal, to change the roots/wordpress Composer package (defined by this repository) to contain the "no-content" WordPress release which means none of the default themes will be included.

Currently, roots/wordpress uses the releases from https://github.com/WordPress/WordPress which includes all default themes. There's a few downsides to this:

  • WordPress' site health flags - "Have a default theme available" is marked as critical
  • it's wasteful and inefficient to include all the default themes when they almost always won't be used

However, making this change is a breaking change as consumers of roots/wordpress might be relying on a default theme being included.

Release plan

We plan to use the release of WordPress 6.0 as a natural point to make this breaking change. The published version of roots/wordpress for 6.0 will use the "no-content" WordPress release without any default themes included.

In the spirit of Bedrock, any default theme can be included by adding it as an explicit dependency via WordPress Packagist packages:

"require": {
   "roots/wordpress": "6.0",
   "wpackagist-theme/twentytwentytwo":"*"
},

Implementation

Right now roots/wordpress is built from GitHub workflows in this repo. We're going to (finally) be switching to https://github.com/roots/wordpress-packager and using @LeoColomb's improvements to let us build multiple versions of the package, including switching roots/wordpress to the no-content version.

As an added bonus, we can remove Bedrock's register theme directory mu-plugin

cc @LeoColomb @roots/everyone

commented

I can only support the switch to the "no-content" variant, which is a really good idea. 👍

That said I'd like to express few concerns on the plan:

  • The breaking change at roots/wordpress level will not be easy to manage, and might be quite unexpected.
    • It removes all bundled themes (as well as Hello Dolly plugin but this one is safe to remove I guess).
  • Keeping a single repo for this change can be confusing:
    • 6.0 might not even be a "major" version from WordPress POV, I mean more major than 5.9 for example.
    • Even if 6.0 is considered as semver-major for WordPress, there is no way to express the breaking change from roots/wordpress perspective.
    • Package consumers might quite hardly understand why it happens, and if and how it is possible to keep coherent deployment.

My suggestion would be to create another package for the new variant.
Eventually do the same for all variants to offer the ability to chose to the consumers, especially because some variants can support beta/RC builds effortless, making them perfect for testing.

Detaching these packages into another organisation might be handy to do that, eg. like @composer-wordpress (disclaimer: I'm the maintainer of this org).
This can help to build a proper documentation, to easily (and securely) use the build script, and be more robust for next breaking change. 😎✨

Thoughts? 😊

commented

The proposed plan wasn't using 6.0 because it signified any major version (in terms of semver). It was mainly just an arbitrary big milestone we could point to in the future.

Detaching these packages into another organisation might be handy to do that, eg. like @composer-wordpress (disclaimer: I'm the maintainer of this org).

Disclaimer: there's obviously a bit of selfish bias and motivation for us wanting to keep it under roots/wordpress which we'll admit first.

However, I think moving to another org/package would just increase confusion instead of clarifying the situation. Since roots/wordpress would remain heavily used regardless of us suggesting a new package.

So I think the main decision point is keeping roots/wordpress as is (with content) and introducing a new roots/wordpress-no-content package. Or the plan outlined in this issue originally.

I think we all agree that making this breaking change isn't 100% ideal, but it might be worth the possible breakage because it's the proper long-term solution?

I'm also wondering if there's any other Composer features we could take advantage of to make this plan work better. Maybe we could add a suggest package for wpackagist-theme/twentytwentytwo and leverage the message to include some information about the migration?

commented

I feel that while we should make every effort to ease a transition, at the end of the day if you (the end consumer) bump up a major version on a package and don't have some level of testing to make sure it doesn't explode that's on you--the intent of the ecosystem is that it allows you to specify versions in a very granular way so that you can be safe and careful about managing them. Whether or not WordPress adheres to semver isn't necessarily the point: We do, so a major version bump is a clear signal to the user that they should expect things to change. If you chose not be be careful and take advantage of that system, you're kind of on your own because we can't predict (or be expected to account for) your behavior.

I'd prefer roots/wordpress to be the "canonical" version--the one we approve of--but we might consider setting up additional repos like roots/wordpress-themes or roots/wordpress-full and then using the suggest Composer field to point them out to folks. Those repos would in turn use the provide or replace field to point to roots/wordpress, theme repos, etc.

A potentially extreme solution but one that would potentially have the most visibilty would be to move to different repo entirely, i.e. roots/wp and then set the abandoned field on roots/wordpress, pointing people to roots/wp.

commented

Whether or not WordPress adheres to semver isn't necessarily the point: We do, so a major version bump is a clear signal to the user that they should expect things to change.

The roots/wordpress package versions match the WordPress release versions though so unfortunately we can't follow semver either because they don't.

commented

Fair, although I feel that the larger argument (managing versions and checking that they work is the responsibility of the end user) is still valid. Since suggest allows a message along with the recommended packages, we might consider adding a suggest message along the lines of

"suggest": {
  "roots/wordpress-full": "roots/wordpress will be removing themes starting with version 6; to include themes in your dependency use roots/wordpress-full instead"
}
commented

As for next steps, I think we should publish two new packages now in advance:

roots/wordpress-full

Same as roots/wordpress right now, will continue to exist after if people prefer the full version.

roots/wordpress-no-content

This will become the same as roots/wordpress after the breaking change. This also means we'd have two identical packages with different names long-term so this one is debatable? The package description would make it clear what each one is though.

@LeoColomb what do you think?

commented

This looks to be a good plan! 👍

This also means we'd have two identical packages with different names long-term so this one is debatable?

This is debatable indeed.
One option (my favorite 😄) would be to mark roots/wordpress as obsolete after some time and without switching it to no-content content.
This will force roots/wordpress consumers to select an option without introducing an unexpected policy change.
Bonus: that avoid maintaining a duplicated package. 😊

commented

Any timeline on when we can get a first release on this?

With the new packages -full and -no-content there's not really anything tying you to a major upstream milestone anymore. The sooner the better IMO :)