🇭🇺Hungary @nagy.balint

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.

nagy.balint → created an issue.

Any news here?

Probably this should be moved to https://www.drupal.org/project/issues/projectownership →
based on https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... →

We also need Drupal 11 compatibility,

The admin/reports/config-log is simply a views where the config is installed from the config_log_views submodule.
So if it is not there, then it is likely that config_log_views is not enabled in that database, and or that the config differs.

Apart from that, only the emails are not sent?
If you enable "Default logging system" in admin/config/development/config_log then it should log config changes in the dblog (admin/reports/dblog) Recent Log Messages.

Thanks!

The "const outgoingRegion = el.closest('.js-lpb-region').dataset.regionUuid;" was missing from the reroll.

Hi!

I could not reproduce it in my system.

However I think that using "1:1:2" as a machine name, especially when in yml syntax there is a : after anyways, is likely not the best idea.
I think generally machine names do not allow ":" to be used.
And so this might work in some places, but certainly not reliable.

It works with is between now too.

I leave it as needs work, because of the issue when enabling the plugin the first time.

I made some adjustments.

We cannot change the dateFormat in most cases it has to remain as is, or if it is date only then the time parts can be removed, but for display purposes only the altFormat should be changed.

Thanks!

I am not sure why this patch deletes code from processFieldSettings though.

This will need more testing, but I got a first working version.

It has an issue where on first setup it throws an error, but then if the view is saved it works fine afterwards. Not sure why it does that.

I did not test it with min-max (2 date filter) yet, but tests run fine.

I would guess if
- code is the same
- config is the same and nothing to synchronize
- some sites do send mail

then the only thing that could be different is perhaps mail sending configuration (perhaps site email, or any related config in settings.php overriden, or in config split or gitignore or config ignore)
because if the mail sending is different, perhaps also due to domain differences, then maybe the mail is rejected by the mail server.

There might be some dblog messages on the affected sites on config change about mail sending.

related issue: https://www.drupal.org/project/commerce_paypal/issues/3322346 🐛 Unexpected PayPal order status CREATED Active

might be related to Paypal module and not this module.

If it works on the sandbox though, then it is still more likely a configuration issue unfortunately.

I think that if this module would conflict with normal commerce operations, then surely it would appear in the sandbox mode as well, unless Paypal itself or the Paypal module made a mistake somewhere.

So after some more research, I concluded that this approach will unfortunately not work.

$webform_submission
      ->set('entity_id_commerce_order', $order->id());

Cannot work because entity_id_commerce_order is not a base field on the webform_submission entity. And altering the base field info is not recommended.
Maybe it works temporarily but it is definitely not reliable. In fact the tests fail with this change.

Also we cannot simply add it in the Data array where the submitted values live, cause that would also be unreliable, maybe it would get lost on a resave of the submission data. Also the data is a serialized column and would not be able to use join on in the webform_product_views_data_alter

Of course since Order has the submission reference, it might be possible to construct the views using the order and then relate that to the relationship, but not sure that we can store order in the submission as submission has no extra metadata storage.

I am setting this back to Active in case further ideas come up.

I recently added a bef submodule to Datetime Flatpickr → , it does not yet support time entry, but might be extendable, as an alternative.

Thank you!