I can’t really speak on CKEditor, but here’s some thoughts:
My view is that with any CMS you shouldn’t be relying too heavily on the more complex controls of a WYSIWYG editor. Whilst it’s really handy to have some controls to do things like apply a class to a heading or a piece of text I’d suggest that editing really should just be about adding headings, paragraphs, lists, a few inline images, etc, just the common content/HTML stuff. If you’re doing very complex things within the editor, I’d think those are best handled with some custom blocks, where you can very closely control the output. It also makes future re-brands much easier, as you’re dealing with cleaner HTML.
we’ve been able to upgrade sites from 5.7, to v8 to v9 successfully many times. Sites with few/simple add-ons end up quite easy, whilst sites with lots of add-ons have taken more work, mostly because lots of add-ons need replacing or manually updating. In these latter cases, it can take a bit of work, but most of the time it’s just cleaning up some undefined variables that PHP8 complains about. A competent PHP dev can do this.
But the biggest challenge has actually been the PHP version update of PHP7.4 to PHP8, not so much Concrete’s design or major version changes. I think now that V9 is on PHP8, I think future version upgrades are going to be cleaner.
About Less compilers, I’d suggest that you really shouldn’t be compiling stylesheets on the server anyway. The Less compiler is included to facilitate themes that have styling options, and it handy for that. But if you’re building a custom theme for a site those controls aren’t needed, you should be compiling everything in your development workflow.
We’ve used Sass (and Less) to build a large number of custom themes over the years, and never have I compiled those themes on the server.
I thought Bootstrap 5 moved to Sass as the default, dropping less… or maybe both is now supported, but Sass is what is encouraged.
There are plenty of themes that use the built in LESS compiler. It needs to stay for the same reason it was put back into v9 (v9 was first released without it).
Yeah- CKEditor has to go in the big picture. Some PE firm has bought it (and TinyMCE too) and is doing what they can to moneitize the editor space. More power to them, it’s not an easy problem to solve and it’s a bit weird that we’re all going to depend on these editors for countless SaaS apps yet expect them to be free. That said, the approaches they’re taking with their core license kinda make it a non-starter for a MIT licensed open source cms like us to include it. It’s a shame, as I’d be perfectly happy to upsell their extensions - but here we are.
There’s already been some prototyping of different approaches with v10.
We also know that we need to at least leave the LTS version of CKEditor that we do have rights to distribute in there for a while as there are any number of extensions that use it in hard coded ways.
Our vision for v10 would be a new default editing experience, but being careful to try our best to not bork old solutions that work.
I would expect the same to be true for bootstrap, LESS, and frankly any other approach we have in the core today. The focus for v10 is to fix bugs, update dependencies, and deal with the CKEditor issue. A combination of polishing the last 10% and trying to buy some long runway for future version support.
There’s always talk of exciting new template engines and what not, but to be direct - we need Concrete to work the way Concrete works. It’s more important to me that existing projects that depend on it behaving in a certain way can continue to work over embracing whatever is the new front end hawtness. Such is life.
Really liked the comments in the town hall Franz, sounds like version 10 is going to be epic.
CKEditor is obviously going to need to be supported for some time, but there’s already been some discussion somewhere about what alternatives are around (I can’t remember where that was).
I just had the thought to look at what Payload CMS uses, which is a headless CMS with a lot of popularity at the moment.
Interestingly they made a rich text editor switch at one point - they used to use one called Slate, but now use call Lexical (from Meta) - https://lexical.dev/
Lexical looks really interesting in that:
it’s MIT licensed
supports vanilla javascript
huge amount of interest/activity on Github
designed to be extended with plugins, lots already exist
looks to be able to support custom style/class functionality like we have via page_theme configs
and the fact a big CMS is using it, and it’s Meta supported is arguably a really good thing for longevity
The main difference is that it’s not using HTML under the hood, but more of ‘state’ of the content. It does look like they’ve got nice ways to convert back and forth with HTML, so Concrete wouldn’t need to store that state - but a lot of editors work this way these days and I’m sure there are lots of advantages.
I like it! The example in the playground is easy to use. I like that it has the debug view. Also some niceties such as convert from markdown. The toolbar is fairly self explanatory.
The only thing I regularly use that isn’t in the playground demo is a direct html edit/view. Looks like there is an extension for translating to/from html, so maybe it could be partnered with Ace for the html view.
Lexical looks great, but I also started to develop a CKEditor 5 add-on. CKEditor is not a good option for our open-source project now, but it is still a good choice for those who can buy their commercial license.
We have sites with many editors using a lot of Ckeditor inline styles.
I define typography styles in application\config\site.php
What would be a safe method defining these styles for a future text editor?
I’m afraid that if a new editor is chosen for CMS v.10 all our styles go away, breaks editor block code and we have to start from 0 when sites are updated.