wysiwyg is 100% on topic for strategic planning as an example why we need to align closer with Wordpress in plans.
There is a limit in our ability to get work done upstream. The government of Ontario wrote an elaborate fix two years ago to preserve tfoot elements and it has sat for two years in github.
Obviously we're committed to ckeditor5 given the 4 years investment gone in and my team has been working on a contrib level support for resolving ckeditor upstream issues using text filter plugins with regex.
As for ckeditor 6, who is to say it will not be tabled before 2028? When the time for ckeditor6 comes I urge an alignment with Wordpress as a safe strategy going forward. I sincerely hope that Wordpress influences our editor choices in the future and that we weigh seriously industry juggernaut choices in our strategic planning when it will help our upstream support in wysiwyg and in other endeavors.
@nod_ ,
The example of TinyMCE and alignment with Wordpress is a relevant topic to consider for the
"Drupal Core strategy for 2025-2028"
I will explain:
Large organisations such as NGOs , Governments, large corporations have millions of pages of existing content that was designed and coded using ckeditor4. These organisations are subject to accessibility laws that are designed to enforce accessibility standards. This means that if our content breaks we expose ourselves to teams of lawyers from groups such as the national instutute for the blind and others. As these organisations upgrade to Drupal 11 as some of my clients already have, they will be forced to use ckeditor5. ckeditor5 however as we have discovered has broken a lot of this markup which translates to exposing ourselves to lawfare. The folks at ckeditor have received multitudes of patches to fix bugs however they have used several arguments saying that if the fix contains no related ui component that they will not accept the fixes.
Meanwhile tens of millions of Wordpressers continue to use TinyMCE that has not pulled a ck4 style "EoL". Wordpressers are avoiding lawfare meanwhile as we upgrade to Drupal 11 and switch from ck4 to ck5 we expose ourselves to lawfare or else we create elaborate text filter plugins to resolve the broken markup. I am considering publishing a module called "please_replace_ckeditor5_with_tinymce", what this module does is provide three seperate text filter plugins that rewrite markup that was "broken" by ck5.
So in response to the challenges of adopting majors (since we have many clients to upgrade) I have raised a one sentence policy suggestion that will give us a more predictable timeline for majors.
📌 [policy no-patch] Discuss LTS options Active
We have to digest the choices made upstream and since we're not using libraries that Wordpress heavyweights have chosen we don't get the same level of support. ckeditor5 was a total rewrite and while it is water under the bridge, probably too late to drop, if ckeditor6 comes around where ckeditor5 goes EoL I would highly suggest that as a strategy we adopt Wordpress choices, so if Wordpress goes to ckeditor6 , we go, but if they stay on TinyMCE , we choose TinyMCE instead of upgrading to ckeditor6. This therefore is a two pronged strategy suggestion.
1) policy no patch one sentence #3508715
2) align wysiwyg with Wordpress when ckeditor6 is tabled.
What are the steps to reproduce this issue? What configuration options are being used where this is being observed?
What is your default language, how many languages are configured? is the content bundle translation enabled?
What other modules may be involved here?
Are you able to reproduce this with a vanilla Drupal 10.4.6 or Drupal 11.1.6 setup using the entity_translation_unified_form module?
If so, what are the install steps and configuration options being used , which languages are installed and configured? Are you using a language prefix to determine the language interface or domain or cookie?
Please throw me a few bones here.
Governance issues.
https://github.com/ckeditor/ckeditor5/pull/14276#issuecomment-2815624337
LGTM
ah ya, since it's a new file the MR branch patch will still apply against wxt_library
https://git.drupalcode.org/project/wxt/-/merge_requests/22.patch take this patch, apply it against wxt_library , should work.
Drupal CMS is interesting and I encourage this activity. With that said, we've got existing platforms built on Drupal that are not aligned with Drupal CMS and likely will never be aligned with Drupal CMS. This proposal is a modest step in a direction that aligns with our priorities which include achievable deadlines and a lowered TCO which our stakeholders are able to understand 📌 [policy no-patch] Discuss LTS options Active
I'm using this module with Drupal 10 and Drupal 11 and have not encountered this issue.
Steps to reproduce please?
List of installed modules?
devel is an important tool and for DX, +1 here
Please see comment #16 and comment #17. This needs to be a configurable option.
see MR and here's the MR patch
Please click the thumbs up on this pull request that fixes the issue at the root which is in ckeditor it'self.
I've created a new module called please_replace_ckeditor5_with_tinymce
added a text filter plugin in src/Plugin/Filter/TableTfootFixFilter.php
namespace Drupal\please_replace_ckeditor5_with_tinymce\Plugin\Filter;
use Drupal\filter\FilterProcessResult;
use Drupal\filter\Plugin\FilterBase;
/**
* Wraps orphan <tr> tags after </tbody> in a <tfoot> section.
*
* @Filter(
* id = "table_tfoot_fix_filter",
* title = @Translation("Fix orphan 'tr' after 'tbody' by wrapping in 'tfoot'"),
* description = @Translation("Wraps 'tr' elements that appear after 'tbody' with a 'tfoot' block."),
* type = Drupal\filter\Plugin\FilterInterface::TYPE_TRANSFORM_IRREVERSIBLE,
* weight = 101,
* provider = "please_replace_ckeditor5_with_tinymce",
* settings = {}
* )
*/
class TableTfootFixFilter extends FilterBase {
/**
* {@inheritdoc}
*/
public function process($text, $langcode) {
// Match closing </tbody> followed by one or more <tr> elements not already wrapped.
$pattern = '#</tbody>\s*((?:<tr\b.*?</tr>\s*)+)(?!\s*</tfoot>)#is';
$text = preg_replace_callback($pattern, function ($matches) {
return '</tbody><tfoot>' . $matches[1] . '</tfoot>';
}, $text);
// Process each <table> individually.
return new FilterProcessResult(
preg_replace_callback('#<table\b[^>]*>.*?</table>#is', function ($table_match) {
$table = $table_match[0];
// Match all <tbody> blocks inside the table.
preg_match_all('#<tbody\b[^>]*>.*?</tbody>#is', $table, $matches);
if (count($matches[0]) > 1) {
$last = array_pop($matches[0]);
// Replace last <tbody> with <tfoot>.
$last_tfoot = preg_replace([
'#^<tbody([^>]*)>#i',
'#</tbody>$#i'
], [
'<tfoot$1>',
'</tfoot>'
], $last);
// Replace the last occurrence in the table with <tfoot>.
$pos = strrpos($table, $last);
if ($pos !== false) {
$table = substr_replace($table, $last_tfoot, $pos, strlen($last));
}
}
return $table;
}, $text)
);
}
}
Enable this filter on all text formats using ckeditor5.
We also have a other text filter plugins in the please_replace_ckeditor5_with_tinymce module called VideoCleanupFilter.php and SpanLinkFixFilter.php . Perhaps we will have to turn the please_replace_ckeditor5_with_tinymce module into a full contrib project so that others can get our text filter plugins that put a bandaid on content that would otherwise be broken by ckeditor5.
commit a9fbc558d2969092b693412dcf36205bd6bc5fdd (HEAD -> 2.0.x, origin/HEAD, origin/2.0.x)
Author: joseph.olstad <joseph.olstad@1321830.no-reply.drupal.org>
Date: Wed Apr 16 00:42:24 2025 -0400
Change label
diff --git a/src/Form/SettingsForm.php b/src/Form/SettingsForm.php
index f2d4532..b77d97e 100644
--- a/src/Form/SettingsForm.php
+++ b/src/Form/SettingsForm.php
@@ -37,7 +37,7 @@ class SettingsForm extends ConfigFormBase {
'#type' => 'checkbox',
'#title' => $this->t('Enable dialog on node edit form'),
'#default_value' => $config->get('enable_dialog_node_edit_form') ?? true,
- '#description' => $this->t('It shows a confirmation dialog in edit form of any node type when state changes from non-published to published.'),
+ '#description' => $this->t('It shows a confirmation dialog when publishing a node from a node form.'),
];
$form['enable_dialog_admin_content'] = [
'#type' => 'checkbox',
Once this is correctly implemented as a configuration option then I'll re-consider merging. Should prompt by default, with an opt-out config setting.
Sorry my bad, this is by design, my clients that want this confirmation box would be surprised if it isn't there confirming a publish action.
The proper way to deal with this would be a configuration setting, pass it to drupalSettings and implement that setting in the js.
Actually, this is by design, my bad, I will revert the commits.
I will update the label instead.
joseph.olstad → made their first commit to this issue’s fork.
Prepare commit
joseph.olstad → created an issue.
Needing a fix for this.
Ok so possibly we may have stumbled upon the bug or broken functionality that is preventing the layout_builder_st tests from passing.
We have a site installed with French, french being the default language, English is a second language.
What we noticed is this:
"Layout tab only available on French translation, not English"
joseph.olstad → created an issue.
ok thanks for that, I'll have a look in jquery_once and check what's happening.
hmm, jquery_once isn't the same idea, what it does is add jquery once which was removed from core. Core now has an es6 once instead
whereas jquery_downgrade has to replace it. I prefer being able to control WHERE it gets replaced, that's why jquery_downgrade is designed the way it is, with that said, your feedback has been very important here. We probably didn't notice this during testing and implementing this.
Hmm, I pushed up a change, might help jquery_downgrade, have a look at the patch: https://git.drupalcode.org/project/jquery_downgrade/-/merge_requests/1.p...
@iancawthorne , did you try the merge request patch? it includes a new module called jquery_downgrade_force. apply the patch, rebuild cache, install the new module jquery_downgrade_force
I have the same issue as @liam morland
about to test the workaround which is to move the content_moderation_state directory away during the first import and putting it back for another import.
joseph.olstad → created an issue.
Here's the patch file https://git.drupalcode.org/project/jquery_downgrade/-/merge_requests/1.p...
@iancawthorn, you might want to try out this patch, maybe play with the weight setting, I adjusted it to -99, maybe it needs to go to -999 or maybe it needs to be set to 999 instead of a minus number.
Alternatively, I created a jquery_downgrade_force module , however be warned, this affects the admin side as well, might not be good to use.
Added search_api views hearts integration (available if installed)
joseph.olstad → created an issue.
@phenaproxima has done a significant spike on this merge request: https://git.drupalcode.org/project/layout_builder_st/-/merge_requests/26...
Looks like it might be as good as what we have hear and less commits/noise.
Would be good to get a manual test done on MR 26 to see if it works as well as MR 16.
📌 Make coding standards fixes Active
@danrod, @liam morland , I haven't had a chance to test this merge request on Drupal 11 yet, it looks like it'll probably do the job. Test results are similar to what we achieved in the 3431600-automated-drupal-11 branch.
Hoping this gets merged into dev, that would be enough to unblock our Drupal 11 WxT release. Even if it's broken but D11 compatible we would be able to patch fix it without using a composer override.
Hmm, so you adjusted your theme and it fixed it?
Improved it even more, now has a views data field plugin
joseph.olstad → created an issue.
2.0.0 comming right up
Ok lets go
joseph.olstad → created an issue.
agreed, open to reviewing merge request(s) or patch(es) for adjustment(s).
joseph.olstad → created an issue. See original summary → .
as a workaround you can downgrade jquery by theme selection in the configuration options. This should effectively downgrade it everywhere that your front-end theme is used. Rebuild drupal cache after adjusting the settings.
Hmm, ok, I'll try to reproduce. Thanks for reporting.
@rvilar , I've done a major spike on this, started publishing a 2.0.0 release, up to 2.0.0-rc1, it's getting quite advanced and functional with quite a bit more configuration options. A db storage option (fallback to cookie for anonymous users.).
I would really like to be able to have a bit more permissions for this project seeing as I just put two solid days into it.
I'll put some screenshots up:
Now for the heart block:
Unselected:
Now for a selected heart
patch file for D10.4.6 , upgrading a D10.3.x site for a client
joseph.olstad → created an issue.
joseph.olstad → created an issue.
Checking crediting system.
One down, one to go:
https://www.drupal.org/project/toc_api/releases/2.0.0 →
Next is lightning_builder_st , praying that phenaproxima goes ahead with some sort of a move forward. A branch, or even just a merge to dev.
Creditting
Merging
Thanks, here it is!
https://www.drupal.org/project/simple_favs/releases/1.0.0-alpha1 →
Joseph
We need this merged and a release tagged asap, this is a release blocker for our distribution and we're looking to publish our Drupal 11 release in the next week or two at the latest!
Hello Ramon, could you please also tag an alpha release and publish it so that it shows up as supported on the project page for simple_favs? I could do this for you if you grant me enough permissions.
Thanks!
joseph.olstad → changed the visibility of the branch 1.0.x to hidden.
joseph.olstad → created an issue.
@phenaproxima, thanks for this. There's a lot of changes accumulated and they look good, would be good to merge this in and we can open up a followup issue for the 4 test failures. We will definately be putting the 8.x-1.x branch through it's paces in real world scenarios using D11 once this is merged.
Would be good to see what the error logs (php error log) shows.
Thank you @tunic!