chrissnyder → made their first commit to this issue’s fork.
smustgrave → credited chrissnyder → .
There are still errors and issues that need to be addressed See https://git.drupalcode.org/project/sitewide_alert/-/merge_requests/49
There are still deprecations that need to handled in order to make this module combatible with Drupal 11. Updated and new MRs welcome!
See the failed phpstan tests on the MR or those seen in sitewide_alert.2.2.1.upgrade_status.post_rector.txt → .
chrissnyder → made their first commit to this issue’s fork.
ChrisSnyder → made their first commit to this issue’s fork.
ChrisSnyder → changed the visibility of the branch 3349054-javascript-operators-in to hidden.
Core issue. Resolved by 🐛 JavaScript operators in Needs work .
If the filter allowed tags is checked everything is stripped except the allowed tags. It should skip to filter this part of the content, no?
It does not. The filter operates separately from the CKEditor HTML Embed plugin. There are cases (security, design adherance, perdicatable markup, etc) where a site's configuration will still want to limit the allowed tags even when using the HTML Embed plugin.
On the text format that has the HTML Embed button, do you have "Limit allowed HTML tags and correct faulty HTML" filter enabled? If you do, does the issue still occur if you disable that filter?
On the text format that has the HTML Embed button, do you have "Limit allowed HTML tags and correct faulty HTML" filter enabled? If you do, does the issue still occur if you disable that filter?
kopeboy is correct. The best solution is to create an additional text format.
ChrisSnyder → made their first commit to this issue’s fork.
Has anyone tested this patch to make sure it still works for sites using Bootstrap 4? We should ensure it does not cause any regressions for those still using Bootstrap 4.
@UriDrupal The patch/changes were merged, and a new release was deployed.
Update to the latest version of the module with the change: composer require drupal/address_map_link:^1.4
Merged and new release tagged. Sorry for the delay on this.
ChrisSnyder → made their first commit to this issue’s fork.
Should this be a configurable option on the text format?
I have tried, but unfortunately, I am not able to reproduce the issue. Is there any additional context you can provide? Does this happen if you clear PHP opcaches or any other caching that might be caching the container (memcache/redis)? Does the issue still occur on the latest version of Drush 12, Drush 12.4.3? ARe there any additional logs or stack traces you can provide for this issue?
I don't think this is possible within the scope of this module. If needed this need to be resolved within the External Link Popup module see https://www.drupal.org/project/external_link_popup/issues/3303109 → .
ChrisSnyder → made their first commit to this issue’s fork.
ChrisSnyder → made their first commit to this issue’s fork.
@liquidcms Is this still an ongoing issue?
Would it be possile to include this feature as a configuration option so that the existing functionality is preserved for those who need it and the new ability to avoid the extra request is avoided for others?
There are no current plans. However, this is a good idea. If a MR with this feature is introduced I would be happy to include it in the next release.
ChrisSnyder → created an issue.
ChrisSnyder → created an issue.
ChrisSnyder → created an issue.
I am not able to reproduce this. Reopen or create a new issue if this is still an issue with the latest version of this module.
ChrisSnyder → made their first commit to this issue’s fork.
ChrisSnyder → created an issue.
ChrisSnyder → made their first commit to this issue’s fork.
Nice work on this!
PHPCS and PHPCBF should not be run against Javascript because they can break their functionality as they are not PHP. In general, the PHPCS tools should only run against PHP files. Patch #2 breaks the the JS provided by this module.
MR18 resolved the issue and I no longer see the error when updating to raven 5 using drush 11.
ChrisSnyder → created an issue.
The icon in the patch/MR is from https://iconoir.com/, which I belive has an open-source MIT license. If that is not GPL-compatible, we can replace it with one of the attached icons. The attached Icons i just created myself for this project so there should not be any licensing issue with them.
Thank you for your work on this JSchref!. I opened a MR with your changes from the patch and added an update hook for those that already have the module installed.
ChrisSnyder → made their first commit to this issue’s fork.
The 2.0 version support Drupal 10
This may not be needed because in-theory formatted text (WYSIWYG) fields should never be rendered in the first place.
Patch in #22 works well for the specific issue I was encountering, which is explained in the opening post.
Is this issue resolved with the changes in the beta12 version → of the module. That release includes an Ajax error bug fix.