🇨🇦Canada @mdolnik

This issue is stemming from the logic in this module's select2.js file in the if (config.multiple) { section at the bottom.

This logic allows the selected items to be dragged to change the order of the values, but for some reason on mobile when you tap on the close button, it attempts to start dragging the item instead.

Note: I was able to recreate this issue on mobile chrome, but on mobile firefox the button works as expected.

The solution for this is to tell the Sortable functionality that it should avoid dragging when tapping on the close button and this can be done by adding filter: '.select2-selection__choice__remove' to the configuration.

Added a patch to bring in this change as well as add versioning to the library files to ensure cache is busted.

It turns out that the 418 error was caused by dream host's firewall for "malicious HTTP requests"
https://help.dreamhost.com/hc/en-us/articles/215947927-Enabling-the-Web-Application-Firewall

Regardless for some reason the patch to add the theme dependency still resolves this issue.

mdolnik → created an issue.

Not necessarily a solution, but a workaround can be to use twig to render the resulting unix timestamp value as a date format.

Configure Field > Rewrite Results > Override the output of this field with custom text

Set the Text to:
{{ created|date("Y-m-d H:i:s") }}

Replace created with whatever the field name is in views and use whichever PHP date format you wish.

Also you need to ensure Thousands marker is - None -

mdolnik → created an issue.

Added a patch which adds a FontAwesome submodule.

This sub-module provides instructions to install FontAwesome's free library (version 6).

I have not tested this with any other version of FontAwesome, nor have I tried a paid version of FontAwesome so I don't know how it would support either of those combinations, but this can at least be a step in the right direction.

mdolnik → created an issue.

1. Modified icons_form_views_ui_edit_display_form_alter() to only display the icon settings on the views menu form
2. Modified icons_form_views_ui_edit_display_form_alter() to add Prefix/Suffix titles to the elements
3. Modified IconsManager::getMenuItemIcons() to retrieve the icon values from the correct area in the $options array.

mdolnik → created an issue.

Fixed issue where the element validation was incorrectly attempting to validate empty values.

Fixed issue with the CSS of the icon picker being added after some of the icon sets' CSS leading to broken icons being displayed.

Modified Icon::preRenderIcon() to support using '#icon_id' as described.

mdolnik → created an issue.

Added ListIconItem::storageSettingsForm() to always hide the allowed values list.

mdolnik → created an issue.

Provided a patch which adds a new Element/Widget that utilizes the jQuery Font Icon Picker.

The logic was inspired by the fontawesome_iconpicker_widget sub-module within the fontawesome module.

I decided to place all the logic in a iconpicker sub-module, but technically the logic could be moved into the main module.

mdolnik → created an issue.

I have had success with the approach outline here:

https://wiki.cbeier.net/en/webworking/cms/drupal/drupal8/snippets/use_different_views_for_various_vocabularies

In summary:

1. Clone the default `taxonomy_term: page_1` view display and alter it to your needs.
2. Add a new controller class which overrides and extends the views controller (`ViewPageController`) to alter its `handle()` method.
3. In the `handle()` method, get the taxonomy term entity from the route match.
4. Check the vocabulary of the entity, if it should have a different view display call the parent method with the alternate view/display IDs.
5. Otherwise call parent with the provided view/display IDs (ie `taxonomy_term: page_1`).
6. Create a route subscriber to alter the default taxonomy term entity route (`entity.taxonomy_term.canonical`) to point to your overridden controller class.

edit: Ok \Drupal\KernelTests\Core\Theme\ConfirmClassyCopiesTest tests are failing since text-format-wrapper.html.twig got changed here which changes the hash. This patch changes Stable and Stable9. Is that allowed? I was under the impression that it wasn't... I also notice that not all text-format-wrapper.html.twig files were changed (e.g: claro, bartik, etc).

I am not sure about this, I may need someone with more knowledge as to what is allowed to be changed when it comes to base theme templates.

Regardless whether it's allowed or not, one would need to make the same changes to overridden templates in their own themes as the title_display variable should be provided to all text-format-wrapper.html.twig templates, the theme will need to ensure that the value is utilize to add the form-no-label class or not.

To clarify on these template changes, these are only to fix asterisks on formatted text widgets, so if this needs to be cut from the issue then it's not the end of the world and can be manually fixed on a site-by-site basis.

Patch doesn't seem to apply cleanly to 9.5, so I've rerolled.

Sorry about my failing patch in #52 🐛 State required asterisk doesn't show Needs work not sure why it was not applying when I submitted it.

It seems that many of the subsequent re-rolls have introduced issues or omitted patch changes that were present in #52 that are no longer present in the latest #65.

I have provided updated patch files for D8, D9, and D10/11 (10-1-x currently applies to both versions).

Patches 8.9.x and 9.5.x provide the same changes.

The main differences between 9.5.x and 10.1.x:

1. Removes the states.es6.js which no longer exists.
2. Removes the bartik template changes as the theme no longer exists.
3. Removes the classy template changes as the theme no longer exists.
4. Removes the seven template changes as the theme no longer exists.
5. Removes the stable template changes as the theme no longer exists.
6. Alters the new claro template to be changed in the same fashion as other templates.
7. Alters the new olivero template to be changed in the same fashion as other templates.
8. Alters the new stable9 template to be changed in the same fashion as other templates.
9. Alters the new starterkit_theme template to be changed in the same fashion as other templates.

Besides the re-rolling only a single change has been made to states.js which is to add the lines:

// Labels within a summary.
+ ', details > summary'

This issue should have been resolved in Time Field fails required field validation if value is 12:00 AM 🐛 Time Field fails required field validation if value is 12:00 AM Fixed but the merged in fix missed a certain part of the provided patches.

The validation error is caused when the time is set to midnight as the value resolves to 0 which is treated as empty by Drupal core.

This is resolved by modifying TimeElement::valueCallback() to cast the return value as a string.

This string cast is necessary to avoid FormValidator::doValidateForm() from considering midnight to be empty.
ie: the line with $is_empty_value = ($elements['#value'] === 0); will treat 0 (midnight) as an empty value where-as it will treat '0' as populated.

The original merged in fix for this issue is not sufficient as it will still cause a validation error when the time is set to midnight as the value resolves to 0 which is treated as empty by Drupal core.

The original patch supplied in comment #5 had logic in TimeElement::valueCallback() which cast the return value as a string which is missing from both the current 1.x and 2.x branches.

This string cast is necessary to avoid FormValidator::doValidateForm() from considering midnight to be empty.
ie: the line with $is_empty_value = ($elements['#value'] === 0); will treat 0 (midnight) as an empty value where-as it will treat '0' as populated.

Regardless I believe the updated patch in #9 should work for anyone needing this fix in 1.x and for 2.x there is an open issue 3227128 🐛 Time Field fails required field validation if value is 00:00 Needs work which I think should be used to resolve this in version 2.x.

Added update to \Plugin\migrate\process\SignatureFieldProcess::transform() which provides new logic to grab an existing file entity if one already exists for a given signature file URI.

This updated patch helps prevent situations where there could end up with multiple file entities for a given signature file.

This situation can occur when entity revisions which contain the reference to the signature file are migrated.

This patch modifies \Drupal\views\Plugin\views\style\Table::buildSortPost() to add existing sort filters after the click-sort has been processed.

This will ensure that either value of Override normal sorting if click sorting is used will keep existing sort filters, but the checking will ensure the click-sort is sorted first, while un-checking will ensure the click-sort is sorted last.

The patch in #4 worked for me, but it took a while for me to figure out that this will only work when the export is set to "batch" mode.

Perhaps if this is approved it should have a disclaimer for this in the configuration description.

Added a patch for the proposed changes.

1. Changed the configuration values to have minimum value of 0
2. Updated configuration description to suggest setting values to 0 will omit functionality
3. Add logic to SlackLog::log() to ignore message per minute functionality if Limit of Messages per Run is 0
4. Updated SlackLog::log() utilize (int) casting instead of intval() because the casting is more efficient

mdolnik → created an issue.

Added a new patch which removes the changes to ElementBase::prepareState().

While this helped resolve the issues with the logic in ElementBase::validateOther() for Radios, it ended up complicating things when the fields as a whole are required via states by outside logic.

Removing the modified states code also prevents the need to update relevant tests.

Since the issue with ElementBase::validateOther() for Radios is caused by the issue that #3171843 is trying to fix, it should be considered to be a requirement for this task to be completed.

This is the same patch file as above, but can be applied to version 4.0.0

Added a patch to resolve this issue.

In summary this adds two parts to add validation:

1. The signature of ElementBase::prepareState() has been updated to accept an array of $states instead of a single string:

- This ensures that callers of this method can now provide not just the visible state, but visible,required states if the field is required.
- This causes the Other text element to be required via JS validation whenever its visible AND required.

2. A new #element_validate callback has been added ElementBase::validateOther()

- This ensures that if JS Validation is disabled (or somehow bypassed) that the validation will be performed server-side.

I have manually tested this on:

- Single-value select lists
- Single-value buttons (radios)
- Multi-value buttons (checkboxes)

With all of the above testing with JS Validation enabled/disabled.

One caveat is if JS Validation is disabled, the logic in ElementBase::validateOther() does not work for Radios. This is related to and caused by the issue that #3171843 🐛 Multiple-value checkboxes do not render existing values Active is trying to fix and its #6 patch will resolve this. (Radios will still successfully work with the JS Validation with/without #3171843 being resolved)

mdolnik → created an issue.

smustgrave → credited mdolnik → .