@mdranove

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.

Regarding #19 🐛 Content moderation workflow changes against one language affect translations too Needs work

We are also experiencing an issue at random, I believe it is what you are referring to. Moving translated content through content moderation workflow sets the current published default language material to not published seemingly at random. This is obvious on our site as there is a contextual filter set to create anchor links to paragraphs on each node. Occasionally a node will have its default status set to unpublished because multilingual content is being moved through workflow. Still trying to determine exactly what set of parameters triggers this.

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

@apaderno,

Thank you for the feedback, I have gone ahead and merged the most recent changes into branch 1.1.x.

Drupal 10 compatibility is included in release 1.1.4.

Hello, thank you for the feedback.

Feedback has been incorporated into release 1.1.4 → .

Validation for taxonomy terms is not supported yet, but will take it into consideration for the future.

1. You can simply use MODULENAME_form_node_form_alter() here.
2. I'm pretty sure that entity can be retrived with $form_state->getFormObject()->getEntity() here.
3. If you use setErrorByName() method you should provide the actual form element key for the first parameter.
4. In case when $original_alias == $alias your method returns nothing (void). You might consider the approach when your method ends with return $original_alias != $alias; so you won't need to use isset() in the validation function.
5. I belive you would like to change the class description :)

Thanks for the feedback @a.kovrigin. I have incorporated some of your suggestions on release 1.1.3 → , but not all. Response below:

1. I don't think this will work as form IDs change per content type.
2. Tried this, but it did not work consistently.
3. I have updated setErrorByName()
4. I have updated this logic based on your suggestion
5. Yes :). Thank you.

1. Remove the LICENSE.txt file. The LICENSE file isn't necessary. It will be added automatically by the packaging script.

2. Replace README.txt with README.md file. Please take a moment to make your README.md follow the guidelines.

Tagged and released v1.1.2 with the following:
1. Removed license.txt
2. Replaced Readme.txt with Readme.md based on drupal guidelines.

Hello Vishal, all errors have been fixed on newly tagged release 1.1.1.

1 warning remains, intend to leave as is:

FILE: /Users/mikdrano/dev/drupal-testing-two/web/modules/contrib/unique_alias_checker/src/Form/UniqueAliasCheckerSettingsForm.php
---------------------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
---------------------------------------------------------------------------------------------------------------------------------
 38 | WARNING | Only string literals should be passed to t() where possible

mdranove → created an issue.

Hi there,

uswds 2.1-rc1
drupal 9.4.11

mdranove → created an issue.