🇧🇪Belgium @tim-diels

tim-diels → created an issue.

Also one setting to not forget is to set the exposed form to be in a block so it doesn't render on the view itself.
I added the Simple search form module to the project page, so closing this issue.

Tested in the next scenario:

• Created a view listing articles
• Have 2 sort options "Date", "Title"
• Show the view on a path for example "articles"
• Set the exposed form to be in a block
• Place a block in block layout for the exposed sort and limit it to this page and select the view with corresponding display

It will right away show the next error

Warning: Undefined array key "uuid" in Drupal\views_exposed_sort_block\Plugin\Block\ViewsExposedSortBlock->getCacheTags() (line 161 of modules/contrib/views_exposed_sort_block/src/Plugin/Block/ViewsExposedSortBlock.php).
Close message

So not sure how this caching is supposed to work and how its tested. Can there be some explanation as maybe I'm missing something?

@ant1 thanks for the work done to create the submodule! But can you explain "There is still the issue of data loss regarding this setting with the upgrade."?
As to me it seems you covered the problem with adding an update hook to install the submodule when pathauto is installed...
Putting this to needs review as I think this is ready.

Project link is https://www.drupal.org/project/mask →

I think we waited long enough now so moving this issue.

Can this please get committed? Using this for almost a year without problems.

In our eyes this is an important improvement to the module. We would love to see this committed. What can be done to get this committed?

As it seems we're the only one still using the patch, I tried to reproduce this with the latest version and can't seem to reproduce this. For me this can be closed.

Thanks, this looks good for me.

Looks good for me, thanks

Added the schema for cutom_stacked in meanwhile. But not sure if this is the correct solution, but can't find the cause that creates this issue.

I think this is strange behaviour as there is

field.widget.settings.*:
  type: custom_field_widget_base

custom_field_widget_base:
  type: mapping
  label: 'Custom field widget settings'
  mapping:
    label:
      type: boolean
      label: 'Show field label?'
    wrapper:
      type: string
      label: 'Wrapper'
    open:
      type: boolean
      label: 'Show open by default?'

that would normally should be picked up.

tim-diels → created an issue.

tim-diels → created an issue.

Thanks for the adjustments, I really like you're activity on here. I just have a small remark where there is a difference in config schema keys and form keys.

It gives now an error 'modifier_type' is not a supported key.

This will need work to provide test coverage for the required options.

I've added the option to set attributes required. But for some reason the empty option is still there. Can't really find out if this module is responsible for that or it's something else.

tim-diels → created an issue.

I want to thank you for the already work done as it inspired me to think further on how to handle this.

I would suggest we think about this broader and allow other options to the autofill. So I would call it modifiers.
So first we need to have an option to enable the modifiers as this is only needed for specific use cases and not the default option.
After that we should be able to have modifiers, in this use case its only one for now called "Anchor". So this will allow other feature requests or persons to add modifiers as they want.

I adjusted the summary and title to reflect the required changes. I hope that's ok for you?
Thanks you for being so flexible already and the effort you put into this.

Also check the pipeline issues please. Keep an eye on Coding Standards, CSpell, ESlint , ...

I love it that you already did this!

Exactly what I needed, except that I would have let the developer/site builder specify the patterns.
I do think this is a good addition but maybe the naming is not correct in this case.
Maybe we can change the title to say for example "Transform to anchor" instead of string replacement?
Then we should also update the issue title and summary here to reflect the change.

With that said now onto the functionality, did you test every specific case? Like special characters and symbols? We should strip out every character that is allowed to be entered in the textfield but not allowed in the anchor definition.

Setting this to needs work for 2 things:
1. Update issue title/summary if we keep this implementation. Update the label and machine name of the field.
2. Test more scenario's and make sure we only keep valid anchor text.

Having this issue on multiple sites and this patch is working for us. So I'll give it also another RTBC++

Adjusted the code so it allows to support paragraphs on a dynamic manner by passing on the field parents.

Added support for paragraphs but the delta needs to be made dynamical so it does not picks only the first paragraph.

tim-diels → created an issue.

tim-diels → created an issue.

Updated the title

Thanks for the addition we also exactly needed. Works as expected and contains everything that should be there like a config schema adjustment for the config setting. Setting to RTBC.

tim-diels → created an issue.

Been using it on more project. So lets merge this.

The readme has been changed with the change of install instructions. So closing this.

Let me review this.

Should be solved as the other ticket changed the class. If not, feel free to open a new issue.

I'll review this

Not going to do anything about the spaceless as there is not yet a complete solution see 📌 Twig Filter "spaceless" is deprecated Active

tim-diels → created an issue.

Fixed.

This would really be interesting to look into. I'm up for reviewing any proposals.

tim-diels → created an issue.

I've also added decimal and float. So the complete number field is covered.
Changed title to reflect the change.

Fixed.

I'll look into this further

Does not break anything for me.

Thanks for the suggestion. I'll review this.

Because of the comments from kopeboy.

With Drupal 7 not being supported anymore. I'm closing this issue.

Lets support this in 2.1.x

Fixed.

Sorry that I must say it, but the Drush commands are removed as the preferred install these days is with composer. so this became outdated.

The reported problems were solved as the Drush commands were not needed anymore. But there are other issues. Will open a new ticket to keep it clean.

We should add more formatters to the integer field.

Fixed.

tim-diels → created an issue.

Thanks for the feature request. I'm postponing this for the new 2.1.x release that I will create soon to remove deprecations.

This MR does more then needed so going to close it. Will credit for the work done though.
Will add new smaller MR with only Drupal CS and not DrupalPractise, that should be handled differently.

Fixed

The file phpstan.neon that is included is not complete. We should update it and then see what the issues are that still needs to be adressed.

Fixed

tim-diels → created an issue.

Removed the dependency on the gin toolbar and suggested to install the gin toolbar if you want this for the frontend.

tim-diels → changed the visibility of the branch 3499447-the-module-does to hidden.

tim-diels → changed the visibility of the branch 2.0.x to hidden.

Switching to 2.0.x

Talked about this with a few people and suggestion is to create a 2.0.x branch where we remove the dependency. This will create awareness to the persons updating to a new major that they need to require gin_toolbar themelves if they are depending on the module.

Investigated and the Gin Toolbar is not needed. So will change it to suggest installing it but it's not required.

It actually does not need the gin_toolbar module if your website only serves as backend in a headless context.
So we can remove the dependency and set it as suggested.

But indeed it is now blocked due to new version of gin_toolbar

Someone else made a different ticket about it and provided a change in class 🐛 Use class .clipboardjs-tooltip instead of .tooltip to prevent collisions with other code Needs review . So guess this ticket can be closed?

I'm much more a fan of using the asset-packagist then using the merge plugin. So if someone has time and interest to fix this, would be great.

This is very hard for anyone to understand why you need this. Could you provide more info on where it is failing and why you need to add the container?

Also the status "Patch (to be ported)" is not correct in my eyes. So moving to needs work to provide more info on steps to reproduce.

There is no need to add this as patch or MR as it is already on git through the commit https://git.drupalcode.org/project/clipboardjs/-/commit/adb3f68a16da524e...

You can use the diff of the commit in meanwhile to have it as patch.

But indeed a new release is needed so people can properly install everything.
I would say "RTBC".

Hi dieterholvoet,

I'm happy to accept your offer to maintain the module together. I don't have sufficient time to react as fast as I would want. So any help is welcome. I added you as maintainer.

Tested this on a Drupal 10.3 install with PHP 8.3 and everything works.

tim-diels → changed the visibility of the branch 2.0.x to hidden.

Postponing this until the other modules have the patches accepted.

tim-diels → created an issue.