🇹🇷Turkey @makbay

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

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

No @hatuhay, that's not how things work.

You should check the box beside my name at the bottom of this issue and hit Save.

No @hatuhay, that's not how things work.

You should check the box beside my name at the bottom of this issue and hit Save.

@hatuhay, please do not forget to give credit.

@hatuhay, please do not forget to give credit.

Thanks a lot for diving into this in such depth! Your explanation really helped me understand what’s going on under the hood.

The difference caused by Unicode's handling of capital "İ" and its decomposition into "i" + U+0307 is indeed something I hadn’t realized before. The link to CaseFolding.txt and the idea of using mb_convert_case(..., MB_CASE_LOWER_SIMPLE) makes a lot of sense. I wasn't aware that this flag avoids locale-specific casing rules in a more consistent way, and it sounds like a safer path forward given the intl extension constraint.

If the results from your test script look promising, I’d be happy to create a merge request for this and help move the discussion forward

Thanks again for your insight and support!

@ghost of drupal past

MariaDB [db]> SELECT VERSION();
+------------------------------+
| VERSION()                    |
+------------------------------+
| 10.11.11-MariaDB-ubu2204-log |
+------------------------------+
1 row in set (0.000 sec)

MariaDB [db]> show full columns from node_field_data where field='title';
+-------+--------------+--------------------+------+-----+---------+-------+---------------------------------+---------+
| Field | Type         | Collation          | Null | Key | Default | Extra | Privileges                      | Comment |
+-------+--------------+--------------------+------+-----+---------+-------+---------------------------------+---------+
| title | varchar(255) | utf8mb4_general_ci | NO   | MUL | NULL    |       | select,insert,update,references |         |
+-------+--------------+--------------------+------+-----+---------+-------+---------------------------------+---------+
1 row in set (0.002 sec)

Why would you ignore other people's contributions and haven't given credit to them?

makbay → created an issue.

Base color equals to body color. It makes the heading colors equal to the body color, in another words, does not change the heading colors.

There is another bigger problem that I have just discovered and resolved here:
https://www.drupal.org/project/bootstrap_barrio/issues/3522986 🐛 Incorrect logic in _get_color() causes color values useless Active

makbay → created an issue.

I'd like to propose a small but important change to improve clarity in the color scheme settings UI.

Currently, the form uses the labels for the color fields:

• Primary base color
• Secondary base colo

Meanwhile, when choosing colors for headings (H1, H2, etc.), we are presented with options like:

• Base color
• Primary color
• Secondary color

This inconsistency causes confusion. Users are left unsure whether Primary base color corresponds to Primary color, and what Base color refers to at all.

Suggested fix:

• Rename "Primary base color" to "Primary color"
• Rename "Secondary base color" to "Secondary color"

This change would align the labels with the options in the dropdowns and provide a more intuitive experience.

makbay → changed the visibility of the branch 3287144-automated-drupal-10 to hidden.

makbay → changed the visibility of the branch 3287144-2.1-automated-drupal-10 to hidden.

Merged into 8.x-2.x.

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

Patch works. Thanks!

Yeah, I also switched to that one eventually.

@dydave I tested with both patches applied on Drupal 11.1.6

There is another thing to be resolved, see attached image.

makbay → created an issue.

Same here, I have tested the patch from MR17 over 8.x-1.x-dev. It works fine.

Attaching the patch here for convenience.

I have checked the patch from @mark_fullmer's MR over 8.x-1.x-dev along with composer-drupal-lenient plugin. It works fine on D11.1.6.

Attaching the patch here for convenience.

A new branch should be created for D11. I really like and use this module a lot, I'm happy to assist if anything is needed.

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

makbay → changed the visibility of the branch 5.5.x to active.

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

makbay → created an issue.

Patch #2 does not work.

yearonly 9.1.2 & Drupal 11.1

Works fine for me. Thank you.

makbay → changed the visibility of the branch 3494200-Needs-Dedicated-D11-release to active.

I have created another branch, that should not be merged to 8.x-1.x: https://git.drupalcode.org/issue/audiofield-3494200/-/tree/3494200-Needs...

I'm afraid we need to create a dedicated release for D11.

LibraryDiscovery class is deprecated with D11.1

https://www.drupal.org/node/3462970 →

Thanks @kreynen!

Why don't you release a version that supports D11?

Still waiting for them to reply?

makbay → created an issue.

I guess I just enabled the Paragraphs Library @shasha821110.

Works as expected

Thank you so much, @kreynen! I was starting to lose my motivation to contribute due to the maintainership process, but your message truly made my day. I really appreciate your willingness to step in and help keep this module alive.

If you take over the project, I would be more than happy to collaborate with you to get it cleaned up and fully compatible with Drupal 10 & 11. Looking forward to working together!

@avpaderno, could you help with the necessary steps to proceed?

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!