🇺🇸United States @mkindred

Ah, gotcha. Thanks for clarifying.

I haven't had a chance to review all this lately, but since #3210353 was committed to the 2.0 branch 2+ years ago, and people were still having this issue described above as recently as last week, the fix doesn't seem to have solved it.

I don't understand how #2658678 is related to this issue.

If I have the time soon, I'll try to recreate the issue in a new install and record it.

I created the patch I referenced in the issue description, but the modal 'Create Event' creates the node only, not the group node. So I won't offer it up here until I can determine whether I can make the modal work within group nodes.

mkindred → created an issue.

lmk if anyone needs anything further from me. While I'm probably not up to the task of creating a patch at the moment, I can test and provide more info regarding any potential theme implications, if necessary.

I applied MR19 against core 10.3.9 and entity_print 8.x-2.15, and it's working great. This MR fixes my css rendering issues in local docker containers via the base_url setting already in entity_print.settings.

This still seems to be an issue. The bug appears in multiple scenarios (not just when you set existing terms to 'None'), so I changed the title.

As @deepakaryan1988 mentioned, if you add a new term after changing existing terms (terms that existed prior to the current edit), then the values for the edited terms are reverted to the pre-edit values. This change happens in the background such that it looks as though your edit is OK; you find out only after you save.

Steps

Adding new term reverts changes to existing terms:

1. edit content with existing terms saved
2. change existing terms
3. add a new term
4. save
5. changes to existing terms are lost

Saves OK if you add the new term before editing existing terms:

1. edit content with existing terms saved
2. add a new term
3. change existing terms
4. save
5. changes to existing terms are saved

I've created a video to demonstrate the bug in a fresh D10 install: https://odysee.com/241024_drupal_shs_bug:c

I was suffering from this issue. I applied the patch from MR20, and it seems to have solved the problem for me.

The devel_entity_updates module states, "Do not use this to fix the Mismatched entity and/or field definitions error: again, this is not meant to fix production sites. If you encounter that error you should identify which module defines the problematic entity type or field definition and open a bug report or support request in its issue queue."   https://www.drupal.org/project/devel_entity_updates →

@markconroy I like disabling them after selecting one to give the user feedback and prevent clicking on a second facet prior to loading the new page. I've shopped on quite a few ecommerce sites where the subsequent page was slow to load, and without feedback I thought I might have missed the facet link.

I was running into the issue mentioned in #12, and the patch in #38 fixes it for now.

Well, that's embarrassing. I did indeed have the "convert line breaks" filter enabled. I've been trying to remove old text formats for some time, and I didn't realize one of the older formats was still being used.

So to update: patch #30 does fix the issue for me while upgrading from ckeditor4 to ckeditor5 on D10.2.1 while using the "Convert line breaks into HTML" filter.

@longwave I tried and cannot reproduce this behavior on a clean install. My ckeditor upgrade involved ~10 commits, so I'm reviewing each one to see where the issue entered.

I think I'm running into this issue, but the circumstances are (confusingly) different.

I'm on 10.2.1, and I'm currently upgrading from ckeditor4 contrib to ckeditor5. I'm not using "Convert line breaks into HTML (i.e. <br> and <p>)" before or after the upgrade, yet I'm seeing doubled linebreaks after the upgrade. If I open the offending node for editing, the linebreaks look normal (single), and saving the node fixes them.

The only two filters I have enabled (before and after the upgrade) are:

- Limit allowed HTML tags and correct faulty HTML
- Correct faulty and chopped off HTML

If I apply patch #30 with the upgrade, it seems to fix the doubled linebreaks. If I'm not using the "Convert line breaks..." filter, should this patch affect me?

Patch to add empty window.onunload function.

mkindred → created an issue.

Although I've never used editor_file previously, I was able to confirm the bug in a fresh install of D10.2.2, editor_file 2.0.0-rc1, and linkit 6.1.2.

Patch #6 fixed the issue for me.

I was successfully using #5 until upgrading to D10, at which point I ran into issues with the use of file_create_url() (which had been deprecated) in the patch.

I created a fork based on #5, replacing two instances of file_create_url().

I'm currently on D10.1.6, but I'm still using ckeditor 4 (contrib). Based on the fact that #5 was meant for ckeditor 5, I'm hoping my commit will also work for 5 but I can't test that until after I upgrade ckeditor myself.

Switching to 4.0.x-dev for bug/deprecation fix.

I ran across this issue today. I was trying to create a simple admin report showing the number of images (media) attached to each node of a particular content type. (I need to limit the number of images that my client adds to an existing 'product' content type, but first we need a report showing how many he's currently using per product.)

Here are the steps I took (in D9.5.10):

1. Create a view for a single content type, table list of fields.
2. Add a relationship to each of two media fields (images in my case).
3. Add two image fields to the view, each using one of the two relationships above.
4. Turn on aggregation. The aggregation works as expected, except that the two fields' counts are multiplied by each other.
5. I tried to change the aggregation type for the two image fields from 'Count' to 'Count DISTINCT'. But the modal won't close, and I'm seeing an error in watchdog:

TypeError: array_filter(): Argument #1 ($array) must be of type array, null given in array_filter() (line 687 of /var/www/html/drupal/web/core/modules/views/src/Plugin/views/field/EntityField.php)

As mentioned in #4, I'm not sure patch #2 is the correct solution, but it prevents the error, allows me to save the aggregation settings per field, and gives me the view I want.

mkindred → created an issue.

I'm having a problem with this, as well.

It seems that the target attribute from the Link field does not carry through to the Linked Field. I had hoped that perhaps the target attribute could be specified as a token in the Advanced section, but that token seems not to be available. (Title does appear as a token, but target does not.)

Is there another way to do this?

Patch #5 works for me. Thanks!

I need to create PDFs of revisions, so I tried #14, but it didn't work for me. Although it alters the controller to accomodate printing revisions from PDFs, it seems to be lacking the {revision_id} path parameter for the entity_print.revision.view and entity_print.revision.view.debug routes.

Also, I couldn't apply the patch via git apply due to a case mismatch in EntityPrintController.php: @TODO should be @todo in the patch. This case change was made back in #3104331 🐛 PHP_CodeSniffer warnings and errors Fixed .

I made the following changes to #14 and got it working for my purposes:

1. added {revision_id} path parameter to the entity_print.revision.view and entity_print.revision.view.debug routes
2. added a missing @param to the viewPrintDebug() document block
3. revised entity_print_entity_view_alter() to add revision_id as a path parameter for the View PDF link.

I'm sure that my revision to entity_print_entity_view_alter() (to alter the View PDF link) is the wrong way to go about this, so consider this patch to be in-progress. It assumes that there's always a revision id, and it works for my specific use case so far. But I'm sure this needs to be improved.

@bengy can I get some feedback on the overall direction of the patch?

I'm hoping someone can help me get a better understanding of this. Here's my current understanding:

Back in January 2023, the 2.1.0 tag included commits from back in April 2021 that added config schema (commits e80fdfa and 3d5a4c7 from issue 3197371 → ). Some time after I updated to 2.10 and/or 2.1.1, I found that I could no longer edit the container attributes. My patch changed two elements in the schema from string to sequence.string. After applying the patch, I can now save container attributes, export config, and import config. It seems to me that my patch aligned the schema to what was already on the dbase.

Is this mostly correct?

Also, if an update hook is required, how can I confirm the schema changes before and after that update hook is run?

This one took a *long* time to diagnose, due to what I think are multiple bugs. There's a UI/AJAX bug that doesn't allow you to save classes or attributes unless you first tab out of the class field. And I believe the schema for attributes is incorrect.

I documented my findings here: https://odysee.com/@ArsNova:6/230309_drupal_contrib_bootstrap_layout_bui...

I've forked the project to provide the schema change, but since working with gitlab's 2FA / SSH keys / passwords / personal tokens is so difficult, I'll provide it as a patch as well.

If my schema changes are correct, I'll create the MR.

I did a few more tests, trying to find out which commit first caused these errors. It looks like it might be related the the config schema changes in/around commit 3d5a4c7 'Missing config schema'. Is it possible that the config schema is wrong for some of these attributes/classes? I didn't notice the issue until updating to 2.1.0, but the previous release was two years prior.

I've exhausted what I can debug with my current understanding of the config schema. If someone can point me in the right direction, I don't mind spending some time to create a patch.

(I'm hoping this wasn't due to my upgrade workflow... I'm a bit surprised that nobody else has run into this issue so far.)

I was hoping to find a way to override the host for docker containers, so I tried the patches here. The latest #22 no longer applies cleanly, so I reworked it so that it does.

But I'm a little concerned about a few things with the patch.

1. Seems like a patch should solve one problem, but this issue is a combination of several unrelated problems:
   1. environment host override
   2. check button
   3. exclusions (not in the current patch)
   4. and content published status
2. I thought the logic used for the overridehosturl was unclear: use overridehosturl only if (host is set and host== basepath)... why not just override if overrideurl is set? (I might be missing something here that's not applicable in my environment.)

But I've always been a bit confused by linkchecker's config: seems like base 'path' includes hostname, and that has always perplexed me. I think the config descriptions could use some updating.

So #23 works for me locally, but I don't think I'll apply it for production. Perhaps the maintainers can chime in... the hostname override is a very good thing.

I created a video to show the bug: https://odysee.com/@ArsNova:6/230223-drupal-contrib-bootstrap_layout_bui...

(This video also shows an odd bug causing multiple sections to be added at a time, instead of one.)

It looks as though commit 9012d81 from #3292760 🐛 Column classes are not inserted to Twig template, only the word "Array." Fixed might be the culprit. I installed 2.1.1 and backed out that commit, and although the column bootstrap classes are now missing again, the addl classes I applied did work:

I confirmed that these issues don't occur on a vanilla D9 site using BLB 2.0.1.

mkindred → created an issue.

I found that #3 fixed the problem on my D9.5 site, so I decided to re-roll for contrib/seven in D10.

One problem with this patch is that it directly alters both nav-tabs.es6.js and nav-tabs.js, the latter of which ought to be created by transpiling in yarn. I tried to do it, but yarn balked:

Error Couldn't find a package.json file in "drupal-contrib-d4d/drupal/web/themes/contrib/seven"

Does seven need its package.json for this to happen?

@therobyouknow Is your install still working? I think I'm having the same issue in D9.5.2 using bg_img_field 8.x-1.7. I got the background image working without layout builder first, and then when I switched to layout builder, I can't get the image to display.

Error message on the Manage Layout page for the paragraph:

Notice: Undefined index: css_selector in Drupal\bg_img_field\Plugin\Field\FieldFormatter\BgImgFieldFormatter->buildElement() (line 218 of modules/contrib/bg_img_field/src/Plugin/Field/FieldFormatter/BgImgFieldFormatter.php).
Notice: Undefined index: css_repeat in Drupal\bg_img_field\Plugin\Field\FieldFormatter\BgImgFieldFormatter->generateBackgroundCss() (line 277 of modules/contrib/bg_img_field/src/Plugin/Field/FieldFormatter/BgImgFieldFormatter.php).
Notice: Undefined index: css_background_size in Drupal\bg_img_field\Plugin\Field\FieldFormatter\BgImgFieldFormatter->generateBackgroundCss() (line 278 of modules/contrib/bg_img_field/src/Plugin/Field/FieldFormatter/BgImgFieldFormatter.php).
Notice: Undefined index: css_background_position in Drupal\bg_img_field\Plugin\Field\FieldFormatter\BgImgFieldFormatter->generateBackgroundCss() (line 279 of modules/contrib/bg_img_field/src/Plugin/Field/FieldFormatter/BgImgFieldFormatter.php).

I'm hesitant to open a new issue, since your issue resolved itself.