PLIP: content quality check before publishing

[tkimnguyen]

add content quality check before publishing

Responsible Persons

Proposer: T. Kim Nguyen

Seconder: Gil Forcada @gforcada

Abstract

A modern CMS must help create and maintain high quality content.

One way to maintain high quality content is to set standards on all content about to be published.

These standards could include:

• spell checking
• accessibility compliance
• checking that linked content is published
• checking for broken links (internal & external)

Castle CMS includes a quality content check that runs several such checks. Optionally, the content quality check can be REQUIRED, ie. if any checks fail, the content cannot be published.

Motivation

The response to the Castle CMS quality content check has been unequivocally positive and is a fantastic feature to include in Plone.

It also solves the problem of File and Image types not having their own workflow state, which leads to other problems (such as unintended publication of Files and Images because their containing folder is published; solutions to THAT problem require further contortions, such as having to display visibility warnings on File and Image content items).

By having a quality content check that includes verifying that linked File and Image content items are published, we can go back to giving File and Image types their own workflow state.

Assumptions

Proposal & Implementation

Deliverables

Risks

Participants

[jensens]

Overall I like the PLIP. A few thoughts:

• parts of the feature are also great for editors even if one uses one-state workflow (always published), other parts do not make much sense.
• the check must not slow down the "save" and prolong the transaction.
• spell checking should work in a wide variety of languages, it must also work together with plone.app.multilingual.
• internal "link" checking should include also reference fields.

I would like to see a pluggable/ttw-configurable solution where an integrator can en-/disable single features (like external link checking yes, but no spell checking).

An addon developer must be able to extend the system with a new feature (i.e. like checking for correct gendering, correct usage of company internal terms, ...). With our component architecture this should be simple to implement.

[fulv]

Is the scope of the PLIP too wide, perhaps? If we are trying to solve the issue of versioning/workflow of File and Image content types, then a generic content quality check might be too ambitious. However, I also want to point out that collective.jekyll has a very elegant "symptom"/"diagnosis" content quality model that uses the ZCA to great advantage. I would only improve it by adopting the catalog indexes and workflow guards that were implemented for the same purpose by one guy who gave a lightning talk at ploneconf Boston.

…

On Tue, Jan 3, 2017 at 12:06 PM Jens W. Klein ***@***.***> wrote: Overall I like the PLIP. A few thoughts: - parts of the feature are also great for editors even if one uses one-state workflow (always published), other parts do not make much sense. - the check must not slow down the "save" and prolong the transaction. - spell checking should work in a wide variety of languages, it must also work together with plone.app.multilingual. - internal "link" checking should include also reference fields. I would like to see a pluggable/ttw-configurable solution where an integrator can en-/disable single features (like external link checking yes, but no spell checking). An addon developer must be able to extend the system with a new feature (i.e. like checking for correct gendering, correct usage of company internal terms, ...). With our component architecture this should be simple to implement. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1894 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcHxoPkiyxEd4ITpvqWX9FkWy-6AAuVks5rOpw6gaJpZM4LZ595> .

[jensens]

@fulv probably you’re right. I think a basic, pluggable system in core is great, while a wide variety of checks may live as addons.

Since we have internal link checking already; this may be provided with p.a.linkintegrity as a default plugin as a kind of reference implementation. This could also help making p.a.linkintegrity better.

Given there are implementations out already, we should look at them carefully before reinventing the wheel.

[spereverde]

@jensens some thoughts on your thoughts :-), since we have some content checking done by collective.jekyll on all of our university websites

• I would like to see a pluggable/ttw-configurable solution where an integrator can en-/disable single features (like external link checking yes, but no spell checking). - this is available ootb in collectiev.jekyll via the Control Panel, checkboxes are available for every 'rule/content check'. Default jekyll rules and extra rules from your own add-ons all show up in the same control panel configlet.

• An addon developer can very easily extend the system with a new feature. The collective.jekyll was specifically made to allow this.

• the content checking does not slow down the saves in any way, however when developing extra 'content checks' in your own add-on you need to pay attention that the edit view loads quickly enough (using beautifulsoup decently)

[spereverde]

PLOG 2019 update: there is a general consensus that this is an important feature for Plone.
We will attempt to list and decide upon the default rules that would be needed to get a basic version of content quality checking into core and add some features for new rules that could be added later.

[jensens]

Best way to get this into core is to have a full working add-on with all features implemented first and then merge into core. If new hooks/events are needed in core, those can be added prior.

I think this can go the same way as plone.login, collective.indexing or collective.navigation. I hope faster than the first two :)

Most important: It is not enough to have a general consensus that it is important to have, there must be people (at best: paid) writing core-quality code, going the full path from addon to core to get it in.

Besides that, today the scope has to include the plone.restapi/Volto usage-story of this feature and the PLIP need to be expanded here.

[jensens]

At today's Framework Team meeting we discussed this PLIP. The Framework Team recognizes the importance of the feature.

• We agreed to have it as a mature add-on first.
• If it is created in the plone organisation, with contributor agreements, a later merge is possible.
• If there are any new hooks in Plone are needed, they can be proposed as simple enhancements.
• once mature, we tend to include the feature as an add-on shipped with Plone, like multilingual or iterate.

Anyway, overall the proposal is not complete, so we can not vote on it officially.