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 -
Note that this will only work in Drupal 10. In Drupal 11, Drupal returns AccessResultForbidden for the menu element within the node form based on the access of the existing associated menu link content item. This means that the menu section is fully removed already from the node form.
jastraat → created an issue.
Currently the module doesn't support exporting between sites.
I agree that this should be in its own table.
Fixed in 🐛 Paragraph cloning fails of the source content does not exist Needs work
jastraat → made their first commit to this issue’s fork.
Could a maintainer please look at this? I'm disappointed a new release was made without getting this merged.
I just updated this slightly to still load the latest revision but to simply refrain from setting syncing to true if the revision info is being retained. This is a slightly smaller difference than the previous one and allows media to be supported again.
We also encountered this error and and the patch in #6 addressed it.
Created an MR based on the patch -
jastraat → made their first commit to this issue’s fork.
jastraat → created an issue.
jastraat → created an issue.
jastraat → created an issue.
jastraat → created an issue.
jastraat → created an issue.
jastraat → created an issue.
jastraat → created an issue.
jastraat → created an issue.
Joseph I created a fresh branch with a fresh MR that does the following:
- Uses "draft" as the fallback for the unpublish action instead of updating the entity a 2nd time within the same action. (from previous MR)
- Consolidates all revision related updates to a separate function.
- If the retain revision info setting is on and there was a revision message in the last revision, append it to the bulk operation log message. (from previous MR)
- If the retain revision info setting is on, the publish action creates a new revision just like it would if the entity was published using the entity form. (new)
- If creating a new revision, make sure to update the changed date on the entity itself similar to what would happen if the entity was published/archived using the entity form. (new)
jastraat → changed the visibility of the branch 3522425-retain-last-revision to hidden.
That's a really good idea since I don't do much multi-lingual.
I'm also thinking of tweaking this so that the behavior with the retain revision info setting makes a new revision when publishing. It seems really odd for that action to be different than the others -
I went ahead an made adjustments to only have the archive change happen on the "unpublish" action with the draft as a fallback. It does eliminate quite a bit of duplicate code and results in a log message that I think makes more sense and an end moderation state of whatever the archived one is (if available).
I recognize that the scope is increased though.
Hey Joseph, this isn't directly related to the functionality of this ticket, but I'm noticing something strange when using the module with media entities.
There's a different process for using this module with a media view ( ✨ Views Bulk Operations Actions for media entities Active ) - which is fine. However, when using that approach, the "Archive Current Revision" action does not appear - just the publish/unpublish current revision.
That's not a big deal, but it looks like the "unpublish" action in this module runs the archive action first - and then runs the draft action on top of it.
You end up with a content entity that is unpublished but in a draft vs archived moderation state. I'm not sure the best approach here, but this issue is highlighted with this patch applied because it's appending both moderation state changes in the revision log message.
Example:
"Bulk operation create draft revision. Last revision message: Bulk operation create archived revision. Last revision message: This content is ready to unpublish"
In #3253887: Change revision message on bulk Unpublish → someone else mentioned how the current log message is confusing, and I can definitely see why now. Is there a reason the unpublish revision doesn't just set to the archived state and only fallback to the draft state if no archive state was found?
Alrighty, I created a new merge request that I actually did some testing with.
In looking deeper at the code, only the publish action does not create a new revision but instead updates the latest one.
Given that, the code needs to treat that action slightly differently. With the publish action, we retain all the original revision information (author, date, message) and simply append information about who/when bulk publishing occurred.
For all other operations where there is a new revision created, I'm leaving the new revision information mostly untouched but append information (if it exists) about the last revision of the entity to the bulk message.
This will help our use case and it does remove a bit of code duplication even if someone isn't using the new setting.
But - I'm not sure how widely useful this is for non-publish actions (in other site use cases). Let me know what you think, and please test with and without the new "retain revision info" option enabled.
Thank you! I'll let you know when I'm ready for a review :)
Also - I'm not sure it makes sense to extend this to the unpublish/archive actions. In my testing, the publish action did not create a new revision, but the archive/unpublish action DOES create a new revision of the node.
@joseph.olstad I appreciate your initiative, but this was unfortunately a work in progress that I hadn't marked as ready for review. Would you mind reverting that commit? It's not complete unfortunately and it causes a PHP error in its current state.
jastraat → created an issue.
Actually I cannot reopen so I will open a new issue.
I am reopening because with the latest version of this module, the issue from #28 is still present.
Both the confirm and cancel buttons are not present.
We're only experiencing this when the "open in a new window" option is NOT enabled.
Thanks!
Followup ticket: ✨ Retain last revision info when bulk unpublishing Active
jastraat → created an issue.
Thanks!
Heads up that I only added the logic to the publish action. We should probably create a followup ticket to add the same logic to the unpublishing action at a minimum.
Are you open to that? I can create a followup ticket and PR -
This is sadly still an issue and if core ever does build a revisions UI for menu link content similar to what they did for media this will be really clear. It also doesn't seem great to be firing presave and save functions multiple times in a single operation.
This seems like something you could customize with a CSS file in a custom module - not necessarily something that needs to be in section library itself.
The module is designed to integrate with the iframe modal and layout builder modal contrib modules as well, so the theming needs to be pretty minimal.
Closing as this does not appear to be specific to section library.
Could you clarify how you would expect these to appear in the off canvas region? It's not wide enough to really use a grid layout.
Marking this as minor.
We need reproducible steps in order to test this.
Could you provide steps for recreating this issue?
The code changes look good; would like to see a review from someone actually using layout library though -
I created an MR with my suggestion.
If this looks like a good approach, I could add the same logic in the unpublishing actions.
I rebased on Drupal 11 and moved the new entity update hook to the hook class with the rest. I'd like to throw this back out for review -