Allow other entities to use this feature aswel

Added my vocabulary fix. Was trying to make a version that would be more inclusive but i could not find a way to get the proper entity types and vocabularies.

Not sure if this is any use to anyone, but it fits my scenario when working with custom entities (not just nodes and taxonomy).

Was unable to use patch from #6 so i made a commit with the changes from that patch with some minor changes like an update hook for the renaming of node_types to content_types.

Sorry about the spam forgot the commits get directly posted here. I have rebased the branch so the patch applies.

Hi, just going to quickly note that this project is considered "Feature Complete," as such I won't be very active in participating in feature requests. However, if this work (or any other Feature Request for that matter) turns out to be really solid and bug-/consequence-free, then I'll happily merge it -- though probably only into a new 2.0-alpha branch.

Otherwise, I'll be pretty hands-off on this and won't be reviewing work until it's marked RTBC.

A rookie question: Does ConfigEntityBundleBase also comprise blocks and paragraphs?

I noticed this MR removes the line use Drupal\node\NodeForm; -- this line is a pain point for compatibility between Drupal 11.2 and <11.2 and should ideally be removed. See #3535599: 2.x: Allow backward compatibility for Drupal <11.2 →

I'll be looking at this and if it seems to work fine as-is then I may release it in a 3.0.0-beta. Otherwise I might just pick out the parts that allow it to work without using NodeForm. In the latter case the MR would need to be updated to target the 3.x branch.

There's a few major issues I ran into when using this MR on a fresh sandbox Drupal 11.1.8 installation.

What worked correctly: I first installed 8.x-1.9 and configured it to apply to the default Article and Basic Page content types. I then applied the MR and ran database updates, which migrated these content types to the new configuration per screenshot:

I then checked every checkbox and saved the configuration.

The Save & Edit button appeared on the following entity types:

- Basic block (block_content_type)
- Default comments (comment)* (clicking "save and edit" on a sandbox site takes you away from the article and it's hard to get back to it)
- Article and Basic Page (node_type)
- Tags (taxonomy_term)*
- User (user)

*These say "comment_type" and "taxonomy_vocabulary" respectively in the configuration form, but I think their actual entity types are "comment" and "taxonomy_term." This is probably related to a bug that I describe below.

However, it did NOT appear on these entity types, which don't seem to use the same form as those on the above entity types. I think this is being addressed somewhat in a core issue: #2835535: Standardize basic content entity form logic in ContentEntityForm →

- Website feedback (contact_form)
- Personal contact form (contact_form) (this form can't be edited)
- File (file) (I wasn't able to find a form to edit file content)
- Custom menu link (menu_link_content)
- URL alias (path_alias)

I don't know what "shortcut_set" is so I couldn't test it.

There's also an issue where if two entities of different types have the same name -- e.g. if there is an "Article" content type and an "article" taxonomy vocabulary -- they will get merged into a single checkbox, and the save_edit.settings content_types array does not distinguish between them at all. In this case instead of "Article (node_type)" the config page will say "article (taxonomy_vocabulary)".

This needs a lot of work before it can be considered production-ready. At the least, we should probably restrict adding the Save & Edit form to only Content Types, Taxonomy Terms, and Media, since only three entity types that come with Drupal are really likely to need the form.