🇺🇸United States @timwood

timwood → created an issue.

In some recent testing I was unable to get this feature to update links in either link fields or body fields.

Is this not related to the linkchecker settings under "Link Extraction" > Text formats for link extraction (side note, this should probably be labeled "Text filters")? If you check the following filter then the Linkit filter will not run and process your links during extraction.

Linkit URL converter
Updates links inserted by Linkit to point to entity URL aliases.

@saif al-dilaimi We've had success against the same scenario you describe by updating Facets to the 3.x release and then rather than using normal Facets, configuring your view to use Facets as views exposed filters which is a new feature in the 3.x branch. Users have to select from a drop down (in our case) and submit the form. It's not quite as elegant or convenient, but so far has prevented the bots from using the filters. The URL format is slightly different so we also were able to block the bot from accessing the old facet URLs with .htaccess rules.

RewriteCond %{HTTP_HOST} HOSTNAME_HERE
RewriteCond %{REQUEST_URI} ^/OPTIONAL/PATH [OR]
RewriteCond %{REQUEST_URI} ^/OPTIONAL/SECOND/PATH
RewriteCond %{QUERY_STRING} f%5B
RewriteRule ^.* - [R=404,L]

It is also possible to run into this situation if you are using config_split to only enable certain modules on upper environments (eg. Prod) and forget to account for an update hook for those modules.

Hi @mably. Thanks so much for the MR/patch! I like the simple solution you've implemented and after testing it against the 3.0.0-alpha4 release, I can confirm it does fix our issue. Original video thumbnail and image style derivatives are both stored in our site-wide default private files scheme.

Good tip about the DB query before and after. Can you confirm in your browser whether a session cookie was sent with the 303 redirect response to the user after clicking the reset button?

Update issue description to add better ordered list formatting.

In testing the MR on a 10.3.13 site, I can confirm that the patch applies there and prevents anonymous sessions from being created.

I also tested the 11.x branch on simplytest.me with and without the MR patch. When using the patch, I do not see cookies being set when clicking a reset button. When not using the patch the cookie is still set.

@tregonia how did you validate the anonymous session? Did you use an incognito window or other browser to ensure you didn't already have a cookie?

timwood → created an issue.

Hey @mferanda. Totally makes sense. I just figured since there were a few USWDS releases out, it might be good to align this theme to the latest.

Thanks for maintaining this theme!

timwood → created an issue.

timwood → created an issue.

Multiple functionality appears to have been added to the 2.x version of this module, including the 2.0 release. Using the documented format → , you can import multiple reference values (term ID), plain text and probably other types. multiple(1021+1056)

Changed the version to 2.x and marked as fixed.

Could the link checking only happen on link insertion or save/preview submit or something? It might be external links too.

Can the JS follow a link as/from the browser in the background and then report back rather than trying to integrate with Linkchecker? That way all user client authentication/cookies/sessions could be leveraged when checking the links.

Sorry to comment on a closed issue but I just noticed that @nicholass suggestion above is no longer working for us. Specifically, an end date value is being stored in the database in the node date field as value 88365 if no end date is submitted to the webform. Maybe this is a unicode character? I have no default value set in the end date value on the node field, which is a core daterange field using the contrib optional_end_date module. Adding a node directly on the node add screen does not result in this weird value in the DB. Switching to the "default" field mapping with custom text no longer accounts for the / in the custom text and includes it in the start value date on the node field.

I tried a few different token values including the suggestion above which we've been using for a while:

1. [webform_submission:values:starting_date:html_date:nolabel]/[webform_submission:values:ending_date:html_date:nolabel]
2. [webform_submission:values:starting_date:raw]/[webform_submission:values:ending_date:raw]
3. [webform_submission:values:starting_date:raw]/[webform_submission:values:ending_date:raw:clear]
4. [webform_submission:values:starting_date:raw]

(even this one, where I do not include the slash or end date still results in 88365 in the database end date value.

Here's a screenshot of the webform submission token suffix options showing :clear.

Attached is a patch for the 4.0.x dev branch and 4.0.0 release version that both remove the lightning_scheduler sub-module and update the README.md to remove the reference to that.

Thanks to all those who have contributed to this issue, however in recent testing after first applying patch from the older MR-68 and then later from MR-92 I've found that allowed tags attributes are removed. So if you allow <a> tags the href="[URL]" (and any other attributes) are removed, breaking the links.

The last working patch was https://www.drupal.org/files/issues/2023-07-05/smart_trim--2901579--allo... → (still listed here) from July 2023 against version 2.0.1. It looks like it was actually an unrelated change release (2.1.1) of this module.

Code above patch changes in src/Plugin/Field/FieldFormatter/SmartTrimFormatter.php from MR-92

           $output = preg_replace('/<(\w+)(?![^>]*\/>)[^>]*>/', ' <\1>', $output);

Code above patch changes in src/Plugin/Field/FieldFormatter/SmartTrimFormatter.php from patch #25

           $output = str_replace('<', ' <', $output);

Reverting this change after applying the latest patch, or reverting back to version 2.1.0 and using the older patch both restore links in allowed <a> tags.

timwood → created an issue.

Applied patch and ran login / logout tests with many different urls and the patch seems to be working correctly without adding any errors or issues.

Re-rolled patch against the latest 4.0.x branch attached w/interdiff.

I've also attached a patch that just fixes the "Undefined array key 0" error. I think webform changed since the report & patches were created and it now uses country & state short codes. I don't get any other errors when just applying this limited patch, even with saving the node afterward and the created node address field storage reflects the submitted state code in administrative_area and country code (which I default to "US" in my webform) in country_code fields in the database.

Latest module release required the patch to be rerolled. Attached w/interdiff.

In order to use the workaround provided you need to include use Drupal\Core\Url; in the custom module. Added to the workaround example in issue summary.

timwood → created an issue.

Any ideas on how to move this forward? It's more of a nuisance, but is still there, lingering...

I didn't notice before, I seem to have missed these Drupal messages at the top of the edit form. I guess the patch does gracefully fail.

In further testing with the patch, it doesn't seem to gracefully fail when a user has access to the CKEditor5-enabled text format, but doesn't have a role with the "Insert CKEditor Templates Allow user to insert ckeditor templates" permission. The button silently doesn't work/do anything and throws an AJAX error in the browser console.

Drupal.AjaxError {message: '\nAn AJAX HTTP error occurred.\nHTTP Result Code: 40…keditor templates\\u0027 permission is required."}', name: 'AjaxError', stack: 'Error\n at https://example.com/site…srpiiF1hjvyiFFDjy_jB1pTW_XUY7ls_gMdePQq:260:19298'}

@khaldoon_masud you should use the 8.x-1.x-dev version, which at this time is identical to the 8.x-1.3 release version (save for the automatic package additions to the module info.yml file).

I tested the latest patch in comment #117 and it works great!

Attached is the patch we've been using for this that also applies to the latest 2.x release. Sorry it doesn't include the test case.

We just recently started encountering the double leading slash issue that @joelpittet mentions above. We use SAMLAuth along with the https://www.drupal.org/project/require_login → module to force all visitors to login to our Intranet.

I think it has to do with the amount of followers a Twitter account has. Try embedding an account with a lot of followers and see if the widget loads tweets.

@devkinetic Thanks for working on this!

Our use case is for non-admin users to see the admin toolbar with environment indicator color but NOT the switcher.

We encountered this issue as well trying to limit the ability of lower level roles to see lower level environments other than prod, while still allowing them to see the color indicator for prod.

Thanks for the updated patch @Stockticker. It's working for us!

I'm not sure whether this new patch "uses the same implementation as the views functionality mentioned in the parent meta issue?", so not marking RTBC.

Added link to Elastic docs on the subject.

https://www.elastic.co/guide/en/elasticsearch/reference/current/security...

Issue fork and MR added with changes.

timwood → created an issue.

timwood → created an issue.

timwood → created an issue. See original summary → .

A temporary workaround that seems to have worked in a quick test is to run composer require laminas/laminas-diactoros:"2.14.0 as 2.18.1" for your project which satisfies roave/security-advisories while keeping the code at the version Drupal currently requires. But obviously doesn't fix the security issues with the laminas/laminas-diactoros package.

I can get the 8.x-1.4 version module installed on Drupal 9.5.x without the patch by following similar steps to #4 above.

1. composer remove drupal/ckeditor_liststyle (we were using the dev version with the patch here)
2. Manually remove the patch from composer.json
3. composer require drupal/ckeditor_liststyle

I guess Drupal.org's package repository can resolve a dependency on drupal/ckeditor to drupal/core...

Merge request provided and referenced by @jonraedeke in #4 above works to fix the issue for us.

timwood → created an issue.