@mdranove

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.

Based on the patch, added new addNodeToBook() helper method to BookTestTrait.php. Updated a couple of tests to use new addNodeToBook() helper method and replaced existing testing steps that produced the same result by editing the node form through separate steps.

Searched for other instances of the old submitForm() code in the test folder. Found one more similar usage in the testBookDelete() BookTest.php, but this doesn't seem to be something that is a 1:1 replacement with the new method so left it alone.

Moving to NR.

Potential testing steps:

1. In BookTest.php debug the value that is set to $edit[‘book[bid]’] in both testBook() and testBookOutline().
2. In BookTestTrait.php, debug the value that is passed in as the $book_nid.
3. The integer values should match.
4. Repeat same method with BookContentModerationTest.php, comparing $book_2->id() and $book_1_nodes[1]->id() with the values that end up getting passed to the trait.

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

Repro steps.

Drupal 10.3 standard install profile.

1. Have a published book and basic page.
2. Enable content moderation workflow and add basic page and book content types to the editorial workflow.
3. Give content editor role the create_new_draft, Add non-book content to outlines, and create new books permissions. Do not give them "Add content and child pages to books and manage their hierarchies."
4. Login as content editor. Attempt to save as draft.
5. Error message prevents save: "You can only change the book outline for the published version of this content."

Testing steps.

same setup as above.

1. Still logged in as a content editor, attempt to save the same nodes as step 1 in the repro steps.
2. The nodes save as expected.
3. Give the content editor access to the published transition.
4. Edit the nodes and add them to a book outline and change the state to "published".
5. The nodes save as expected, and the nodes are added to the books.

Moving to RTBC.

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

Tested on Drupal 10.3 with standard install profile (claro admin theme).

From what I see, this mostly works, but not totally. Explanation below.

Testing steps:

1. Created a book with a child page and children for that child page.
2. Added "administer book outlines" and "Reorder child page of a book" permissions to a role.
3. Logged in as a user with the role from step 2 and navigated to /node/{node_id}/child-ordering.
4. Tried to reorder the items by dragging and dropping.
5. The drag and drop doesn’t work as expected. You can reorder the items, but only by dragging the item you want to move to the left, not up or down. (see screenshot).
6. Changing row weights manually does work as expected.

Moving back to needs work.

When you enter the menu, Changing row weights manually works np.

Reviewed on drupal 10.3 setup with standard install profile.

Testing steps:
1. Ran drush updb.
2. New book navigation field appeared in default and teaser display modes.
3. Moved around book navigation field, worked as expected.
4. Enabled layout builder.
5. Moved around book navigation field on a book node. Worked as expected.

Moving to RTBC.

mdranove → changed the visibility of the branch 3204406-add-sibling-button to active.

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

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

mdranove → created an issue.

mdranove → changed the visibility of the branch 3258863-minor-multilingual-function to hidden.

Updating version to 2.x

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

I ran a git merge with this branch onto 2.0.x and didn't get any conflicts. Tested in a vanilla and Search API view, worked as expected.

Yes disregard #15.

Everything in #11 worked as expected except for the translation of the reset link. Think it also needs a |t filter in the twig.

I've made that small addition in this patch.

Updated MR to fix eslint issues in addition to phpcs.

Moving back to Needs Review.

Reviewed by running
phpcs --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml views_filters_summary against this branch.

Confirmed no issues found. Moving to RTBC.

Cannot reproduce on 2.x.

Moving to closed.

This module creates a block visibility configuration for books. This means site managers can scope blocks in the block config to one or more books.

https://www.drupal.org/project/book_visibility →

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

Yes I do think this is a critical issue, still active. Last and current project still have same exact problem.

I wanted to post again to try to be more succint and to describe it from the content manager's perspective.

Assume you have two languages, EN and ES, you have workflows, moderation states, translatable entities, etc:

1. Save a draft of a node in EN.
2. Save a draft of the same node in ES.
3. Publish the ES draft.
4. Content manager no longer has access to edit the EN draft in step 1, because it is no longer the "latest revision". They can still see this draft in the revision history but it's not editable. They essentially lose all their work.

Hope this helps.

mdranove → created an issue.

mdranove → created an issue.

mdranove → created an issue.

mdranove → created an issue. See original summary → .

Created Untranslated Paragraph Warning → module to mitigate this problem. Need to use it in conjunction with some custom twig as described on project page.

I know you can already get some logic together in your twig templates to hide untranslated paragraphs. Also #4 looks interesting, That being said, the next time the translation of the node is saved those paragraphs are going to be classified as translated by Drupal, even if they were not touched. This module detects those untranslated paragraphs and displays a warning message at the top of the node edit form.