🇺🇸United States @jastraat

Looks like this was incorporated into the 2.x version of the module. Probably could close this?

Adding a patch with a post-update hook to automatically clear the cache and pick up the updated form dependencies.

Hey @AaronChristian thank you for testing! Just to make sure, did you fully clear the Drupal cache after applying the patch? This injects a new service to check for layout_builder_modal.

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.

Sorry - that earlier patch included some changes from another section_library patch I have applied.
Here's a clean one.

And finally figured out the dialog closing issue. This latest patch addresses both of the outstanding issues mentioned in #3.

Updated patch that pre-filters template type based on the import link clicked. Still haven't figured out how to get the ajax modal to close after adding a template.

I'm attaching a patch that integrates the MR's changes with the latest dev of section_library. Unfortunately I could not make changes to the MR directly. This also does not resolve the two last issues.

Thanks for the update Lee!

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

jastraat → created an issue.

jastraat → created an issue.

The patch from the MR linked in #15 is also working for us.

jastraat → created an issue.

jastraat → created an issue.

Quick clarifying questions on this one:

Should the convert to webp also be added to the default config from the Drupal core image module? (That would include the large, medium, thumbnail, etc styles.)

And is this truly just to add something like the following as an additional entry in the "effects" section of all image.style.*.yml files in core install profiles?

    e037ec38-0f1e-425b-90f2-a80e622df793:
    uuid: e037ec38-0f1e-425b-90f2-a80e622df793
    id: image_convert
    weight: 2
    data:
      extension: webp

Sorry; I meant to reach out to the Drupal support team after the initial PM to ask what the usual method for re-assigning a project namespace was.

The library module was initially developed for Drupal 6, and its functionality was mostly recreate-able without a custom module even in Drupal 7.

So it totally makes sense that the library namespace should be assigned to a more active project. While there is a version of the module for Drupal 7 and Drupal 7 is not technically unsupported, I doubt there are many existing D7 users of the module and there is no plan to create a Drupal 10 compatible version.

Thank you for checking!

I created a second branch and merge request for the 3.x branch.

Alrighty, it looks like disable_toolbar_language_switcher is still a configuration setting in 3.x and I don't see it listed in the schema, but if you think this makes more sense as a separate issue, happy to go that route.

Thanks @joseph.olstad!

I think the 3.x branch needs these same changes.

Created a merge request for the 2.x branch.

jastraat → created an issue.

It looks like "-1" is the default version set when a library does not declare a version:

https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/lib/Drupal/...

@Denes.Szabo pinging to see if you could look at / commit this to add compatibility for shortcode. This is our last module hold out for upgrading to Drupal 10.

I believe this code may correct the failing test in the committed code -

Adjusting 11.x tests in new CronSuspendQueueDelayTest.php

Re-roll for 11.x

Fixed in 🐛 search_api Drush error drush.service in composer Fixed

This is a patch to make the existing Shortcode text filters compatible with CKEditor 5, the module as a whole compatible with Drupal 10, and fix the existing shortcode tests so that they pass.

The existing Shortcode 2.x code does not include a CKEditor 4 plugin (e.g. a class that extends CKEditorPluginBase) so while there may be a desire to add that for CKEditor 5, it would be new functionality. Marking back to needs review.

If someone has tested this patch with CKEditor 5 and are getting errors, please post those errors so we can get them fixed! Thanks :)

Damien, I tested the shortcode basic tags plugin with CKEditor 5. There are pieces to this that make the module compatible with CKEditor 5 - namely changing the filter type from TYPE_MARKUP_LANGUAGE to TYPE_TRANSFORM_IRREVERSIBLE

Have you tested it with CKEditor5 and it did not work?

We have tested with this patch and Drupal 9.5.x + CKEditor 5. We are using our own custom Shortcode plugins that extend ShortcodeBase and they work with CKEditor 5 and this patch.

We don't use the shortcode_basic_tags submodule typically, but I just enabled it in Drupal 9.5 site using CKEditor5 along with the patch above and [highlight] for example works as expected replacing the shortcode syntax with the span tag.

@DamienMcKenna, if you revert those edits, the tests won't pass. When the HTML is generated, it creates spaces ahead of class names.

The changes to add D10 compatibility are included in the patch in 🐛 CKEditor 5 + Drupal 10 Compatibility Fixed . Since CKEditor 5 is also part of being D10 compatible, I'd suggest focusing on getting the fix in that ticket reviewed and committed!

@peter-majmesku thank you for your quick response! I'm not looking to become the maintainer. If the module is currently unmaintained, would you mind updating the project page to reflect that it is seeking a new maintainer? I can also create an issue in the https://www.drupal.org/project/issues/projectownership → queue.

jastraat → created an issue.

Could someone else please review this so we can get a CKEditor 5 compatible version out the door? We've been using the patch above in production for a few weeks now.

Could we please get this committed and a new release of the module? It looks like the last commit to this module was made over 2 years ago. Is the project still being maintained? Thanks!

jastraat → created an issue.

The 2.0.x branch is now available to select to test against; marking as fixed.

Removing the core: key from the info files again. Waiting to run tests until 2.0.x branch is available.

The 2.0.x branch is the current one, so that is the branch this patch was created against which is why the patch does not apply. The 2.0.x branch is not available to test against right now. I've created another issue to make it available so that automated tests are useful.

jastraat → created an issue.

Trying this once again with #3203585: Patch didn't apply, but it seemed like it was only the info file that it failed on → in mind.

This updated patch fixes the functional tests for shortcode.

Since the filter transforms on render, we needed a more robust setup for the functional tests that includes having a content type (using the standard install profile), creating a custom filter format, creating nodes with the test content, and then displaying those and comparing the expected result to the actual result.

A few subtle additional changes:

• Drupal has dropped closing tags in self-closing void elements (e.g. img) since they aren't part of HTML5. In order to get the test for the img tag to pass the test needed to take that change into account. See 📌 Remove all references to "self-closing" void elements in core Needs work
• Drupal has some oddities with how it sometimes adds classes to elements, and under some circumstances when there is a single class, a preceding space is added. The tests take that into account.
• Since we're comparing rendered content, special characters like ampersands render as multiple length text strings instead of single character strings leading to unpredictable results when running the random test. I've limited the character set generation to only alphanumeric characters now.

I also rolled the D10 deprecation fixes from 📌 Automated Drupal 10 compatibility fixes Fixed into this patch.

The file_url_generator service was added in 9.3, so

core_version_requirement: ^8 || ^9 || ^10

needs to be

core_version_requirement: ^9.3 || ^10

#332 works for us, and we've been using it in production for roughly 9 months. It still applies to 7.53 (with a 15 line offset) and fixes our issue with left joins.

Note that to generate the original issue described by this ticket, a content access module is not necessarily required. Just an optional relationship in a view using an entityreference field.

Patch #231 works for me. Is this a confirmed bug in D8? It's been a number of years since this was first reported, and it seems like a number of folks have reviewed this for D7.

Patch in #231 with 7.34 worked like a charm.