🇺🇸United States @josephcheek

@loopy1492 were you able to get past this? If so, how?

With D10.4 and Lightning Core 5.14, the patch in #3 applies but doesn't fix the issue; instead, it creates an error very similar to the one it is supposed to fix: (tried: 10.4.2, 10.4.4).

[error] AssertionError: Failed on config name 'lightning_core.versions' in assert() (line 264 of /var/www/html/docroot/core/modules/system/system.post_update.php) #0 /var/www/html/docroot/core/modules/system/system.post_update.php(264): assert()

(the rest of the backtrace is exactly the same)

josephcheek → created an issue.

same patch will fix #3358814 also.

This patch, #2, is the same patch in bug# 3332016, patch #2, which works for me in my use case (Solr not available). I voted for RTBC on that patch, so does that count as a vote for RTBC in this issue as well? Do bug votes have transient properties?

If so, I vote +1 for RTBC.

+1 for RTBC. patch #2 works for me.

Q: is there any downside to altering the code to configure the code to default to changed: changed instead of changed: timestamp ?

Note that the warning does look ugly but does not seem to affect functionality, and since most (?) Drupalers are using media:image and not file:image now, this is probably a low priority. But I didn't see a bug report on it, so I thought I should log it anwyay.

josephcheek → created an issue.

Looks to me like this bug, 3437293, and 3277056 are all the same, and each has patches available which (approximately) do the same thing. Of the myriad of patches available, I'm trying https://www.drupal.org/files/issues/2024-06-12/2914385-35.patch → because that seems to be the simplest (smallest LOC) that doesn't generate an empty-string UUID. But I really don't know which patch is better, honestly.

+1 for patch 4. can we get this rolled into a release, please?

also getting this in a D7->D10 migration with LDAP. will attempt removing LDAP from before the user migration.

MR at https://git.drupalcode.org/project/drupal/-/merge_requests/6294

josephcheek → created an issue.

josephcheek → created an issue.

Gave credit to the wrong org. This was found while working for ICF.

josephcheek → created an issue.

This page? https://groups.drupal.org/node/6795 ? It's a wiki page. Anyone can edit it.

Done.

This page? https://groups.drupal.org/node/6795 ? It's a wiki page. Anyone can edit it.

Done.

Another wrench in this machinery is that claro, at least, has a custom twig template for the exposed filter form (when chosen as exposed, at least) that hard-codes all the form objects that go above the "fold" that dialog.views.js creates. It specifically puts these fields in the top:

{{ form.form_description }}
{{ form.expose_button }}
{{ form.required }}
{{ form.group_button }}
{{ form.label }}
{{ form.description }}

{{ form.operator }}
{{ form.value }}

and then, later,

{{ remaining_form }}

which includes the $form['filter']. So another option is placing $form['filter'] inside 'value', or modifying the template (adding your own?) so that {{ form.filter }} is displayed before the fold.

The culprit for this is dialog.views.js inside views_ui and a similar problem has been discussed in the drupal core buglist at https://www.drupal.org/project/drupal/issues/3161840 🐛 Modal dialogue Views Messages breaks form usability Needs work . That particular bug has to do with messages displaying inside the modal, but the effect (and cause) is the same -- the JS code that is trying to maximize the space inside the modal dialog is not taking all elements into account.

There is a patch in that ticket that adds support for counting message dialogs inside the modal, so perhaps that can be used as a starting point to fix this issue.

Added a fix to check for the block before attempting to render it. Credit should go to ICF, not ZDS Group.

You can trigger this also just by trying to display a block whose token doesn't exist, such as adding a character to the end of a valid block token. Ex: if [block_token:my_module:foo] is a valid block, try to render [block_token:my_module:foo2]. You get the above error.

I thought it was just me! Good call on referencing the 9.x documentation; at least I can see the 9.x API...

ok I couldn't figure out how to get a diff to patch composer without creating a MR, so MR created 8-).

I added a bit of code to check whether the field definition for the label field exists before attempting to set the label. No MR yet because it needs checking, testing, rewriting, debating, rewriting again, etc. https://git.drupalcode.org/issue/auto_entitylabel-3387731/-/commit/5f124...

josephcheek → created an issue.

At risk of adding a comment just to say +1, I would love to see this. +1.

josephcheek → created an issue.

Hello, #13 doesn't apply on the latest 2.0.0-rc5 due to (I think) the merge of https://www.drupal.org/project/inline_entity_form/issues/3097411 🐛 Entity form simple weight duplicates Needs review , but I am not clear whether this patch is still necessary now that 3097411 is fixing the weight problem on its own. I am using multiple_fields_remove_button and have found that I cannot remove the entity reference when there is only one entity remaining in my multiple fields. So, it used to be that the last one was always removed, and now it can never be removed?

@slydevel made a patch for D10.1 that applies for me (whereas #15 does not). It took me a while to find it so here's the link, hoping to save others some time fixing this issue on D10.1.

https://git.drupalcode.org/issue/drupal-3308707/-/commit/acdedacad5af5af...

Patch #10 added support for Checkboxes, Table, and Tableselect, but removed the necessary isset() from #3 on those, now giving (D10.0.9, PHP 8.1.18):

Warning: Undefined array key "#options" in Drupal\Core\Render\Element\Radios::processRadios() (line 62 of core/lib/Drupal/Core/Render/Element/Radios.php).

Either an isset() or my preferential array_key_exists() needs to be added to these to suppress this warning. I've rerolled #10 to add array_key_exists() on all of the changes.

I'm getting this also. I'm using bootstrap_sass 5.0.9 and my subtheme is referencing this undefined variable. Adding $barrio_path_images: "../images"; does appear to fix it for me.

BTW this is on a clean slate, so I do believe this is a bug, but I'm not sure whether this is a bug in bootstrap_barrio or in bootstrap_sass.