🇭🇺Hungary @nagy.balint

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!

Hi!

So the date formats available at admin/config/regional/date-time
And the feature would be a dropdown in the formatter options to select a date-time format from there, instead of having to input the format in the alternative input field.

If I understood correctly.

Hi!

If I understand correctly, all the sites have the same configuration, but different database.

Is the (drush cim) show nothing to synchronize for all sites?

Hi!

I did not test it yet, but if it works, then it is a good approach.

We just need to move ->set('entity_id_commerce_order', $order->id());
out of
if ($this->configuration[self::ORDER_ID]) {

and the 'entity_id_commerce_order' could be in self::, for example
const ENTITY_ID_COMMERCE_ORDER = 'entity_id_commerce_order';
just to follow the existing practice.

so this value would always save, and then this further simplifies the set up process, as we would not need to even set up the Order ID and Order URL components.

Of course the purchasable entity is optional in Commerce, so it is most likely that the modules that use it without checking hasPurchasedEntity are actually using Commerce incorrectly, and it is not technically a bug in this module.

But if we would like to have a purchasable entity, we have the following options:
1, We can create an actual entity for each orderItem.
2, We can extend the OrderItem class and also define a dummy purchasable entity class, and then override the getPurchasedEntity method to return the dummy object. That way we don't have to save in database an extra entity for each OrderItem.

The commerce registration module has the code

if ($variation = $item->getPurchasedEntity()) {
...
}
      else {
        $remove_item = TRUE;
        $message = $this->t('Sorry, <strong>@item_name</strong> is no longer available for registration. It has been removed from your cart.', [
          '@item_name' => $item->getTitle(),
        ]);
      }

since we have no $item->getPurchasedEntity(), it will remove the item.

We will need to check if we can set this when creating the order, even though in our case multiple order item could have the same entity (submission or webform?)

Which commerce modules do you have setup on your site?

It seems weird that you get the "no longer available for registration" message, maybe there is a commerce module which alters the process and collides with this module?

I guess there is no easy way for me to look around on the site to see the configuration.

Thank you!

Even though Drupal 7 is unsupported,
it would be nice if this could be committed.

I tried to reach out to the maintainers via their contact form, but received no response so far.

@heddn, Hi! Do you have your version from #12 somewhere so we could restart from there?

Unfortunately this will require a reroll for 1.0.2

Well, actually I guess we can do this small change before the final release of 3.1, considering that now we have the option "Display only the order item title" in the handler settings.

Basically on most elements you can add a price which is added as an order item when submitting the webform.

Since we need to be careful with backward compatibility, we can only add a checkbox option somewhere either in the handler config or on the component config to show the component label or not, which is off by default.

I guess adding it on the handler settings is the easiest.

The patch seems to be wrong here, since

FieldConfig::loadByName($element['#entity_type'], $element['#bundle'], $element['#field_name']);
still uses bundle, maybe something is missing from the patch.

I added "Display only the order item title" in the handler settings.

I committed a solution.

The number component so far was only used when under the Order data settings of the handler the Total price was selected, or if the Price extra component setting is selected.

I added a new setting in Order field mapping of the handler where Order Quantity component can be selected.
Then if the user inputs a number into that component (which has to be numeric and bigger than 1, and will be rounded up), then the OrderItems will get their quantity modified.

for example:

10 x Webform product test - Price $200.00
10 x Webform product test - Checkboxes - 500 $5,000.00
Subtotal$5,200.00
Total$5,200.00

Hi!

Did you follow the video for setup? https://www.youtube.com/watch?v=zf1ZGKZVGQQ

Here is a patch with the "once".

Thanks for the report!

I unfortunately could not reproduce it just with layout paragraphs and layout paragraphs limit.

Maybe the issue only appears in Mercury editor.

I think the issue is with the behavior is that technically the behaviors might be called multiple time, and so this registration can happen several times on a page.
So maybe we need to combine this with "once" on the body tag of the page, to make sure that no matter what, this registration only happens once.

Thank you!

Reroll for D11.