🇺🇸United States @anthonyroundtree

Ok. It seems that I need to enter the login link as example.com/loginpage?destination=node/nodeidnumber. I just need to find a way to add this to the webform description. Thanks. This issue can be closed.

anthonyroundtree → created an issue.

Using rc7 and it worked, right up until I moved it into my production environment. Is there a plan to role this or it's patch into the next version?

anthonyroundtree → created an issue.

anthonyroundtree → created an issue.

I'm getting the same error using v2.0.6 and I'm using saml authentication 8.x-3.10 (as of this posting it's the latest version).

I'm getting the exact same error. I even tried using switching over to Ckeditor 5 and get the same results.

I'm using D10.3 with a Gutenberg related theme. I'm curious if it's related to that?

I just opened an issue, https://www.drupal.org/project/gin/issues/3461545 🐛 Buttons missing or not working properly in Views Active , about action buttons not appearing in Views only, but I'm using Gin as the admin theme, not the sites theme. Could this issue be related? If so, I'll just close that one. In my case, I'm seeing the save, not the other action buttons.

anthonyroundtree → created an issue.

anthonyroundtree → created an issue.

anthonyroundtree → created an issue.

anthonyroundtree → created an issue.

You may have to update WYSIWYG module to latest version if you haven't done so already. https://www.drupal.org/project/wysiwyg/issues/3350431 ✨ Update to CKEditor 4.21.0 Fixed

This issue can be closed. Turns out you have to turn off Firefox 'Tracking content' to display social media icons. I would say that this is also the reason behind the following issue, https://www.drupal.org/project/sharethis/issues/2213131 🐛 sharethis not working on latest firefox 27.0.1 Postponed: needs info .

anthonyroundtree → created an issue.

If you don't mind me asking, are you posting your tweets and are they still displaying on your site?

FWIW I was able to use the integration to post a tweet on Monday, but maybe other API endpoints are not so lucky?

If you don't mind me asking, how were you able to do that? Were you still able to pull tweets and display them on your site?

The link to the page can be found here on one of our sites news pages.

If viewed in Chrome, sharethis links appear, but do not in Firefox

I've had the same issue and ended up doing something similar to the above patches listed. My only issue is that running allow-scripts and allow-same-origin is strongly discouraged. In extreme cases, it's defeating the purpose of the original security patch by making things more open.

See, https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe, for more details.

In a related post, one of my solutions was to allow users to select sandbox attributes. This doesn't quite solve the problem (it might create more unintended issues; for example, my opening statement).

I don't want to close this topic, however, I am not comfortable with moving forward with an update with this module if it approves 4.21. Frankly, without something addressing the issue, I would say that 4.21 is not recommended for use with WYSIWYG. This puts everything into a conundrum, of course, because it is a security patch. Any thoughts?

Regarding #3, it goes into a discussion as to whether or not it's a good idea to allow allow-scripts and allow-same-origin at the same time. See, https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe, for more detail. The issue is,

When the embedded document has the same origin as the embedding page, it is strongly discouraged to use both allow-scripts and allow-same-origin, as that lets the embedded document remove the sandbox attribute — making it no more secure than not using the sandbox attribute at all.
Sandboxing is useless if the attacker can display content outside a sandboxed iframe — such as if the viewer opens the frame in a new tab. Such content should be also served from a separate origin to limit potential damage.

Just want to follow up that the latest version, 7.x-2.14 is having the same issue on Firefox. I'm running FF 102.

That seems to be the issue.

anthonyroundtree → created an issue.

anthonyroundtree → created an issue.

I believe this is the same issue:
YAML filename ends in space, git checkout in windows fails. - https://www.drupal.org/project/flood_control/issues/3337620 🐛 YAML filename ends in space, git checkout in windows fails. Fixed

Running D9.5.2 and having a similar issue after an attempt to upgrade from 2.2.3 to 2.3.

 - Updating drupal/flood_control (2.2.3 => 2.3.0): Downloading (100%)    The archive may contain identical file names with different capitalization (which fails on case insensitive filesystems): ZipArchive::extractTo(C:\.../vendor/composer/.../flood_control\migrations\state/flood_control.migrate_drupal.yml ): failed to open stream: Permission denied
    Unzip with ZipArchive class failed, falling back to unzip command