🇭🇺Hungary @nagy.balint

Now it is available at
https://asset-packagist.org/package/npm-asset/noli42--chosen
https://www.npmjs.com/package/@noli42/chosen

I think wrong queue.

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.

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.

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.

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).

Thanks!

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

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

Would this patch work?

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.

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.

Thanks!

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.

nagy.balint → created an issue.

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.

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.

nagy.balint → created an issue.

Hi!

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

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.

Bit more lines to make tests pass after that.

So I think the proper fix is just 1 line actually.

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.

Thanks!

Thanks!

Thanks!

#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.

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.

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

Any chance of getting this committed?

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

greggles → credited nagy.balint → .

Thanks!

Thanks!

Thanks!

Hi!

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

Thanks!

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.

I had the same issue, patch #10 fixed it for me on 2.0.10

Can you test the dev version?

Could be a Mercury Editor only issue, it seems that certain things work differently in Mercury Editor than in base layout paragraphs.

I will check.

I am not sure about the previous comment, as it is already committed see #4

I just left it open since BEF throws an error when it is initially added, maybe it is a BEF issue, not sure at this point.

Also a quick video could help if the problem persists.

I committed a fix for the empty selector.

Hi!

Can you provide more details on the error?
Usually the console shows the position of the error in the script.

Also make sure that you are using the right library for your branch of the module.

Maybe if you have the chosen_field module enabled, that could apply it, if the widget is specifically selected for the field.

Just in case we could still fix of course to continue to work for empty value in "Apply Chosen to the following elements", likely I could just check if the selector is empty, and skip that part of the code, but then it is likely not very urgent.

Thanks for the report.

Is it possible for you to provide the value of the "Apply Chosen to the following elements" in admin/config/user-interface/chosen ?

It would not work when that field is empty, but not sure if there are other edge cases.

At least on my sites, I cannot reproduce it, but if it is reproducible on a clean install, or a certain module configuration consistently, then we can take a look.

npm-asset/chosen is already taken.

I could try registering at https://packagist.org/ so then it would be possible to install the lib without the repositories section as composer require noli42/chosen.

And then it will only need one line at
"installer-paths": {
"docroot/libraries/{$name}": [

something like
"vendor:noli42",

to make sure that it is installed at the right place.

For that the library would need to be published under npm-asset which is not the case currently.

I usually add the library into the repositories section of the composer.json

        {
            "type": "package",
            "package": {
                "name": "noli42/chosen",
                "version": "3.0.0",
                "type": "drupal-library",
                "dist": {
                    "url": "https://github.com/noli42/chosen/releases/download/3.0.0/chosen-assets-v3.0.0.zip",
                    "type": "zip"
                }
            }
        },

and then i can just do composer require noli42/chosen

So If I understand correctly, we have two main ways:

a) If the user adds this extra component and sets it up so the module stores the order id in there, then we can create a views handler similarly to how the webform_views module does it, to be able to show the order in the same row.

This could work without modifying the webform submission base field info.

b) We can implement a new submodule, webform_product_views, and implement this base field alter to add the extra field to the submission, in which case it is easier to implement the views relationship, and it does not require the user to add this extra component to the webform.
The submodule in this case would be to limit the risk in case some installations don't require a views like that, and we would need to document it.

I would suggest to use composer to install the library as defined in the readme.

But if you would like to install it manually, then download the library assets from the release
https://github.com/noli42/chosen/releases/tag/3.0.0

and the files should be under libraries/chosen, the status page for the chosen module has all this information.

I dont recognize the message 'Chosen-JavaScript-Datei not installed' however so maybe there are other modules used which is not in the issue description.

I could not reproduce it on 11.1.1 on the backend.
Maybe it only happens on front end with a specific theme?

I just tested it in a view, where i set up the formatter on the title field and it worked.

So maybe it does not work on all fields, but it definitely works on more than just reference fields.

Hi!

• Can you provide screenshot of the admin/config/development/config_log form on the affected site?
• Can you check if the config_log_views is enabled in the extend page? (admin/modules)
• Are you using the admin user? or have administer site configuration permission?

@ibis:

I have not checked it yet, but if the order id remains as a component, then could it be used with https://www.drupal.org/project/webform_views → to create the relation?

Maybe it is not enough, but worth a check.

Thank you!

I think that we should implement this in a more generic way.

The new option could be in DateTimeFlatPickrWidgetTrait.php

And that could work in the widget settings as well as in the Element, and in the better exposed filters widget.

Then all settings could be made available in the webform similarly to how it was done in the better exposed filter widget (FlatpickrDateBef.php)

I think that last time I tried, my issue was that there was no way to define the date format of the input when using these new input types.

That is why I am using flatpickr.

Thank you!

Hi!

Back in Oct 6, 2023 I was able to send a contact form message, but received no answer unfortunately.

Now when I looked the contact form is gone, so maybe he has disabled it.
Also I could not find him on slack.

Thanks!

Hi!

It was the merge plugin in the past yes, but then the conclusion was that since the merge plugin does not work everywhere (for example it does not work on pantheon), the repositories entry in the composer.json is the better default option, which is why it is the first option in the readme.

I always used the repositories entry on my projects.

There is a third way but that also requires editing the composer.json, so not a big difference.

I wish there was an easy way to include a library without all these extra steps and configuration... (I guess if it was on CDN that would solve it, but that brings in other issues)

Hi!

run
composer require drupal/chosen:5.0.0 drupal/chosen_lib:5.0.0 -W

But also make sure that you have the related library, as 5.0.0 uses a fork of chosen without jQuery.

That being said,

I don't see a lot of possible side effects from the base field info alter, since the webform submission entity does not go anywhere and they will also never add a column called "order_id" so this could be a safe way to go.

I was also looking at something like

$webform_submission->set('entity_type', $this->cart->getEntityTypeId());
        $webform_submission->set('entity_id', $this->cart->id());

But storing the order id there. But it seemed weird since that is used to store which entity embeds the webform originally.

Hi!

By "theme assets" do you mean gin theme?

So far based on my research, it seems there is no other option.

And we would need an uninstall hook similar to

function webform_product_uninstall() {
  $schema = \Drupal::database()->schema();
  $table_name = 'webform_submission';
  $field_name = 'commerce_order';

  // Check if the field exists before attempting to drop it.
  if ($schema->fieldExists($table_name, $field_name)) {
    $schema->dropField($table_name, $field_name);
  }
}

It is generally not recommended though, so I am currently undecided how to proceed.

Thanks!

I suppose this is by using the https://www.drupal.org/project/optional_end_date → module.

Thank you!

I will check.

Thanks!
It works for me.

here is the github fork for now: https://github.com/webbtik-io/edit_in_place_field

nagy.balint → created an issue.

That is perfectly understandable, It happens.

However considering that this issue is 7 months old, it still would be good if a co-maintainer could be assigned.

I mean of course I can just create a github fork, but surely it would be better to maintain the module here. But at some point I will have no choice since my site has to move on to Drupal 11.

You can turn off the two ignore settings as a test just in case they interfere with something.

I guess you cannot give me any access to look around, if I had access to the server I could probably figure it out.

So far based on the information I could only conclude that the issue is likely not with the module, but how it was installed.
Or maybe if it was an old installation and the upgrade somehow failed, but even then the dblog logger has no dependency so that should work no matter what.
Because what you are describing is that the module is installed but Drupal simply ignores everything the module defined, which is normally unlikely.