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.