🇹🇷Turkey @makbay

Database is 10.3.39-MariaDB.

No, contrib modules are also installed.

makbay → created an issue.

No worries and thank you =)

Thank you and could you please give the credits for people that have tried to fix this?

The MR should resolve the issue. Here is a patch.

makbay → changed the visibility of the branch 3377861-php-undefined-array to hidden.

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

I think it's about this:

Call to deprecated method loadRevision() of class               
         Drupal\Core\Entity\EntityStorageInterface:                      
         in drupal:10.1.0 and is removed from drupal:11.0.0. Use         
         \Drupal\Core\Entity\RevisionableStorageInterface::loadRevision  
         instead.   

I had on tests for a similar issue here: https://www.drupal.org/project/drupal/issues/3201209 🐛 Hook presave does not set original correctly when editing non-default revision entities Needs work

https://git.drupalcode.org/issue/drupal-3201209/-/pipelines/97456

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

makbay → changed the visibility of the branch 9.2.x to hidden.

Thanks for the MR and patch but this is still working incorrectly when the latest saved entity is the default version.

Since the patch is checking if the latest version is default or not, in case the latest revision is default (published), the $entity->original again gets the previous default (published) revision instead of the latest revision.

Steps to reproduce after patch

1. Enable the Workflows module
2. Add Basic Page as applying to the 'Editorial' workflow
3. Create and move a basic page through the workflow to published, then set to draft
4. Finally, edit the non-default revision (draft) basic page again and set it to ready for review
5. In a presave hook, $entity->original will be set to the published revision instead of the draft revision.
6. Publish the basic page again.
7. Create a new non-default revision (draft). The patch is ok for now, $entity->original will be set to the published version.
8. Create another new non-default revision (e.g in review) after the published one. The patch is still ok, $entity->original will be set to the draft version on the previous step.
9. Now publish the basic page. The patch will not work here since there is !$entity->isDefaultRevision() check in the condition and $entity->original will be set to the previous published version on step 6.

So, I think we need to remove !$entity->isDefaultRevision() check from the if block.

I'll create another MR for this.

I also noticed this on 10.2.x site and the patch fixed it.

I can also confirm that this happens for Turkish characters.

All of my tables and database are collated as utf8mb4_general_ci

Just came here from: https://www.drupal.org/project/webform/issues/3415445 🐛 Search Chinese in /admin/structure/webform cause error: Illegal mix of collations Closed: duplicate

I can confirm the MR resolves the issue.

For me it was not about the bulk operations. The exception was appearing when I go to the results page of the webforms. But the diff has resolved this.

I can confirm the diff resolves the issue. Drupal 10.1.7 & PHP 8.1

makbay → created an issue.

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

I can confirm the patch is ok, tested on Drupal 10.1.7 and 10.2.0

makbay → created an issue.

MR is created for the patch.

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

makbay → changed the visibility of the branch 3150991-elastic-search-not to hidden.

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

Suggestions are applied.

I have created a similar issue to the original issue and noticed the change of CLDR json publishment there:

https://www.drupal.org/project/drupal/issues/3395852#comment-15285830 📌 Update the countries list to latest Unicode CLDR version 44 Fixed

This is the most recent way to get the json:

- Choose the main branch on repository https://github.com/unicode-org/cldr-json
and download the territories.json file inside the directory cldr-json/cldr-localenames-full/main/en
e.g. https://github.com/unicode-org/cldr-json/blob/main/cldr-json/cldr-locale....

Never mind this. The dependency is coming from the Paragraphs Library module, which is not properly installed on my setup.

makbay → created an issue.

This is a major one. I have updated the MR for 11.x.

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

The issue I have created for D10/11 is just committed. Now we may consider committing this one.

📌 Update the countries list to latest Unicode CLDR version 44 Fixed

MR is updated for 11.x

makbay → created an issue.

makbay → created an issue. See original summary → .

makbay → created an issue.

Actually I ran the script on a D9.5 site and copied the output from there.

Seems we have another issue here.

@cilefen, hope it's ok now. Please feel free to change the title and/or issue summary in order to make this go through. Contributing should not be this hard and discouraging.

Attached is the latest list from CLDR.

Actually, the way that CLDR publishes the json is also changed. I'll be also creating an issue to fix the description text inside the update-countries.bash

I have created the issue for D9/10 so this can be closed now I guess.

Hi @cilefen,

You're right. Now the list is fully updated including a new country called Sark. Greetings from Türkiye to all the people of Sark :)

Coming from ✨ Permission for viewing active domains Closed: duplicate and I have closed it in favor of this issue.

Well, actually in my case, we have an entity reference field referencing to domain entities in a content type. While using this field in a view to create a link to the referenced domain, non-admin users is not allowed to see the link or referenced domain entity. Please see the image below.

Oops there is another issue open that describes the need better. I'm closing this and will continue working there.

https://www.drupal.org/project/domain/issues/3332327 ✨ Show Domain Access field without 'view domain list' permission Active

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

Well, actually in my case, we have an entity reference field referencing to domain entities in a content type. While using this field in a view to create a link to the referenced domain, non-admin users is not allowed to see the link or referenced domain entity. Please see the image below.

I don't think that we need a default block implementation at the moment. I'll try to update he patch and MR.

makbay → created an issue.

I can confirm that we have 2 separate fields for singular and plural translations and it works!

makbay → created an issue.

@TwoD

I tested your commit. It's removing all the items instead of removing the one that should be removed.

Same here. Actually $field_state['removed_item_id'] does not exist.