Account created on 13 January 2012, over 13 years ago
#

Recent comments

🇭🇺Hungary nagy.balint

I guess it is best to commit this here.

Thanks!

🇭🇺Hungary nagy.balint

Hello!

14 day passed.

I am still interested.

🇭🇺Hungary nagy.balint

Moved it to Drupal.org project ownership as 1 month has passed already.

🇭🇺Hungary nagy.balint

Not yet unfortunately.

I will move it to the project ownership queue.

🇭🇺Hungary nagy.balint

Since the common practice is to create a new branch when we drop compatibility for major versions of Drupal,
I am pretty sure that defining core version as >=10 is not a good idea,
as we also know that this module will become incompatible with either Drupal 12 or Drupal 13, when the hook system is deprecated for example.

So it is better to define the compatibility the normal way
core_version_requirement: ^10 || ^11

🇭🇺Hungary nagy.balint

Message sent via contact form to @adcillc at 20th of July 2025.

🇭🇺Hungary nagy.balint

I think this is an outdated issue at this point.

🇭🇺Hungary nagy.balint

Can you provide more details on how I could reproduce the issue?

🇭🇺Hungary nagy.balint

From the formatter definition

 * @FieldFormatter(
 *   id = "image_url_formatter",
 *   label = @Translation("Image URL Formatter"),
 *   field_types = {
 *     "image"
 *   }
 * )

This module currently only supports image field.

🇭🇺Hungary nagy.balint

I think the gitlab ci file was not according to standards in the merge request, so I put in the correct one.

Also it is time to switch to the semver version, especially as we change the drupal core requirement to 10 and 11, then usually we would create a new branch anyways.

This is now fixed on the 2.0.x branch.

🇭🇺Hungary nagy.balint

I sent a message via contact form to @howard ge at 14th of July 2025

🇭🇺Hungary nagy.balint

Ok, thanks!

@nwom, Hi! Then likely we need to close this issue, as we surely do not want to officially mark the module unsupported for weeks.

It seemed that there was a way if the module became abandoned to then quickly promote a new maintainer, but then it seems it is not possible.

So I will need to create a new issue and start over the 2 week period unfortunately.

🇭🇺Hungary nagy.balint

The 5.x branch is also available where we have a Vanilla JS version of Chosen, and there are already some accessibility fixes there, but we can add more: https://github.com/noli42/chosen
https://www.drupal.org/project/chosen/releases/5.0.2

I think that going forward mostly the 5.x branch will be maintained,
as to me it seems problematic that we need to add extra JS for things that should really be in the library itself.

🇭🇺Hungary nagy.balint

Hi!

It is https://www.drupal.org/project/image_url_formatter

I guess whichever solution gives us the shortest wait time. I guess if the project is marked abandoned then we don't need to wait another month?

🇭🇺Hungary nagy.balint

I sent a mail via the contact form to @tamerzg at 10th of July 2025.

🇭🇺Hungary nagy.balint

I sent a message via the contact form to @sudishth at 10th of July 2025

🇭🇺Hungary nagy.balint

Hi!

I can join as co-maintainer.
While I have no contributions on this project personally, but you can check my profile as reference for other projects.

We used the project on one of our sites, and I could help pushing out a D11 compatible release.

🇭🇺Hungary nagy.balint

Just marking 🐛 Weird updating issues with the dev version Active as duplicate, as likely my issue was the same as here.

🇭🇺Hungary nagy.balint

I sent an email via contact form to @dave reid at 3rd of July, 2025.

🇭🇺Hungary nagy.balint

Switching to the OOP Hooks would require quite a big jump in Drupal core requirement, and so would likely be a new branch.

I would not mix these together, as parts of the module in the currently supported branch does not work currently, and so it requires this quickfix.

🇭🇺Hungary nagy.balint

I can confirm that the patch in #2 fixed the issue.

I would argue that this is a critical issue since in its current state the node submodule does not do anything.

🇭🇺Hungary nagy.balint

I share the patch file, since I have it already anyways.

🇭🇺Hungary nagy.balint

I am not sure if the latest version of the module is used, since

$paragraph = $parent->getEntity(); is at line 80, and not 64.

Can you check if there is a dblog entry with an error message when this happens?

Are you using the "Mercury Editor" module or it is only a normal install and the edit page of a node?

I tried but could not reproduce it on my site.

🇭🇺Hungary nagy.balint

Just wanted to note here that this is the only module blocking one of our sites to move to Drupal 11.

Sure I can make a fork in github, but would be much better if it was not needed.

🇭🇺Hungary nagy.balint

In fact #8 not only fixed the issue, but also brought back the translate option in the menu admin (/admin/structure/menu/manage/main) which was missing after the module upgrade.
So it actually made it translatable again.

🇭🇺Hungary nagy.balint

Just to report that I got this same issue yesterday on a site that we are maintaining for a long time.
"The "entity:menu_link_content:main" plugin does not exist. "

So the issue definitely happens often (at least on existing sites).

🇭🇺Hungary nagy.balint

Thanks!

Sorry #6, but that comment was a bit confusing to me so I cannot add that as a credit.

🇭🇺Hungary nagy.balint

Not sure if the following patch is enough, but we will see.

🇭🇺Hungary nagy.balint

Originally the webform component was based on the webform date component, but it had a lot of unnecessary fields and settings.
I was unaware of that feature, I will have to check what can be done.

🇭🇺Hungary nagy.balint

Just an update.

After some more review it seemed that the formatter that was in the Commerce Registration module is basically the same as the one in the Registration module in the new version at least.

So I inherited from the Registration module and then it started to work, however I still had to patch the formatter in the Registration module because there are new conditions now that was not there in the past like that the user needs to have permission to create a registration entity to see the button.
This is only an issue because the idea was that anonymous user sees the button, and then it goes to a login screen.

However I was thinking that maybe an empty class that inherits everything from the main Registration module could work to avoid the error for others. But it is true that due to the condition changes it won't be perfect.

🇭🇺Hungary nagy.balint

Thank you for the workaround!

Since I would prefer not to enable the source editing for basic html, this is the only solution for now.

🇭🇺Hungary nagy.balint

Thank you again,

It seems the issue is that this site I took over actually extended this plugin.

I will see if I can add back the plugin in custom code.

🇭🇺Hungary nagy.balint

Thank you for the quick reply!

Unfortunately cache clear did not help, but I will have time to check tomorrow, to see what more information I can provide.

🇭🇺Hungary nagy.balint

Hi!

This would need to be configurable in the settings of the module.

🇭🇺Hungary nagy.balint

Hi!

Since drupal 10.2 goes unsupported in 2 weeks, and the views module is just an optional submodule,
I guess at this point we will just change the requirement to 10.3.

🇭🇺Hungary nagy.balint

Thanks for the report and the patch, but I am afraid the fix is not 100% correct.

The defaultDate for me is always the same. So when I actually set two dates then on edit both date will be the same, even though item.value contains the right value.

I think the issue is somewhere in the DateTimeRangeFlatPickrWidget formElement method,
that $element['value']['#attached']['drupalSettings']['datetimeFlatPickr'][$name]
the $name is likely the same for each item in the multivalue form so the settings are overriden.

🇭🇺Hungary nagy.balint

#5 I think you mean the merge plugin which uses the libraries.json, that also requires some manual setup, it might work with this module as well although i have not tested it yet.

Otherwise the dropzonejs module's readme recommends the same repository entry approach as this module, so there really isn't much of a difference.

As far as I can see.

🇭🇺Hungary nagy.balint

Yes unfortunately if we simply put it in the module's composer file, composer will install it in the wrong directory.

Drupal core could solve this issue globally, but as far as I know they did not yet.

There are numerous workarounds with each having some manual steps.

🇭🇺Hungary nagy.balint

Hi!

You can apply chosen in the admin/config/user-interface/chosen page
by using the
"Minimum number of options for single select"
"Minimum number of options for multi select"
"Minimum number to show Search on Single Select"
and
"Apply Chosen to the following elements"

Also chosen module has a dependency on chosen_lib, so you cannot install it without (as can be seen at chosen.info.yml):
dependencies:
- chosen:chosen_lib

as for composer, you can find instructions on how to install chosen lib with the composer repositories section.
at the "Installation with repository entry:" section of the Readme

🇭🇺Hungary nagy.balint

Any chance of getting this committed?

I have this issue now on two sites and in both cases it fixes the issue.

🇭🇺Hungary nagy.balint

Hi!

Should we skip the version number here as well then? or do we need it?

🇭🇺Hungary nagy.balint

Hello!

I am glad that you have managed to solve the issue.

Technically the repository entry also takes the release from https://github.com/noli42/chosen/releases/tag/3.0.0 but we can likely improve the README of course.

Any suggestion for improving the README is welcome.

Production build 0.71.5 2024