🇩🇪Germany @broon

We also noticed that openapi.json does not contain enum values for the allowed entity types and bundles.

"properties.data.items.properties.type.enum" should be set and contain the list of allowed reference types, ie. "node--my-first-bundle", "node--my-second-bundle", "taxonomy_term--my-vocabulary" and so on.

Patch from #2 was against 2.0.x, this patch is against stable version 2.0.0 (identical except for commit hashes).

broon → created an issue.

Just as a note for anyone looking into that change: By adding a sixth parameter to the widget class, this breaks functionality for modules extending Paragraphs, for example "Default Paragraphs".

Apart from the coding style issues, this MR resolves the problems for me when running PHPUnit tests on custom modules (requiring JWT functionality).

Seems like CKEditor is doing some cleanup. See the module overview page and the linked SO issue for an explanation why this structure was chosen. A span tag wouldn't be sufficient here as it is an inline element and may not contain block elements.

For compatibility with Drupal 11, this information #2442603 → should also be kept in mind.

We encountered this problem as well in an automated pipeline when installing VBO. Here is a simple patch for 4.2.6 to avoid the issue until the actual problem is solved.

Setting status to Needs Review in order to eventually get more automated fixes.

Sorry for taking so long and thanks a lot for your work (and creativity regarding the icon). Committed to 2.x now.

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

Thanks a lot!

Are there any news for this project? There seems to be no active release anymore, is this project abandoned? Has the functionality been moved somewhere else? I am a bit puzzled as I can't find any information about the current status.

The error lies within xdebug 3.3.0+ (published November 30th, 2023). Downgrading to xdebug 3.2.2 fixes the problem.

See also the related issue  https://www.drupal.org/project/drupal/issues/3405976 🐛 Transaction autocommit during shutdown relies on unreliable object destruction order Active

Here's also a patch from the MR for review.

broon → created an issue.

Sorry for being late to the after-work party. I did test it with my custom FormAlter plugins and it works like a charm, good job! If it wasn't fixed and already released in 1.6, I would give it an RTBC. ;)

I just ran into that error while trying to delete a translation. In the system, entity_language_fallback is enabled which eventually leads to more trouble. For example, with three languages set up (EN, FR, IT) and the language fallback for IT is FR instead of the default language EN, if you try to delete the IT translation the mentioned error appears.

If the user does not read the error message and just reloads the page, the delete form submit will run again and delete the next language in the fallback chain.

Adding the patch provided by ad0z in #2 fixes the error. From a functional perspective: RTBC.

I can confirm that adding the dependency by using a patch works and solves the problem.

However as Stefan points out, it's not directly related to paragraphs but I believe rather depends on the size of the form which in turn may lead to different order of loading required JS files. I also agree that the user should not be required to switch on some extra option to make it work for each RTF field. But adding the dependency for all is also not correct as there might be sites not using CKEditor at all.

Maybe, instead of having just a single library "maxlength", there ought to be additional ones like "maxlength_ckeditor" which should automatically be selected if the corresponding textfield is using CKEditor.

sanduhrs → credited broon → .

These are two different but related issues. This here is done, I will look into the other.

broon → created an issue.

broon → created an issue.

Thanks a lot for your effort. From a pure code perspective this looks fine. I'll test it and look for implications this might have (will take a few days).

Monolog requires "graylog2/gelf-php": "^1.2", latest version available is 1.71 which in turn requires psr/log 1.0 or 2.0 while Drupal 10 (core-recommended) requires psr/log 3.0.

Scrap that, working as designed. Due to an unmet dependency, my dev system was not updated to 10.0.10 as intended but rather to 10.0.0-alpha4.

I am not sure if I am missing something, but when using the patch from #16 or using the current dev version, I'll got the following error:

Fatal error: Class Drupal\hook_event_dispatcher\HookEventDispatcherModuleHandler contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (Drupal\Core\Extension\ModuleHandlerInterface::getImplementations, Drupal\Core\Extension\ModuleHandlerInterface::implementsHook) in web/modules/contrib/hook_event_dispatcher/src/HookEventDispatcherModuleHandler.php on line 15

The patch should take of the deprecation. However, on my local dev machine, the tests are skipped.

Alright, I'll take that as RTBC and will publish 2.2.2 soon. Thanks for your feedback!

Hey Elena, thanks a lot for the hint, that did slip my attention. I've already made a commit that adds a new option in the filter's settings (disabled by default). When enabled, check_markup will be run.

Please review if the new 2.x-dev version (otherwise identical to 2.2.0) works for you and solves the problem.

broon → created an issue.

Congratulations! Looking forward to the D10 version. ;)

I understand your intentions but is there any specific reason to drop support for Drupal 9.4+?

Just curious as we are currently in the process of preparing Drupal 10 upgrade for several sites using Hook Event Dispatcher and some already updated to Hook Event Dispatcher 4.0.0-beta1 (which was still supporting D9) and now can't update to rc1 without running D10.

For other site maintainers and developers getting here for the same reason, you can expand your composer.json requirement to something like "drupal/hook_event_dispatcher": "^3.3 || ^4.0" if you are still running HED 3.x and want to stay on stable versions.

Otherwise, "drupal/hook_event_dispatcher": "^4.0" should be fine. Composer will go to beta1 on D9 and only further if D10 is running.

This new foreach loop just accomodates for the different version of the same glossary term (like synonyms or capitalized term name at the beginning of sentences). There is no replacement happening at that point. I am unsure, what exactly is causing this if it wasn't happening before, maybe it was an uncaught (but welcome) error before.

As said above, the text filter is happening on the actual text of a text field. The filter is unaware of the entity that contains the text field. That's why it is not recommended to use Onomasticon filter on the glossary terms as it might result in circular references and ultimately in this issue's problem.

For Drupal 8+: https://www.drupal.org/project/link_context →

Such a recursive situation can be avoided if you enable a text filter _without_ Onomasticon for the description field of your glossary taxonomy (recommended). I am not sure if this module can actually solve such a situation on its own as it is a text filter.

Indeed. There are some alternatives to that.

I am not sure anymore, why we (need to) run "drush cr" first in our deploy script insertMemeHere("AtThisPointIAmAfraidToAsk"). But if it is important, you can add an extra step before running "drush cr" with Drupal Console:

drupal config:import:single --directory="config/sync" --file="core.extension.yml"

This command will only import the core.extension config and thus already enable flexible_permissions. After that, "drush cr" won't fail.

Well spotted! I probably did too many changes yesterday. ;)

Hotfix release 2.2.1 coming up.

Closing due to inactivity. Please feel free to re-open if there are steps to reproduce.

Support for Synonyms has been introduced in ✨ Glossary term synonyms/aliases Fixed .

I finally got to work on this again. It does work as expected, the only drawback is that I can't get the filter settings to be a list of checkboxes for selecting the vocabularies. The "onomasticon_vocabulary" can be an array, but as the vocabulary maschine names are not known in advance, the schema fails upon saving, with something like

InvalidArgumentException: The configuration property filters.filter_onomasticon.settings.onomasticon_vocabulary.glossary doesn't exist.

Anybody got an idea on how to fix that? Do I need to write a custom plugin annotation class?

I do see the problem, but I don't have a solution for that without hacking too much. The title attribute is for accessibility thus is no simple way to disable the tool tip in modern browsers for a specific tag.

Feel free to reopen if you got a clever idea on how to solve this.

Took a while, but it works now using the Synonyms module and the recommend installation procedure.

Can't reproduce that. Do you have an active HTML-Filter which restricts/disallows certain HTML-Tags?

Thanks for creating a new patch and sorry for taking so long.

🐛 Issue when < tag is used in text Fixed has been merged and should solve this, thanks João.

Thanks for the MR!

The issue is always present in (semi-)automated environments where a standardized install script is running.

Our script essentially does this:

composer install
drush cr
drush updb -y
drush cr
drush cim -y
drush cr
drush deploy:hook
drush cr

If you have i.e. Drupal 9.5.9 with Group 1.5 installed and the new package is pushed to the staged server, composer install will download flexible_permissions. But at this point it will still be disabled. By default, it will only be enable during "drush cim -y" when core.extensions.yml is read and imported.

However, that's to late as Group module already requires it during the update hooks. Thus, the first update hook actually installs the flexible_permissions module:

function group_update_9200() {
  \Drupal::service('module_installer')->install(['flexible_permissions'], TRUE);
}

Now, the point is, that the install script already fails before that, during the first run of "drush cr". As the Group module is already installed, a cache rebuild will import the *.services.yml files from all enabled modules. And inside groups.services.yml, the system will find this:

  group_permission.calculator:
    class: 'Drupal\group\Access\GroupPermissionCalculator'
    arguments: ['@flexible_permissions.chain_calculator']

But as flexible_permissions isn't yet enabled, it will fail to find that service.

With the above default install script, an update of Group 1.5 => 2.x is not possible within one delivery. The only solution I can think of is to put group_permissions into a new submodule which will then be enable alongside flexible_permissions.

I've taken the approach from #8 and turned it into a patch for GInvite 3.0.0-beta3.

As for the question about making autoAccept an option, I would prefer an option per invitation, but make the default value (on/off) an option of the group instance.

Re-roll patch #12 against 3.0.4

I can confirm the behaviour on Drupal 9.5.9 with MaxLength 2.1.1.

Counter information is *below* the text field for plain textfields and textareas, but *above* for formatted long text (CKE 5).

MR#35 from comment #3 is fixing the issue for me.

I was running into this problem a few weeks ago, but I was puzzled as maxlength was activated for three fields and only working for two of them. Only if I disabled maxlength for the two working ones, it started to work for the third field. Through this issue I figured, that my specific form's size might be very close and above to the threshold to trigger that error.

Implementing the patch from #4, it now works for all three fields
(using Maxlength 2.1.1 on Drupal 9.5.9).

Joachim Namyslo → credited broon → .

broon → created an issue.

Patch #5 works fine, please commit to module repo.

It's not really a duplicate imho. The referenced issue is about removing disabled methods from the documentation. However, if a resource is disabled altogether, its model will still show up in the doc, potentially disclosing internal structure of various types.

Thanks for the idea and MR.

Here's a patch that reverts the introduction of the "has-menu" check. This is not a final solution but works fine in conjunction with the patch in https://www.drupal.org/project/drupal/issues/2135445#comment-13003616 → to show the admin toolbar for users without admin permissions.

Also, this happens for users who may see the toolbar but are not admins as they will see the "Manage" tab although it has no items. Thus, the menu is not really existant.

See #2135445: Toolbar displays Manage tab even if the user is not permitted to see it →

This issue was introduced by committing the patch in #3257504: Empty toolbar tray displays a stray orientation toggle → .

If you remove the .has('.toolbar-menu') part from Core again, you'll have the buttons back (but also a stray button if there is no menu at all).

Closing as Drupal 7 is outdated.
If required in Drupal 10, please open a new issue.

Contained in Onomasticon 2.1.0

Unable to reproduce on Drupal 9.5.4, can you provide more info, especially the description of the term where it fails?

Not required for D8 version.

Tested it again on a clean install using Drupal 9.5.4, please re-open with proper instructions.

I tested this on a clean install using Drupal 9.5.4 and couldn't recreate the issue. When adding your HTML code and set the configuration as described, neither occurrence of "TERM" is served with a tool tip.

I am closing this as "works as designed" because of the original purpose of this module. If you do get time to work on your patch, I am happy to review. My suggestion would be to add a third option besides "Extra element" and "Title attribute", ie. "Accessibility first" (or similar).

Seems to work fine for both CKE 4 and CKE 5. Thanks for providing a solution!

Maybe this could be generalized to also include field types that extend the default "entity_reference", for example it would be nice to work for "dynamic_entity_reference" as well (see Dynamic Entity Reference → module).

In issue ✨ Add support for field types that extend default entity_reference Needs review , I already provided a new patch that enables this module's functionality for such field types by not checking against "entity_reference" but its or its parent's class.

Here is a patch that not only works with dynamic_entity_reference fields but all fields that extend the default entity_reference field. Thus, I am also changing the issue summary (sorry for hijacking, taggartj, but your case is included).

Btw. the patch is incomplete as it only patches the field config form. This will add the purge option to dynamic reference fields. However, this option is only read for "entity_reference" fields in the entity_reference_purger_entity_delete function.

In fact, could this also be used on field types that extend the default entity reference field? In various projects, we are creating custom entity reference fields, that add new functionality, like

class LabelledEntityReference extends EntityReferenceItem

offers an Entity Reference Field, but the editor can choose a custom label to refer to the referenced node. As this field type's machine name is of course not "entity_reference", this module does not offer an option.

So, instead of checking the machine names, isn't possible to get a fields base class and then decide whether or not to offer the purge option?

Thank you for your input. I am actually aware that the default way Onomasticon is using HTML elements is not proper and there is even a paragraph on that in the module's description page with a link to the discussion leading to the decision made: http://stackoverflow.com/questions/40531029/how-to-create-a-pure-css-too...

To summarize, it was requested to create a CSS-only solution which is able to include rich text in the term's description (including images).

I am open to patches that add an accessibility option but I will not change the default behaviour unless there is a better option that satisfies all requirements.

I can confirm both issues.

(1) If set to 0, no files are shown.

(2) If set to 250, only the one file directly in "public://" is shown, the other 682 files in subdirectories are not listed.

(3) If set to 1000 (which is larger than 683), all 683 files are listed.

(4) Patch #9 resolves both (1) and (2).

Good and useful addition, working fine.

The culprit is in the usage of orConditionGroup(). The attached patch fixes that.

There are two issues here, both related to the generated queries.

First is, that the module generates one query per entity type and adds _all_ eligible fields from _all_ available bundles. However, the table JOIN is INNER and thus it could only work like that on bundles that contain _all_ WYSIWYG fields. This should be changed to LEFT JOIN.

Secondly, the WHERE clause also checks _all_ eligible fields of that entity type and concats them with AND. This should be changed to OR.

With both of these changes in SQL, I was able to correctly find occurrences of my unmanaged files.