Closing since I cannot recreate in the latest version of the module.
We have this included in https://www.drupal.org/project/revision_extras → now in case it makes sense for some use cases. You can also see how we approached the problem -
Tested using the following steps with the issue branch:
- Enabled the setting to override the controller for the usage tab.
- Copied the new twig template from the entity_usage_plus module into a templates/ directory in my custom module and make a small tweak to distinguish it.
- In the same custom module, used hook_theme_registry_alter() to set $theme_registry['entity_usage_plus_usage_table']['path'] to my module's version of the template file.
- The usage table was overwritten with my custom module version.
- Also confirmed that paging continued to work as expected in the table
Looks great!
Oo - I think I may get some ideas from how you modified the vanilla tugboat! :)
Thanks Jason! I'll create a followup issue to clean up the extractor JS in more detail. (It needs love.)
jastraat → made their first commit to this issue’s fork.
@kwfinken That totally makes sense; given that we're going with a separate module, you can remove me as a maintainer. I appreciate the response!
Thank you @bluegeek! Yes, that was what I was referring to.
I spoke with the rest of my team this morning to get their input on the best path forward. While I really appreciate how responsive you've been and I like the code of this module, the team thought it made more sense to go with a separate module.
https://www.drupal.org/project/revision_extras →
We're suggesting Require Revision Log Message as a similar module that has a more lightweight approach if someone only needs to require revisions on node entities.
Created a merge request against 2.0.x and another against 2.1.x.
This PR adds tugboat which adds the "view live preview" option to merge requests.
I'm afraid I got burned on an earlier project I contributed to substantially and was never able to give our organization credit.
I tested the MR with CKEditor5 v45+ (Drupal 10.5+) and could no longer recreate the problem on referenced nodes or media with the following steps:
- Configure a linkit matcher on content and/or media.
- Enable linkit on a text format used on a body field.
- Click within the body field (no text selected) and then click the link icon in the WYSIWYG.
- Start typing the title of content/media and select it from the autocomplete options.
- Do not add display text.
- Click the insert button
- Observe that the data attributes are not present on the link. Only the href with "node/[id]" or "media/[id]"
Or when replacing "Do not add display text" with "Remove the automatic display text" before clicking insert.
We may want someone to test this in a 10.4 or earlier site before marking as fully "reviewed and tested" though.
Wonderful! I also felt like collaboration made more sense -
I am slightly concerned though; is kwfinken the only one who can approve maintainers? It looks like he hasn't been very active in the commit log the past two years.
If folks are using media library, you'd need to take that form into account as well.
Interesting - yes sorry. There was a commit not in the release notes but it wasn't this one.
I'd add that the 7.0.10 release notes also don't include a reference to https://www.drupal.org/project/linkit/issues/3388565 ✨ Display node title (a text) in by default when creating link in ckeditor5 Closed: duplicate which was included in that release and broke some pre-existing functionality.
Cross posting that this commit also results in this bug: https://www.drupal.org/project/linkit/issues/3552727 🐛 Data attributes no longer added to new link when displayed text empty Active (in Drupal 10.5.4 so the current version of ckeditor)
Rebased the MR to take into account recent changes in the dev branch. Could the maintainers please consider merging this so it's available in the next release? For any sites using content moderation with a large number of rotating users, it's a needed feature!
I'm not seeing this issue with Drupal 11 + Big Pipe enabled. Could you try the latest module release and let me know if that's resolved?
Thanks!
Added some minimal screenshots from the module to the module page.
Since it was technically fixed, adjusting the status.
Nothing changed about the layout section entity field between 1.x and 2.x. The specifications for that field should be identical.
The biggest change is that section library entities are field-able in 2.x. That means that the image field becomes an actual image field (with the ability to for example use image styles) and site builders can add additional custom fields to section library entities. In our case, we added a taxonomy field.
Based on your error message, the update hook to migrate existing entities to be the new field-able entities uses a temporary table.
$entityUpdateManager->updateFieldableEntityType($entity_type, $field_storage_definitions, $sandbox);
I would have expected the temp table to have the same column sizes as the original entity table so I'm still a bit mystified. Do your extras make any changes to the column size or storage definitions that might not be reflected in https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
You can use the tugboat preview to test in Drupal 11. Please also test in a vanilla Drupal 10 install!
jastraat → changed the visibility of the branch 1.0.x to hidden.
I think this was because the CSS file in the code had a different name than the one in the libraries yml. This should be fixed in the latest code.
It seems like the additional serialized data might be making your data too long to support the column size.
Just checking, what specifically needs to be done to get https://github.com/Vardot/ckeditor5-anchor-drupal/pull/16 merged into the recommended module package and a new release of the package? There's no code for within the Drupal module, correct?
Confirmed that when following the test steps in #13 with Drupal 10.5.3 only a single a tag is created. It sounds like we still need someone to test the scenario of a site with an earlier version of Drupal.
Workaround for media library add form:
function MYMODULE_form_media_library_add_form_dropzonejs_alter(&$form, FormStateInterface $form_state): void {
if (isset($form['auto_select_handler']['#ajax']['options']['query']['media_library_remaining']) &&
(int) $form['auto_select_handler']['#ajax']['options']['query']['media_library_remaining'] === 1) {
$form['container']['upload']['#max_files'] = 1;
}
Project (sandbox): https://www.drupal.org/sandbox/jimkeller/2985855 →
I also reached out to the maintainer ( https://www.drupal.org/u/jimkeller → ) via their contact form.
jastraat → created an issue.
Closing as a duplicate of https://www.drupal.org/project/tealiumiq/issues/3517011 ✨ Add .gitlab-ci.yml Active
jastraat → created an issue.
Updated the MR to add more Drupal 11 compatibility. Given that Drupal 11 ConfigFormBase is not compatible with versions prior to 10.2 I reflected that in the info files.
Note that the current method for requiring the necessary dependent modules for the sub-module does not work but that pre-dates the need for Drupal 11 compatibility and could be handled in a separate issue.
Also the sub-module for tealiumiq needs the info file updated as well.
Getting the following error with Drupal 11 on /admin/config/services/tealiumiq/defaults:
ArgumentCountError: Too few arguments to function Drupal\Core\Form\ConfigFormBase::__construct(), 1 passed in /var/www/html/web/modules/contrib/tealiumiq/src/Form/Defaults.php on line 33 and exactly 2 expected in Drupal\Core\Form\ConfigFormBase->__construct() (line 44 of core/lib/Drupal/Core/Form/ConfigFormBase.php).
I wonder if https://www.drupal.org/node/3278759 → is related to the scenario outlined in #25
It looks like the composer and info file changes from this issue were committed on Dec 26, 2024. Is there a plan to release a Drupal 11 compatible version of the module? What's the status of this issue? Thanks!
swirt → credited jastraat → .
swirt → credited jastraat → .
Could you outline more specific steps to recreate/test this?
swirt → credited jastraat → .
I made some very slight string and whitespace changes to address pipeline cspell and phpcs complaints and tested the MR with workflows for both media and nodes. This worked like a charm.
jastraat → made their first commit to this issue’s fork.
Thank you! Merged -