🇺🇸United States @timwood

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.