@mdranove

mdranove → changed the visibility of the branch 3115978-required-summary-field-config to hidden.

Im not entirely sure the current approach in MR 5004 is the right approach.

Started a new branch. I think it makes sense to just set this to not be required if it's the field config form. Only issue is there's logic setting the display to none by default for the summary default value. Think only thing left is to show that in JS on click of the checkbox. Then add a test.

mdranove → made their first commit to this issue’s fork.

I updated this for 2.1.x. The original MR is good. Just tweaked it to add a bit from patch #9. Also while testing was getting an exception in src/Plugin/QueueWorker/LinkStatusHandle.php, so I added a bit of logic there to try and make sure we aren't merging any breaking changes.

Please review.

mdranove → made their first commit to this issue’s fork.

Updated pattern, added test based on feedback. Seeing expected result when tags are placed inside of . Moving to NR.

mdranove → made their first commit to this issue’s fork.

Bumping to major as this seems like a fairly big issue, flagged in multiple threads.

I checked it out. Good there's no exception now, but error message should explain the issue, not just "0 is invalid". E.g say it needs to be an integer. Also, users should be allowed to leave the field empty, that shouldnt generate an error IMO.

But all this is second of importance to doing something about https://www.drupal.org/project/linkchecker/issues/3065056 🐛 "Don't treat these response codes as errors" not used Active . Until that's resolved, this configuration doesn't do anything. It's in NR right now. Can someone review?

Took another look on a new branch. Should be good now.

mdranove → changed the visibility of the branch 11.x to hidden.

Added a new test, but need to fixup old tests too.

mdranove → made their first commit to this issue’s fork.

mdranove → created an issue.

mdranove → changed the visibility of the branch 2.0.x to hidden.

mdranove → made their first commit to this issue’s fork.

mdranove → changed the visibility of the branch 8.x-2.x to hidden.

Tested and fixed merge conflict in MR !60. Added an update hook and did a little cleanup on the views config, fixed phpstan error.

Id say it's pretty RTBC at this point, also closes at least two dupes.

mdranove → changed the visibility of the branch 2.0.x to hidden.

mdranove → made their first commit to this issue’s fork.

Might be better to solve in 3468352 🐛 "Broken links report" should filter broken links only Active

mdranove → created an issue.

mdranove → made their first commit to this issue’s fork.

mdranove → made their first commit to this issue’s fork.

mdranove → created an issue.

+1 for patch #13. also experiencing this issue.

@eiriksm, no problem! I get a strange satisfaction from sorting issues by oldest.

Made strings translatable, moving back to needs review.

mdranove → made their first commit to this issue’s fork.

post_update hook added.

mdranove → created an issue.

Should be good now, but I cant seem to get the test I added to the last commit to pass, although it looks fine to me.

Used twig to render link. Moving back to NR.

mdranove → created an issue.

mdranove → made their first commit to this issue’s fork.

This is going to need a rework of LinksFilterWidgetKernelTest.php as the test is not functioning correctly.

Currently, the test believes the "select all none" checkbox is checked for BEF links filter config by default and is looking for the "Any" link at the top of the list, even though in the test this is not specified and currently as discussed above the checkbox does not function correctly.

Maybe need to move this to a JS test.

mdranove → made their first commit to this issue’s fork.

Created draft !128 which fixes this.

Basically the problem is that there is an explicit logic check in core Views' FilterPluginBase.php preventing the "Any" link from being passed to the "options" array if the "multiple values" selection is made.

It looks like this

if ($type == 'value' && empty($this->always_required) && empty($this->options['expose']['required']) && $form['#type'] == 'select' && empty($form['#multiple'])) {
  $form['#options'] = ['All' => $this->t('- Any -')] + $form['#options'];
  $form['#default_value'] = 'All';
}

There is some nice code to workaround this for radios currently. What I have so far is pretty bare bones but gets the job done if you're just looking to get that link in the array out of the box.

mdranove → changed the visibility of the branch 7.0.x to hidden.

mdranove → made their first commit to this issue’s fork.

mdranove → made their first commit to this issue’s fork.

For me patch in #11 fixes the exception in SelectionPluginManager, but then leads to the exception described in #6.

I think this patch ought to be a temporary solution. Believe this is isn't necessary in d11.

I tried replicating this. Drupal 11, set a view to display only article nodes. In row style option set to display body field using grid row component and plain text formatter. Everything worked as expected.

Possible to share more information about your view configuration that might explain the exception?

mdranove → made their first commit to this issue’s fork.

Putting aside the question of "as designed" for now, seems like this is a deeper issue beyond just nested textfields.

I tested mr !122 with the suggested geofield module, and it's not able to add the "data-bef-auto-submit-exclude" attribute to the latitude/longitude fields because the type in the render array is set to "geofield_latlon" (see screenshot). The logic of the function relies on the "type" always being set to "textfield" or "entity_autocomplete" in order to apply the autosubmit exclude, but, as we can see with geofield, this is not always the case.

I think this should be handled by JS so that the actual type attribute of the <input> element itself can be checked for the type="text" or type="entity_autocomplete". See MR !123.

mdranove → made their first commit to this issue’s fork.

mdranove → created an issue. See original summary → .

mdranove → made their first commit to this issue’s fork.

mdranove → made their first commit to this issue’s fork.

Hello, I tried to reproduce with the following setup:

Forked from 2.x, Drupal 11, standard install profile, Claro admin theme, tour_core recipe.

Could not reproduce. Tour button behaves as expected.

Could you please share some more information about your setup? Maybe the admin theme?

mdranove → made their first commit to this issue’s fork.

mdranove → created an issue.

mdranove → made their first commit to this issue’s fork.

Tested with standard install on core 10.3.5.

1. Give Content Editor permissions “Add content and child pages to books and manage their hierarchies” and “Add any content to books”.
2. Login as Content Editor. Content Editor can add content of a permitted content type to a book.
3. Remove the permission “Add content and child pages to books and manage their hierarchies” from the user’s role.
4. Content Editor cannot add books to book outlines.
5. Give Content Editor the “View printer-friendly books” permission.
6. Content Editor can view and interact with the “printer-friendly version” link on book pages.
7. Take away the “printer-friendly” permission.
8. Content Editor can no longer see the “printer-friendly version” link.
9. Give the Content Editor the “administer book outlines” permission.
10. The Content Editor can update the outlines of book pages.

All works as expected. Moving to RTBC.