Make Gutenberg entity-type-agnostic

Honestly, on all projects I've worked that used Gutenberg, I never found a necessity to use the editor on other entity types besides node. But, I guess, there could be some edge use cases.
I agree with the proposed resolution, just regarding:

Introduce a new Gutenberg setting which allows admins to specify the text field to use for Gutenberg rather than defaulting to the first text field.

It should always default to the first text field and give an option to change it.

The use case is compatibility with https://www.drupal.org/project/eck

Why doing this on a per entity setting rather than on a per field configuration, if anything is needed?

Isn't a text input format enough?

As far as use cases go, a basic one would be using Gutenberg on Taxonomy Term pages.

For us, we're hoping to use this on Group entities.

I've pushed some code to the 3163200-make-gutenberg-entity fork. These changes include:

1. Adding hook_gutenberg_entity_info() to allow definition of entities that support Gutenberg.
2. Adding a service used to indicate if Gutenberg is enabled for a given entity/route (see #3142648: Extract $gutenberg_enabled logic into separate functions).
3. Changing Gutenberg to save to Third-party settings for the entity.

With these changes, it does continue to work correctly for Nodes.

It will also support implementing the hook like this to enable Gutenberg for Taxonomy terms:

function hook_gutenberg_entity_info() {
  return [
    'taxonomy_term' => [
      'entity_type' => 'Drupal\taxonomy\Entity\Vocabulary',
      'entity' => 'Drupal\taxonomy\Entity\Term',
    ],
  ];
}

With this, you can then enable Gutenberg for individual Taxonomy Vocabularies. That's where the work ends...

To get it actually working to allow using Gutenberg on the term edit page, there needs to be some work done on the form/templates. I've got some separate code (not pushed) that attempts to do this, but it doesn't quite work yet. Gutenberg does take over the edit term page, but it gets stuck on "Loading..." because (I think) the form isn't rendered on the page correctly.

This work also does not:
1. Create a separate page for the Gutenberg settings (it uses the same Details element).
2. Update the schema as needed.

I've pushed code to the 3163200-make-gutenberg-entity fork to add support for using Gutenberg on other entities, specifically taxonomy terms. I've changed the main Gutenberg module to be more-or-less entity-agnostic, but the support for terms is in a separate gutenberg_taxonomy_term module (included).

You should be able add support for different types of entities by implementing three functions in a custom module:

1. hook_gutenberg_entity_info() to specify the entity.
2. hook_form_FORM_ID_alter() to rearrange form fields so the right ones are moved to the sidebar.
3. hook_theme_suggestions_page_alter() to set the theme suggestion to use the Gutenberg edit page template.

See the gutenberg_taxonomy_term code for an example.

I haven't done a whole lot of testing yet, but it seems to work.

@codebymikey

Well, if you've got working code, I'd love to see it. If it's close, maybe we can help finish it off.

I was bummed out to find that Gutenberg doesn't work for taxonomy pages. I really-really need this for my new 9.x site. My taxonomy pages are fully fledged write-ups full of unformatted info on the topic. And I've seen many drupal sites using such architecture in the past. So far I'm doing it by writing HTML code manually (not always easy to keep track of div opening and closing). A Gutenberg working on taxonomy pages would be a huge saver.

For those of us not code-savy, has this already been added to 2.x-dev?

Many thanks in advance.

@codebymikey

I'm looking at the branch you pushed, but I don't see the ability to enable Gutenberg for any entities, Nodes included. How do you enable this? I saw entity-support.md, but that seems to refer to new, custom modules that you could create config/schema/custom_entity.schema.yml files for.

What am I missing?

@codebymikey

Your latest push to the 8.x-2.x-3163200-entity-agnostic branch seems to work pretty well. Thanks!

@drupalina

This work isn't in the dev branch, but you can use it in your project with a Composer command like this:

# composer require drupal/gutenberg:'dev-8.x-2.x-3163200-entity-agnostic'

Or, you can download the code here:
https://git.drupalcode.org/project/gutenberg/-/tree/8.x-2.x-3163200-enti...

If you can help test this out, we can work on getting it merged into dev.

@jrb (I don't know how to use composer) I'd be happy to test it out on my taxonomy pages, but when I click your link and click the download icon and choose tar.gz, it redirects me to Gutenberg project page on D.o - and nothing happens - nothing gets downloaded.

Is there another way that I can download that version of Gutenberg 2.x ??? Can you attach a .tar.gz or .rar or .zip file in your comment?
Many thanks!

@drupalina

Yeah, I guess you can't download the code from there.

I've attached a .zip file of the that branch of module as of 26 March 2021 (the latest). Please try it out and add comments here with any issues (or to say it's working great!).

@jrb Thanks for attaching the zip file.
Here's my initial test report:
On my 9.x localhost site I've replaced the gutenberg module directory with the gutenberg branch attached inside this zip. Gutenberg module stopped showing among installed modules in "Available updates". So I went into modules page to enable it, it gave me a white screen with "The website encountered an unexpected error. Please try again later.". The front page of the site still worked, but the white screen with error returned every time you try to edit an Article where Gutenberg experience is enabled. In taxonomy pages settings, I did not notice any new settings.
So I removed the guttenberg directory, ran update.php, and then put this "agnostic" branch of guttenberg folder into modules again and ran update.php again. And this time it worked. The Gutenberg settings appeared in Taxonomy pages, and the old taxonomy pages with bootstrap columns were converted into html pages. This means that I have to re-do all the taxonomy pages (oh well, it's ok).
I still have to test how well the conversion of old HTML works, and whether it degrades gracefully (say if after few years one has written loads of content and one wants to switch away from gutenberg - Will the old gutenberg pages retain their basic html structure, or will we have to re-write hundreads/thousands of pages again? that's important from SEO perspective...), but for now, my initial conclusion is that although the installation/upgrade is a little "flaky" (maybe I forgot to do update.php in my first attempt), overall it seems to work on my 9.x site for taxonomy pages (I only tried the default "body" field).
I should say, this is a much better UX for creating content-rich pages, than writing boostrap HTML manually, or using Layout Builder, Paragraphs, or the super-bulky Elementor. So I think this branch should definitely be included in main 2.x branch.
I'm going to test some more over the coming days (especially in the context or bootstrap integration) and if things are as good as now, I'm going to include this branch in my production site, where most of SEO-ed content lives in Taxonomy pages.

On this branch when editing/creating a user, we're getting this fatal error:

Error: Call to a member function getThirdPartySetting() on null in Drupal\gutenberg\Hooks\GutenbergFormAlter->alterEntityForm() (line 179 of modules/contrib/gutenberg/src/Hooks/GutenbergFormAlter.php).

I've attached a patch to fix this. This may also fix the white screen issue @drupalina mentions above when editing a node.

P.S. I'd have done this on the feature branch, but I'm not sure how to do that given that this work is on a separate branch and not the feature branch from this issue.

There was a similar issue on the menu item create/edit page, too. I'd guess that this may be an issue on many different entity types.

The patch in #20 fixes the issue with menu items and should fix it everywhere.

I've been using this branch on a production site for a 2+ months now. It is especially useful for making content rich taxonomy pages. All works fine, and as expected. The only downer is that it's impossible to keep track of Gutenberg in the "Available Updates" page. Would it be possible to merge this branch into the new mainstream 2.x branch?

Thanks for all the reviews. Although it might not be on top of the list, we maintainers have an eye on this issue. I think this is a really good addition, since there no reasons to limit us to nodes only. I'm planning to do a proper review soon.

Out of curiosity: have you used the branch for a new installation or did you moved from already existing Gutenberg driven page to that branch?

@szeidler Thanks! as said in #18, on WAMP localhost I had standard Gutenberg installed (with Drupal 9.x), which I later replaced with the zip attachment in #17. After using it for couple of days and seeing that it fully addresses my needs of easily making rich-content taxonomy pages, I moved the entire installation of the website into live production. And that's where it has been since.
I did also manually apply the patch in #20 (basically, just replaced one for another) on the live site.
The only drawback is that now Gutenberg doesn't show up in "Available Updates", so it's impossible to track and update.

Seems like there is a lot of interest to these features and the fact that several sites are already using this in production is a good indication that this go into a near future release.

Adding both v2.1 and v2.2 tags as we don't know yet which one at the moment.

We'll test this branch on multiple current Gutenberg sites/installations to check how this works with existing setups and do at least 2x of code review here since it's a large change with lots of potential conflicts.

I was starting to review the feature and the initial impression is quite good. Thanks for the incredible job here. I'm testing the branch with a fresh installation and based on an existing Drupal 8 and Drupal 9 installation.

But here some remarks.

The code is currently not mergeable
The simple reason is just the time the feature has been under development and the lack of attention for reviews for some time. But since there has been a couple of commits coming in in the last months/weeks we need to rebase the branch and resolve the merge errors.

In addition we need to increase the update hook numbers. We also need to decide if we care about the ones already using that branch/patch. Because their updates might fail when we're bumping the update hook numbers. So either we add additional checks for the config modification, to skip if it's already in the new data structure or we need to communicate it here.

There is a problem with entity types without bundles

I found an issue with content entity forms, that don't have bundles, such as the user form.

Call to a member function getThirdPartySetting() on null in gutenberg/src/Hooks/GutenbergFormAlter.php on line 179

We need to support/not break bundleless entity types.

Enable field mapping
I like the option and avoiding processing overhead. But where is the overhead actually being created? Couldn't we even on-the-fly really early leave, when we don't see any field_mapping defined? If we agree to keep it like that: Would we need an additional option? Couldn't we just parse the template and check if there is a field mapping or not (and store the boolean field_mapping value if really necessary)?

Removing this from the v2.1 release as discussed in the Gutenberg status meeting today. Will hopefully be ready for the v2.2 release

Thank you codebymikey! for above demo URLs
Gutenberg option missing for content blocks.

This feature is requested in #3123818: Enable Gutenberg editor on core Content Blocks

I'm tagging this to v2.3 release.
Already did some tests and it seems to be working good. I've also missed the inclusion of the Gutenberg settings on Block content type form. I tried to add it to gutenberg.schema.yml file but nothing happened. I confirmed that Block content type class supports the ThirdPartySettingsInterface class. Still, perhaps I'm missing something.
As szeidler said, I'm also not sure if we need the field mapping processing option but I'm ok by leaving it ;)
Really great work @codebymikey and all contributors on this feature.

Thanks @codebymikey, all clear by me. Done some more tests and it seems good to me. Moving this to RTBC.
Btw, we'll try to do more tests on client projects when in dev branch. After that we'll decide if release 2.3 will have a beta 😉

Actually some changes went into dev branch and now we need to rebase again.

Hello codeymikey and marcofernandes. How can I help with the review? I installed the latest dev version, created a new custom block type with a long text field and chose the gutenberg display in that field, but there is no option in the block for enable the gutenberg experience as appears in the regular node content types. - Core D9.3.9

RE: #39 the patch doesn't support blocks, but I think it would be fantastic if that could be added to the scope. Having Gutenberg in blocks is a powerful page building asset.

This MR needs to be rebased or merged up to date