Make section library template fieldable

I'm attaching a patch that does the most minimal job of making section library templates fieldable. It adds no new routes and uses the entity collection route as the base for managing the field UI. It adds no new classes or menu items and does not add fields to section_library's custom "add to library" forms.

This also doesn't include an update hook for sites that already have section_library installed; that would be a good enhancement.

However, with this patch in a site installing section_library for the first time, the following are true:

• Add additional fields to section templates at /admin/content/section-library/fields
• Manage the edit form display and the edit form (which is more content entity vanilla) will display all the fields as you have configured them.

Users could alter the add to library forms using route subscribers to define their own form classes or with form alter hooks to add fields as desired to those forms.

Future enhancements could include:

• Altering the add to library forms so that they automatically include the custom fields
• Adding an entity type update hook for sites already using section_library

The latest MR also converts the image field to a true image field which allows for applying image form options for example. Note: this is another change that requires an entity update.

Attaching a patch reflecting the current MR. This adds an update and post update hook to make the image field a true image field, make templates fieldable, and update existing instances of template content.

The only thing that I have not included yet is updating the template collection view to use an image field in a post update hook.

Added a post update hook to update any views using the section library template image field.

I created a blank Drupal install, enabled section_library and confirmed it was working as intended.

Then I applied the patch. Afterwards the sections I added to the library were still displaying correctly in the admin page on in LB. I was able to still apply section libraries successfully.

I then added a simple text field to Library Template entities and was able to edit and save data into the new field.

section_library_fieldable-3442106-9.patch works with no issues.

Attaching a patch with the most up to date code from the merge request.

I really like this new feature!
I see the new logic and feature being added to a new major branch, 2.0.x, to avoid causing issues for the 5,706 sites currently using the module.
Alternatively, it could have a smart and smooth update process.

This does have an upgrade path to convert the existing entities and any views (likely just the one) that were using the file (now image) field. It might make sense to do a 2.x branch anyway, but definitely trying to provide a smooth upgrade path!

Attaching a patch from the most recent MR. This changes the add forms so that they extend ContentEntityForm and as a result show any custom fields that have been added to the template entity.

Updated patch from latest MR to add more flexibility to the choose section controller, add a title callback to make the add form title dynamic, and fix some stylelint errors.

This MR has expanded beyond the original scope, so it makes sense to create a new branch and it needs to be re-reviewed.

One more addition - the ability to add a description to the choose section dialog.

Adding a new patch based on the latest MR

Tested the patch in #24 for the following scenarios on a fresh D11 install:

• Existing install of section library prior to the fieldable patch with existing templates (with images) that needed to be updated
• Fresh install of section library starting with the version that was patched
• Adding/inserting both templates and sections
• Working with no modal module, layout builder modal, and layout builder iframe modal
• Customizing the choose modal with an image style by setting an image style in the entity view display

All testing passes. Patch looks good to me.

Attaching a patch based on the current MR.

I'd love to hear from the section library community: do you think the template list and field configuration makes more sense under content or under structure (where other field config lives)? One benefit to under structure is that it would be listed with other structure sub-links on the main structure page. The content section doesn't have a page like that.

Tested the patch in comment #28 on a fresh D11 install according to testing steps outlined in this issue. All is looking good to me.

Tested the patch in #28 for a fresh install with patched module and from an existing install with pre-existing content that was later patched and updated.

- menu item "Layout Builder Library" displayed under /admin/content listing available section
- adding a new field to be applied to all sections and configuring field and display settings
- adding and inserting section & page templates worked fine
- the image can be customized to use different image styles
- everything worked fine when the library displayed in the default settings tray, in a layout builder modal, and in a layout builder iframe modal

All testing steps passed and the patch looks good to me.

I've reviewed and tested this patch as well. The code looks good. It cleanly applies to the dev branch and appears to work as intended.

+1 for merge. Nice work!

Hello,

Quick feedback after quick review.

A uuid had been commited in the config provided on install:

uuid: c6a6de3c-e35a-4730-9621-27e6e30aad07

I will try to test that in the coming days.

Yes, Florent
The uuid: c6a6de3c-e35a-4730-9621-27e6e30aad07 should be removed.
removing it for sure

Listed the 2.0.x-dev →
Assigning the 2.0.x branch as a new workspace for major changes.

Jess, I'm sure we will be hit by a large number of follow-up issues for over 6k sites.

• Minor changes should be in minor branches and minor releases.
• Major changes should be in major new branches with new major releases.

Sometimes it feels okay to make big major changes in a minor release, but it is not.

Release engineering and management are meant to limit follow-up issues and guarantee a smoother update/upgrade process.

Semantic Versioning 2.0.0

'file_extensions' => 'gif png jpg jpeg',
Drupal Core supports webp now, we could allow for it in the file_extensions

@rajab natshah after our conversation in Slack, my understanding was this was fine for the 1.2.x branch as long as we didn't move the section view under structure.

Thank you for removing that UUID from config.

I agree that it makes sense to update file extensions but that seems beyond the scope of this ticket. I created ✨ Drupal Core supports webp now, we could allow for it in the file_extensions Active for that new feature.

Since this has been merged, this makes sense with a status of fixed. Happy to tackle any follow up issues in separate tickets though!

Yes, Jess, we agreed to have this in 1.2.x.
Maybe Florent's comment made me a bit hesitant.

Let’s file new issues for further improvements and changes.
Keeping a clear threshold between major and minor changes.

Sounds good!

Updating this to the relevant major version.