Thanks aporie,
Ahh yup that makes sense. Luckily in my case I don't need the alerts to vary by user so I think what I've got will work. Unfortunately I can't provide much more info, I can't figure out why the middleware causes problems for my site and haven't had time to try reproduce on a clean install.
I mostly just wanted to record the issue in case others have the same problem. If so it could possibly be resolved by setting a user context on the block, e.g. as in https://drupal.stackexchange.com/questions/288881/problem-setting-user-s....
timmy_cos → created an issue.
Hey Wim,
Sounds good, here's some markup for the 'Table 1' example above.
<table><thead><tr><th>Header</th><th>Header</th><th>Header</th><th>Header</th></tr></thead><tbody><tr><th>Header</th><th>Header</th><td>Data</td><td>Data</td></tr><tr><th rowspan="2">Header</th><th>Header</th><td>Data</td><td>Data</td></tr><tr><th>Header</th><td>Data</td><td>Data</td></tr></tbody></table>
It might be a little tricky to test since the problem only manifests when the editor is activated. Expected result is that opening the content in edit mode and saving immediately would result in the same HTML; instead the markup is changed to:
<table><thead><tr><th>Header</th><th>Header</th><th>Header</th><th>Header</th></tr></thead><tbody><tr><th>Header</th><td>Header</td><td>Data</td><td>Data</td></tr><tr><th rowspan="2">Header</th><td>Header</td><td>Data</td><td>Data</td></tr><tr><td>Header</td><td>Data</td><td>Data</td></tr></tbody></table>
(second column has been converted from th to td)
I've had a look through upstream issues and I think https://github.com/ckeditor/ckeditor5/issues/14826 might be the same problem?
There's a pull request in there which is waiting for review, I'm not sure how well it would apply to Drupal though...
Hey there,
I've tried out these changes and the interface is working great :)
I did need to make a few small tweaks to CKEditor5Plugin/Mathjax.php though:
- The 'provider' annotation should be up one level, outside of @DrupalAspectsOfCKEditor5Plugin
- There are still some methods missing for CKEditor5PluginElementsSubsetInterface (I just removed the implements)
- I had to remove the call to 'getElements' on line 89 (getPluginDefinition was returning an array directly)
Awesome to hear @matthieuscarset!
I just wanted to throw out a big +1 that a CKE5 version of this module would be a huge benefit for my team, and your work is very much appreciated <3.
I mentioned this in a comment against the issue that introduced the problem (sorry I should have raised it more prominently): https://www.drupal.org/project/fast_404/issues/2820923#comment-15146433 🐛 Fast404 path checking is incompatibility with multilingual paths Fixed
Would it not be preferable to switch both instances of Fast404 to use the factory rather than bring the use statement back?
Hey there,
The changes to fix this issue seems to have introduced a class not found error on https://git.drupalcode.org/project/fast_404/-/blob/8.x-3.x/src/EventSubs... (due to the removal of Fast404).
The bug has made its way into v3.0. I've attached a patch that works for me, not sure if this needs to be a new issue.
Hey there,
I'm currently experiencing this issue while attempting to install with composer 2 via an internal mirror of packagist (hosted on JFrog artifactory).
In my case at least, the problem is that the "dist" property is set to "__unset" in the coder.json file at https://repo.packagist.org/p2/drupal/coder.json. When JFrog tries to read that property it crashes, and exposes the problem to composer as a 404. This results in the error that composer could not find a valid version.
I'm not actually sure what dist is supposed to be set to, so this could purely be a JFrog issue. But if there is some easy fix to setup dist on packagist that would be great :D.