🇮🇳India @anandhi karnan

I was unable to reproduce the issue based on comment #11 in Drupal 10.3.x and 11.x.

I followed these steps:

1. Installed Drupal 11.x
2. Enabled the Languages and Content Translation modules.
3. Added the French language under /admin/config/regional/language.
4. Created a node that uses the second language.
5. Removed the second language from the site (/admin/config/regional/language).
6. Returned to the node view page that had been created.

I am attaching a screen recording of the testing in Drupal 11.x. I followed the same steps for Drupal 10.3.x, but I was unable to reproduce the issue.

Please let me know if I am missing anything here.

I was able to reproduce this issue in Drupal 11.x.

Here are the steps I followed:

• Language and Content Translation modules are enabled.
• Multiple languages have been configured under Configuration > Regional and Language > Languages.
• Navigation to Configuration > Regional and Language > Content language and translation was done to enable translation for the content type.
• A content item with a date field was created and published.
• The content was translated into the second language.
• Navigated to the page displaying the content.
• Observed that "ago" and "in" in the timestamp format are untranslated.

I have created a merge request (MR) against Drupal 11.x. Please verify.

Thanks

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

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

Hi

I have created tests to report the bug. Please review it.

Steps to reproduce

• Add a new field. Set it to multiple values and mark it as required.
• Create a Node and enter the values for the multi value field

1. Value 1: foo
2. Value 2: bar
3. Value 3: baz

• Save the node
• Edit the node, empty the first value 'foo'
• Click Save to submit the edited node.
• You should see an error message indicating that the first text field is required.

Thanks!

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

Hi

I tried to reproduce the issue (TypeError: Illegal offset type in Drupal\taxonomy\Form\OverviewTerms->submitForm()) in Drupal 11.x but was unable to replicate it. I have attached a screen recording for reference.

Here are the steps I followed:

• Navigated to admin/structure/taxonomy.
• Clicked on “Add vocabulary”.
• Entered a name for the new vocabulary and saved it.
• Accessed the newly created vocabulary.
• Clicked “Add term” to create several terms within this vocabulary.
• Went to the overview page for the vocabulary at admin/structure/taxonomy/manage/{VOCAB-ID}/overview, where {VOCAB-ID} is the ID of the vocabulary.
• Tried to reorder the terms by dragging them or using any available UI controls.
• Saved the changes by clicking the “Save” button.

I have updated the serializers to handle failure scenarios more robustly:

PHP Serializer (PhpSerialize):

• Added exception handling for unserialization errors.
• Incorporated the allowed_classes option to enhance security and prevent unserialization of objects.

JSON Serializer (Json):

• Implemented exception handling for JSON encoding and decoding, including handling invalid JSON and circular references.

Testing:

• Added tests to verify correct behavior for both valid and invalid inputs, covering various edge cases.

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

Hi @sam152

I am currently analyzing the ticket regarding content moderation and entity revisions. To ensure that I address the requirement accurately, could you please clarify the following points:

1. Revision Creation Criteria: What specific criteria should be used to determine when a new revision should or should not be created for content? For instance, should revisions only be created when certain fields are changed, or is there another criterion?
2. Non-Syncing Content Definition: Can you provide more details on what constitutes "non-syncing content" in this context?
3. Preferred Approach: Are there any existing solutions or approaches that are recommended for handling this issue?

Understanding these points will help me make the necessary adjustments to avoid unnecessary revisions and improve content moderation.

I have tested the provided patch #18 🐛 Unable to add content to a content type named 'type' Active and can confirm that it resolves the issue as described. The problem no longer occurs in Drupal 11.x
Thank you for the patch!

@smustgrave The warning "Undefined array key '#access'" is difficult to reproduce in environments where the #access key is consistently set. Consequently, the warning does not typically manifest under standard conditions. However, it is important to address this issue to adhere to strict coding standards and ensure robust error handling.

merge request !11for backporting

MR for Drupal 11.x

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

I have hidden the branches that were created from the incorrect version. The actual fix for this issue can now be found in Merge Request 10. Please review that merge request for the correct updates.

anandhi karnan → changed the visibility of the branch 3425694-elastic_enterprise_search to hidden.

anandhi karnan → changed the visibility of the branch 3425694-elastic_enterprise_search_index_issue to hidden.

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

Revised patch for autosave fix

Autosave fix for CKEditor5

anandhi karnan → created an issue.

Rerolled patch for compatibility with version 8.x-3.0-rc11.

Anandhi Karnan → created an issue.

Anandhi Karnan → created an issue.

Anandhi Karnan → created an issue.

Fixed test failures, please review.

Please ignore this issue, created for testing purpose only.

Anandhi Karnan → created an issue.