🇹🇷Turkey @makbay

Hello, I have tried everything to reach the maintainer, but had no responses. I'm willingly interested in maintaining this project.

As a work around, maybe you can implement hook_ENTITY_TYPE_access()</a> in a custom module:

/**
 * Implements hook_ENTITY_TYPE_access().
 */
function YOURMODULE_flagging_access(EntityInterface $entity, $operation, AccountInterface $account) {
  if ($entity->getFlagId() === 'your_flag_id' && $operation === 'view') {
      ... maybe some other logic ...
      return AccessResult::allowed();
  }
  return AccessResult::neutral();
}

makbay → created an issue.

PR: https://github.com/goalgorilla/open_social/pull/4251

makbay → created an issue.

Wow, this is wild! For a workaround just duplicate the value: 0 and its label, change them to the desired values in the field storage config file and re-import it.

E.g.

settings:
  allowed_values:
    -
      value: 0
      label: 'Existing label for value 0'
    -
      value: 1
      label: 'New label for new value 1'

The latest patch successfully checks if there is another entity with the same field value but does not prevent saving the new entity.

makbay → created an issue.

Please provide some more context, screenshots, steps to reproduce etc.

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

Thanks for the fix. Seems OK.

makbay → created an issue.

I'll try to reach the maintainer and request for a co-maintainer role.

I'll refactor this shortly.

makbay → changed the visibility of the branch 8.x-4.x to hidden.

makbay → changed the visibility of the branch 3401111-editing-removing-specific-flagging to hidden.

makbay → created an issue.

makbay → created an issue.

Thanks guys!

Thanks guys!

This is also needed for 2.x

Why don't you credit people that has contributions in the issues? Why do you take all the credit yourself?

For me, the reason was the encoding of a .module file of a custom module. It was set to UTF-8-BOM. After changing it to UTF-8 without BOM, the ajax errors are gone.

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.