Drupal 10 is released and let's take the opportunity to clean up a bit this module. Drupal 10 already supported on 2.6 but the plan remains the same.

Proposal

Must-have

  • ✅ Include Current RTBC and To review issues to codebase. Zero critical issues.
  • ✅ Make Drupal 10 compatible, of course - Project Update bot already identified some changes but there's still some handmade work to be done.
  • ✅ Remove EditorsKit experimental module - This module never got updated and not sure of its usage. If enough interest we can move it to a separated module and maybe try to update the library.
  • ✅ Remove Gutenberg Cloud module. It had potential but patterns made the library of blocks kind of obsolete. Again, we can move to a separated module if enough interest.
  • ✅ Update Example block module - Update it's code and dev tools. Add more examples with top documentation 😉.
  • ✅ Drop Drupal 8.x support. Minimum requirements: 9.4.x (maybe 9.5.x). D9 has reached EOL.
  • ✅ Change version semantics - Next version: 3.0.0!
  • ✅ Full support for Claro admin theme and Olivero frontend theme.
  • ✅ Remove specific configuration, styles and alters for Seven and Bartik themes. If 9.x is supported then we need to keep support for those themes. D9 EOL
  • ✅ New version of Gutenberg library. #3334499: Update Gutenberg library

Please, give your feedback regarding this proposal or if you would like to propose more stuff.

Comments

marcofernandes created an issue. See original summary.

marcofernandes’s picture

marcofernandes commented
Issue summary: View changes

szeidler’s picture

szeidler
Primary language German
Location Berlin
commented

I guess it depends a bit on the timeline. Should 3.0.x be the only Drupal 10 compatible release?

I would love to see "Entity agnostic" in the release. Not necessarily because of "Entity agnostic" itself, but codebymickey has invested quite a lot of work in general improvements for configuration and UI in that branch. Realistically speaking: When we cannot land this in 3.0.0 it probably needs to wait for 4.0.0, because the changes are so massive.

In general I'm onboard with your proposal.

marcofernandes’s picture

marcofernandes commented
Issue summary: View changes
marcofernandes’s picture

marcofernandes commented

The version major bump is mostly because we're dropping those sub-modules, especially Gutenberg Cloud.

Should 3.0.x be the only Drupal 10 compatible release?

I believe it's best. 8.x-2.x could be updated to be compatible with 10 but probably that would mean more maintenance - if anyone is up to it, I won't oppose 😉.

Entity agnostic: I also really want to have this on 3.0.x. Already check the merge issues and, with some patience 😅 probably it can be done for 3.0.x. Let's see.

thorandre’s picture

thorandre commented

Removing Gutenberg Cloud might be something we could ask the community about. Should we create a separate issue to make it more visible maybe? I assume we only know those using cloud that is contributing back, and not much about general usage?

jidrone’s picture

jidrone commented

Hi everyone,

Nice plan, I agree removing the other modules, personally I'm not using them.

Maybe we can focus on the Must Have improvements and leave the other ones for later releases, I don't know the progress on the entity agnostic issue, but I will start testing this branch in a D10 site, so let me know the priorities and I can help.

I think you can push this 3.x branch to allow the people to install it via composer.

adiatis’s picture

adiatis
Primary language Dutch
Location Belgium
commented

Is 3.x branch ready for Drupal 10 development and give a try?

ejseguinte’s picture

ejseguinte commented

I noticed the 3.0.x branch is using Gutenberg Version 14. Does that mean we might get access to adding media items from the link menu? I believe that was merged in for Version 13.

https://github.com/WordPress/gutenberg/pull/39701

I also noticed the 3.0.x branch is requiring PHP 7 still.

jidrone’s picture

jidrone commented

Hi everyone,

I was using the version 3.0.0 on a site I'm developing, so far everything have been working ok.

I still suggest to create the 3.0.x release for us to be able to continue testing, also if you agree we can add child issues for the remaining things so that we can contribute.

Thanks.

marcofernandes’s picture

marcofernandes commented
Version: 8.x-2.x-dev » 3.0.x-dev

@jidrone
I agree. I added a 3.0.x release and let's try to keep all 3.0.x issues as child of this one for now, at least until a stable release.

@EJSeguinte
We'll try to support the new features as much as possible. Although I guess any new feature related to media will require extra work due to Media/Media Library integration (which is something that I really wanted to simplify in terms of implementation 😁).

marcofernandes’s picture

marcofernandes commented
Issue summary: View changes
marcofernandes’s picture

marcofernandes commented
Issue summary: View changes
deg’s picture

deg commented

Great plan! Having a more modern version of the Gutenberg library would be huge for us!

batonac’s picture

batonac commented

While you're doing refactoring, how about building this module using the NPM @wordpress/block-editor and associated packages directly, instead of a custom build scripts? Ideally, this might help smooth the transition between Gutenberg library releases.

ken hawkins’s picture

ken hawkins commented

What's need in terms of support to help further the 3.x development?

juc1’s picture

juc1 commented

Remove Gutenberg Cloud module. It had potential but patterns made the library of blocks kind of obsolete

I am just starting to use Gutenberg so @marcofernandes or anyone does this mean I should not use the Gutenberg Cloud module?

sashainparis’s picture

sashainparis
Primary language French
Location Provins
commented

Short answer: yes.

Long answer: it can be easily adapted to be a generic module that could be used in a controlled perimeter domain-oriented. On a dedicated package server with the right description format.

But: in between, patterns appeared to be a better way and cloud approach is limited to actual Gutenberg blocks. Which should be used only when you couldn't do the job with patterns.

In other words: You will use modules to declare a new block. And you will prefer composer to manage the reuse in your domain.

This is also true at community level through contributed modules. The main difference is: You wouldn't need to trigger a new delivery to make it available.

So: great architecture, but not the list optimized approach from a maintainability point of view.

Hope it helps a little bit.

marcofernandes’s picture

marcofernandes commented
Issue summary: View changes

marcofernandes’s picture

marcofernandes commented

Finally we have a beta release https://www.drupal.org/project/gutenberg/releases/3.0.0-beta1
There's still some tasks to be done from the list on the description and also we need to deal with some issues that are ready to commit to 2.x (merge to 3.0.x).
One thing that I what to move forward is the entity agnostic feature. I've checked Layout Builder implementation and I think it's simpler than what we have and it would cover any content entity without any configuration. I know codebymickey invested a lot of time implementing that feature but, even if we opt for a different implementation, definitely we'll re-use a lot of that work. Let's see.

marcofernandes’s picture

marcofernandes commented
Issue summary: View changes

thorandre credited eiriksm.

thorandre credited helderm.

thorandre credited vegardjo.

thorandre’s picture

thorandre commented
Issue summary: View changes

Closing this! Yay! All done and released. Thank you all for contributing! 🎉

thorandre’s picture

thorandre commented
Status: Active » Fixed
drclaw’s picture

drclaw commented

This is amazing! 🤩 Great work!! 🙏

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.