PW 3.0.203 – Core updates + custom fields for comments

[ryan]

This week on the dev branch are several updates to the comments system including support for custom fields on comments (which we're calling comment meta data).

I'm currently working on a site that uses a reviews system powered by BazaarVoice. It's pretty nice but it's also very expensive (I think at least $500/month in this case). The system powers their reviews which include not just a rating and review text, but also a bunch of other criteria that the user can provide. See an example here — click the "Reviews" tab and what you see there now is currently coming from BazaarVoice. But in a couple of weeks you should see the same thing powered by ProcessWire. 

Think of this like a comments system with custom fields. That's not something that ProcessWire has supported before, but now this week it does. Though I know most don't need this, so have kept it pretty simple, focusing just on adding API methods to make it possible to get and set custom field values for any comment. These include:

$comment->getMeta('name'); 
$comment->setMeta('name', $value);
$comment->removeMeta('name'); 

The name and $value can be whatever you decide. There's also a bonus $comment->meta() method which combines the methods, letting you get or set, kind of like the meta() method on Page objects. 

If you want to use comment meta data like this, it's exclusively an API feature. So if you are looking to collect custom fields from users, you'll want to implement your own comment form rather than the default. In our case, we'll be using FormBuilder to implement the comment form that includes the review and custom fields. But you could just as easily use a homegrown form.

When it comes to outputting that custom data, you'll want to handle it more like you would outputting a repeater, iterating through the $page->comments and then using $comment->getMeta('name'); for each of the custom properties you want to output.  Worth noting is that output formatting doesn't come into play here, so if some text in the meta data needs to be entity encoded for output (for example) then that's your responsibility. 

How about later editing of the meta data? Should you need it, the ProcessCommentsManager module (Setup > Comments) has been upgraded to support editing of comment meta data. Next to each comment is now a "Meta" link, and if you click it, you'll get a modal window on top of the comment enabling you to edit the meta data as JSON. That might seem a little unconventional, but I'm trying to keep it simple and flexible. Most will probably use this to view meta data rather than edit it, but the ability is there when/if needed. I didn't think it would be worth spending the significant time building a full-blown page-editor like environment for editing comment meta data, but also felt like I needed something like this for occasional editing needs.

The InputfieldCommentsAdmin module was also updated to have meta data links for each comment. But the reality is if you have ProcessCommentsManager installed, chances are you aren't editing comments in the page editor anyway. So a new option has been added in the comments field configuration (Input tab) enabling you to disable comments in the page editor and instead link to the editor in the comments manager. When enabled, your Comments field in the page editor would instead look like this:

This is worthwhile because the comments manager is just a better place to view/edit comments in the admin since it is paginated, supports editing of all properties, and lets you sort/filter as you see fit. Whereas a big list of comments in the page editor just slows it down. 

This week the CKEditor version has been upgraded to 4.19.0 (see release notes). I'm also emailing with the people at CKEditor about getting us a license to use CKEditor 5 with ProcessWire. As you may or may not know, the CKEditor 5 license (LGPL) isn't compatible with ProcessWire's license (MPL2 and MIT), so we are working on a license agreement to make it possible. Since CKEditor 4 will reach EOL in 2023 it's a good time to start planning for CKEditor 5 and I'm excited to work with it. 

Thanks for reading and have a great weekend!
 

[teppo]

3 hours ago, ryan said:

As you may or may not know, the CKEditor 5 license (LGPL) isn't compatible with ProcessWire's license (MPL2 and MIT), so we are working on a license agreement to make it possible.

Just to be clear: CKEditor 5 is licensed under GPL, unless I'm mistaken. LGPL would likely be less of an issue (if not a non-issue), since it's relatively permissive (no strong copyleft, dynamic linking with proprietary code allowed, etc.)

Anywho — very interesting to hear that there's a (likely) roadmap to 5 in the future ?

[Ivan Gretsky]

On 7/16/2022 at 2:57 AM, teppo said:

Anywho — very interesting to hear that there's a (likely) roadmap to 5 in the future ?

As far as I know CKEditor 5 is quite a different beast and transition to it would require some massive changes. But it surely could bring a lot to the table. Maybe even some basic content builder functionality.

[Zeka]

As @Ivan Gretsky said, the core of CKEditor 5 has changed and implementing it in PW will require significant changes, so maybe we should consider other options like https://imperavi.com/article. It is also used in Bolt CMS (not a promotion). 

[pwired]

Page not found (july 17 - 17:00 gmt) - -  tried with 3 different browsers

https://imperavi.com/article

Edit: link is working

[Ivan Gretsky]

19 hours ago, Zeka said:

As @Ivan Gretsky said, the core of CKEditor 5 has changed and implementing it in PW will require significant changes, so maybe we should consider other options like https://imperavi.com/article. It is also used in Bolt CMS (not a promotion). 

That one seems to have a paid license, which is probably a showstopper for having it inside the core.

[pwired]

Quote

Since CKEditor 4 will reach EOL in 2023 it's a good time to start planning for CKEditor 5 and I'm excited to work with it. 

Is it really necessary to have CKEditor 5 in Processwire ? Is CKEditor 4.x not more than safe and powerful enough already ?
CKEditor 5 will not make more productive neither make a website client more happy. It will only make things more bloated.
At least leave the option with the user and client to choose CKEditor 4.x or another simple Editor for the client.

Most clients are non-tech people occupied with business for whom something like CKEditor 4.x is already complicated.
 They will never use all its options anyway. All they need is to change some prices, text and pictures.
 So please leave the option for the client to choose a simple Editor.

Quote

the core of CKEditor 5 has changed and implementing it in PW will require significant changes,

What made Processwire stand out from the crowd was its focus on a versatile and powerful api with a core free from bloat.
How much of that is still true ?

[szabesz]

On 7/17/2022 at 8:20 AM, Ivan Gretsky said:

As far as I know CKEditor 5 is quite a different beast

I would rather see CKE4 being replaced with https://easy-markdown-editor.tk/ as I and my clients really don't like the complexity of CKE4, and CKE5 is even more complex than version 4.

I know that Easy MarkDown Editor is not as WYSIWYG as CKEditor but I could never set up CKEditor to be a true WYSIWYG editor anyway. Maybe it just my fault, I don't know.

Anyway, at least Easy MarkDown Editor could be added to the core as an additional option. So in the end there would be CKEditor 5 and Easy MarkDown Editor, both being integrated as much as possible.

[MrSnoozles]

Article editor is nice and much more lightweight than CKEditor. @Marcjust posted an example of how an integration could look:

And while CKEditor might have more features in general, for editing website content I think Article offers greater flexibility and is easier to use.

----

@ryanI once wanted to add images to FieldtypeComments, so each comment can optionally have one or multiple images attached to it. Is that something that could be supported too? If not, could you think of an easy way to integrate images into comments?

[teppo]

Article looks great, but their licensing model is indeed problematic. Folks at Bolt likely got a custom license (or perhaps paid OEM license) to use it, but on what terms is hard to say — I couldn't find specifics about their licensing terms. Only thing they do say is that it's available for use "in Bolt itself", which is a bit vague.

It's up to Ryan whether he finds this interesting enough to contact Imperavi and query about license ?

Either way, I wouldn't count CKEditor 5 out of the race quite yet. To me personally it looks UI/UX wise like a solid upgrade over CKEditor 4. I do remember that it seemed potentially "too different", and there were some relatively basic features (which I can't for the life of me remember anymore) from v4 that the devs originally said would be very difficult or nearly impossible to implement in v5, but that was a long time ago so perhaps things have changed.

On 7/18/2022 at 9:24 AM, pwired said:

Is it really necessary to have CKEditor 5 in Processwire ? Is CKEditor 4.x not more than safe and powerful enough already ?
CKEditor 5 will not make more productive neither make a website client more happy. It will only make things more bloated.
At least leave the option with the user and client to choose CKEditor 4.x or another simple Editor for the client.

Most clients are non-tech people occupied with business for whom something like CKEditor 4.x is already complicated.
 They will never use all its options anyway. All they need is to change some prices, text and pictures.
 So please leave the option for the client to choose a simple Editor.

First of all, CKEditor 4 being EOL'd in 2023 is a huge reason to move on. There's no guarantee of updates after the EOL date, which includes potential security updates. ProcessWire is relatively safe since most of the time CKEditor is used by trusted users, but there are cases where that isn't necessarily true. And even if it was, there could still be vulnerabilities that third parties can abuse.

In my opinion it's painfully obvious that we must drop CKEditor 4 support from the core at some point in the future. If some prefer to keep using EOL'd software (which I would personally recommend against), there's always the possibility of stripping it from the core and converting into a separate, possibly community-supported module.

For me personally CKEditor 5 seems like a logical next step, but admittedly I've not used it enough to know if it's really going to be feasible, let alone how much work it will require. It's a good idea to check out what else there is, but CKEditor has quite a few things going for it as well: plenty of features, solid UI/UX, longevity of the project, active community, being open source with no costs or limiting licensing rules, etc.

As for ease of use, I absolutely agree that this is vital. And in this regard CKEditor 5 feels like a big step up — if anything it feels less confusing and more streamlined than earlier versions. I would not expect my/our clients to have any trouble with it. Give it a try and see for yourself, and do keep in mind that CKEditor 5 is configurable: features you don't need can be disabled ?

Just my two cents.

On 7/18/2022 at 9:24 AM, pwired said:

What made Processwire stand out from the crowd was its focus on a versatile and powerful api with a core free from bloat.
How much of that is still true ?

100%.

[Jonathan Lahijani]

I'll mention Quill: https://quilljs.com/

[szabesz]

12 hours ago, teppo said:

And in this regard CKEditor 5 feels like a big step up — if anything it feels less confusing and more streamlined than earlier versions.

Besides being able to format docs easily and without too much confusion, the editor should be as "lightweight" as possible, JavaScript-wise. I mean that PW should be able to load a lot of editors into – for example – repeaters without ajax loading. Ajax loading should be a last resort option, let's say when more than 50 / 100 (perhaps?) editors must be loaded by a page.

[teppo]

4 minutes ago, szabesz said:

I mean that PW should be able to load a lot of editors into – for example – repeaters without ajax loading. Ajax loading should be a last resort option, let's say when more than 50 / 100 (perhaps?) editors must be loaded by a page.

This is why I always prefer the inline mode for CKEditor: very little is done until needed, which speeds things up nicely, yet setting up a new RTE field (when it is needed) takes maybe a few hundred milliseconds (assuming scripts and/or styles need to be loaded, otherwise it's nearly instantaneous).

No matter how you do it, adding elements to DOM tends to slow things down. The more you add, slower things get. That is why Ajax loading is great for things that are needed rarely, while things that are needed most of the time can and should be loaded right away ?

[bernhard]

I just wanted to mention that I hope that our new editor will still be a rich text editor and not a page builder (like the mentioned "article" editor) - imho we should not mix those two! I've done a lot of work and research in that regard over the last two years or so and I'm now very happy with my repeater based content builder. When I started I also looked at editor.js as the interface looked neat. But I couldn't even manage to build a single custom content element with it. It's an editor for JS artisans and not for PHP devs like me (us?).

A repeater based content builder has the huge benefit that we can simply use all the existing fields that PW provides. If at some point someone created a new field that would most likely just work within a repeater. Having a new editor interface with a totally new storage concept would mean we'd need to build all those block's for the editor and we could not use them outside of it.

What about Multi-Language? The example above shows a nice page builder, but I wonder how multi-language would work with such a field? In a repeater-based setup we can just install LanguageSupport and make those fields translatable.

PS: Using a matrix based approach makes CKEditor fields usually super simple! Like this one where only bold text and links are allowed:

[wbmnfktr]

Just a little rant:

Please don't turn our textarea/RTF-fields into something like Gutenberg or similar.
As a module, ok. But please... not as the default option.

I'm not that deep into all the details about those RTF-Editor tools/scripts but what's so bad about staying with CKEditor 4.x for a while as it's stable and mature enough. Never had any issues with it.

 

[BrendonKoz]

I feel bad bumping this topic, but I think some people might've missed, or misunderstood the importance of the reasoning for looking towards moving away from CKE4. The codebase of CKE version 4 will essentially be abandoned as of sometime in 2023 by the organization that maintains it. Considering the large amount of security issues that are consistently discovered in heavily used input/output handling JavaScript packages (whether due to custom add-ons or its core), and the fact that Ryan strives for a very secure system... The need to provide an alternative WYSIWYG module is evident.

CKE5 seems like the least intrusive option (for users/clients). It appears as though he hopes to make it fairly seamless for site administrators and developers, but the integration changes aren't a 1:1 swap, so he'll have quite a bit to consider.

It's likely that you'd still be able to use CKE4 as a module, just like you could continue using TinyMCE when it was removed from core -- as a separately installable module.

If you wish to use standard textarea fields or Markdown-powered fields, there are add-ons for those too (already). You will still have choice, and that's one of the excellent things about ProcessWire. The only issue here is that Ryan wants to make sure that you and your clients have a stable, secure, and usable system. As always, you will still have control over your own system(s). ♥