🇭🇺Hungary @nagy.balint

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.

It seems that the config_log module is trying to log a config change in the config_log table while the drush updb was running, so before the schema modifications could take place.

admin/config/development/config_log
If the "Custom table ("config_log")" option is disabled then likely it won't attempt to insert into the table, and then the update hook can run.

I posted an issue at the DropzoneJS issue queue.
✨ Allow CDN to make the module work out of box Active

I think that using the CDN as a fallback would be the right solution for making it work out of the box.

Otherwise if we can't do that, then the only other option is to improve the documentation of this module and basically copy the install explanation from the DropzoneJS module.

nagy.balint → created an issue.

Hi!

Did the update hook cause that error (update.php or drush updb)?

I think only 10.2+ since it uses php attributes.
https://www.drupal.org/docs/drupal-apis/plugin-api/attribute-based-plugins →

Thank you!

The patch in #6 solved the error.

It is indeed critical as it breaks the add field UI in Drupal 11.

nagy.balint → created an issue.

This seems to be a duplicate of ✨ Drupal 11 compatibility fixes for conditional_fields Active

So what needs to be done here to consider for commit?

Do we need to fix all the tests in this issue even though the branch itself is not passing?

Or can this be committed, and then tests can be fixed in a follow up issue?

project-update-bot-only MR is only for the bot, and normally should have had no commits on it apart from that.

3455217-automated-drupal-11 MR !227 is the right MR, as you can see in #13

Any news on this issue?

What do we need to commit this?

This cant be RTBC since in the 3.0.x this code part is completely different, I think it does not even use better exposed filters anymore (although the dependency is still there, but no plugin)

class FacetsFilter extends FilterPluginBase {

So if the issue exists in 3.0.x then it is still needs work.

Okay, so Merge request 227 works for me.
I rebased it, and added some more changes from the 2.x branch.

Hi!

Thank you!

I found one issue however on searching:
https://www.drupal.org/project/suggestion/issues/3483904 🐛 Issue with db merge on Drupal 11 Active

Unfortunately we need to raise the requirement to Drupal 10.2 for the following patch to work.

nagy.balint → created an issue.

But I would prefer not to use the lenient composer plugin, so any help pushing this forward is welcome.

I applied 219 and it worked for me.
The only thing it missed is the core_version_requirement changes in the module, submodules and test modules.
core_version_requirement: ^10.1 || ^11.0

I can only do limited testing, but on my site using facets it worked fine.

So I guess, this leaves me no other option than to fork the module.

This is basically the last module that blocks me from upgrading to drupal 11.

Hi!
@batigolix, any news about pushing this forward?

Works for me as well.

Would be good but 💬 Facets 3.0.0-beta2 release? Active .

Also loosing hope for a D11 compatible version :(

Hi!

Thank you for looking at the issues.

Once the compatibility patch is in, I will be able to move forward with some of my sites, and I will report back if there are any issues on Drupal 11.

What are the plans for the 3.0.x branch D11 compatibility?

Will at least the dev version be compatible soon?

Updated page after ddev updates.

Updating the installation guide for 5.0.x.

Changed branch.

I am not sure why an alpha release could not be made on the 6.3.x branch, since alpha releases would not be recommended for use anyways, but it would make it easier to test dependent contrib modules on drupal 11.
I think it would help contrib to commit this work and continue with fixes on that branch instead of waiting for a big pull request.

Hi!

I think this might have been the case for previous versions as well.

For claro the module defines "min-width: 160px;"

The front end theme has no such definition, but we have a "Minimum width of widget" setting in the
"admin/config/user-interface/chosen"

Maybe it is only problematic in a Tabs context.

If I set "Minimum width of widget" to 200px for example, then it works for me even in horizontal tabs.

Let me know if 5.0.0 still has accessibility issues.
It has a new fork with some improvements.

I got access to set the default branch now, so I close the issue then.

Now it is possible to enable mobile devices in the 5.0.0 version. But it requires a new fork of the library: https://git.drupalcode.org/project/chosen/-/blob/5.0.x/README.md

Now it is possible in the 5.0.0-rc1 version to enable chosen library on Android and iOS devices.
https://www.drupal.org/project/chosen/releases/5.0.0-rc1 →

There is a "Allow mobile devices" option in the admin/config/user-interface/chosen settings page.

so then the first step is done.

The 5.0.0 version requires the library to be changed to the new fork: https://git.drupalcode.org/project/chosen/-/blob/5.0.x/README.md

The request was not created by me. I was just monitoring the module status.

Thank you!

Updated documentation.

Added information about news and event content type, and about the theme colors.

Hi!

There is already an offer for this module at https://www.drupal.org/project/projectownership/issues/3470293 →

First I sent a message (via contact form) at the 3rd of September to ask about the plans for Drupal 11 support, and then at the 9th of September about offering to become a co-maintainer.

I have received no response unfortunately.

Hi!

The hook_field_widget_single_element_WIDGET_TYPE_form_alter() works for me on core 10.3.5 and paragraphs: 1.18

I think at this point often websites implement their own design for these chosen elements.

We can always improve the default css of chosen, but need to be careful with it.

Of course the first issue here is to see if we can enable chosen on mobile screens, as without, mobile phones will anyways only see a standard HTML select.

You can use https://developer.chrome.com/docs/devtools/device-mode
to simulate mobile.

As far as I checked today https://github.com/JJJ/chosen (which is used in 4.x) also displays only a normal select on mobile.

The original reasons behind it can be found here https://github.com/harvesthq/chosen/pull/1388

I wonder if we can override the AbstractChosen.browser_is_supported = function() (which is defined in chosen.jquery.js)
somewhere around line 24 of the chosen.js in our module.
Because in that case we could make it configurable to show it or not for Android and iOS.

Now it only does not like the api.php, but it should not analyse that anyways.

Updated patch

I think they fail only cause of missing schema.

Hi!

I unfortunately cannot reproduce it on Chrome in a fresh Drupal 11 install with Olivero
(I guess there should not be a big difference between 11 and 10.3.2 regarding this issue)

And on mobile currently chosen will not apply 🐛 Chosen is not working on mobile devices? Closed: duplicate

So the 4.0.3 only added a JS change for modals, it should not affect normal select items in any way.

Also the search field is required as that is where the user can type in a search term.

For me when an item is selected the placeholder attribute of the search field is cleared and that is why it is not visible.

So we need more detailed reproduction steps in this issue, as I could not reproduce the issue.

I don't see how this would work.

The module uses the "dropzonejs" element, so the dropzonejs module needs to be a dependency.

At the same time even if we were to use a CDN we would need to provide an option to use the library locally, so for that a library_info_alter would work which detects whether the dropzonejs is installed.

So maybe this should be more an issue on the dropzonejs issue queue to allow CDN and use library_info_alter to detect local install.

Currently I cannot change the default branch, so I added it to both branches.

Actually the FormBase already have
use LoggerChannelTrait;
use MessengerTrait;
So we don't even need some of those injections.

The patch is a bit outdated.

Here is a reroll for 2.0.x, but likely applies to 1.0.x too.

Fixed on 2.0.x