I work for Radio Free Asia.

Let's jump right into the problem. There should be some kind of 'hook' to modify 'stuff' before we send it to 'the browser'. For example: TinyMCE images, safe-html transforms, Mosaic blocks. Intercept the response, do something with it, and send it on.

The solutions in Plone: plone.outputfilters and plone.transformchain.

plone.outputfilters: tools for modifying field values when you get() them. Demo: add an image and then use this in a news item or document in TinyMCE. Save it, and you see the caption of the image. Where does this come from?

• story.text.raw has just an image.
• story.text.output suddenly has a caption.

plone/outputfilter/browser/configure.zcml has a browser page plone.outputfilters_captioned_image. If you don't like it, you can easily override it with jbot, overrides.zcml or a browser layer.

For Radio Free Asia, we want AMP. This is a special webpage for Google to quickly show news items, and Google caches it. We need an updated caption for this, but only when there is an AMP request.

First try: special browser view, let it add an interface on the request, and let the snippet return something else.

Problem: the output is cached, so you have the original non-AMP answer in a Zope cache.

Plone Outputfilters hooks into the Products.PortalTransforms machinery. It registers its own mimetype and transform for safe html transform.

Solution: create a new mimetype text/x-html-safe-for-amp and transform policy. Manually call the transformer in the browser page. We now have two versions of the caption snippet in the cache.

On to plone.transformchain. It provides methods to modify the response from a page before it is returned to the browser. It is used by plone.app.theming, plone.app.blocks, plone.protect, plone.app.caching, etc. They are called in a specific order.

At RFA, we use this to convert between language alphabets. Uygur Arabic is transformed into Latin or Cyrillic.

We have some example private code, you can send me a mail to get access.

The old installer needs updating.

In the past we had the UnifiedInstaller. This tried to do all in one: install Python from scratch at first (not anymore), buildout based, support as many OS as possible. It has become too complex and won't be used for plone 6.

In the future we want to use the standard tooling. There is tooling for backend Python and frontend Node. Python and Node themselves are widely available. Use pip and npm to install backend and frontend. Use containers / Docker.

So: no installer. But we have tooling.

• Use pip install Plone
• Use pip to install add-ons.
• Use standard Zope scripts to create the instance.
• npm run yo init @plone/volto to bootstrap your Volto frontend.

You may now say: "Stop! This is a lot to install on my machine!." So we use containers:

docker run plone-[webserver|frontend|backend|database]

Run it in Docker of Kubernetes. Inside it, we run:

• webserver: nginx (or Traefik, Caddy)
• frontend: Volto
• backend: Plone application server
• database: ZEO+blobstorage, or PostGreSQL (recommended) or MySQL/Oracle

It is easy to start with. You can do local development with containers. It integrates well with CI/CD processes. The container image is a frozen version of the whole application. So you have isolated environments and repeatable deployments.

Workflow example:

• Two repos or directories with backend and frontend customizations
• Dockerfile
• Setup Gitlab CI/CD workflow to build containers and store in registry.
• Auto deploy to testing/staging/live.

You could use Ansible and similar tools (I won't).

Disclaimer: this is work in progress. Official images:

• https://github.com/plone/plone-frontend
• https://github.com/plone/plone-backend

This needs help.

• Try the new setup.
• Ask questions at community.plone.org
• Is it inconvenient? Tell us how to improve.
• Have you found a problem? Create an issue.
• Have you fixed a problem? Create a pull request.

Relations in Plone are incredibly powerful. It has lots of sophisticated options. But Plone does not use most of them. Plone here is like a toddler in a Lamborghini.

You can use relations in fields, and Plone also uses two relations without fields:

• working copy (iterate)
• linkintegrity checking

There are at least nine packages required to build one simple relation. Is that okay? My answer: yes, that's all fine. Why? It is stable, very fast, very flexible (more than Plone needs), and documented. Well, the documentation is difficult.

What's new in Plone?

1. We now have a sane Python api for relations:

   api.relation.create
   api.relation.get
   api.relation.delete
   

Get all friends who have a relation with Bob:

api.relation.get(target=bob, relationship="friend)

Get all relations of Alice:

api.relation.get(source=alice)

Create a relation between Bob and Alice and store it on a field with name "friend" if it exists:

api.relation.create(source=bob, target=alice, relationship="friend")

You can use this in Plone 5 on Python 3. On Python 2 you can use the similar collective.relationhelpers.

2. We have a controlpanel for relations.

You can inspect relations and back relations. It also has a magic "Rebuild" button. This will purge all relations, and restore them. This is useful, especially after an in-place migration, to get rid of broken relations.

In Plone 6 this is built in. In Plone 5 you can use `` collective.relationhelpers`` but you need to remember the url of the controlpanel.

3. Helpers to manage, inspect and rebuild relations.

See from Products.CMFPlone import relationhelper.

4. Better and more relation fields

There are default relation fields with default widgets, but you now have more choices for the widgets.

A nice helper is the new StaticCatalogVocabulary that you can use a vocabulary.

Documentation and examples:

• example.contenttype.
• https://training.plone.org/5/mastering-plone-5/relations.html

You can also do relation fields without relations: store a uuid instead of a relation value. You can use a schema.Choice field with a RelatedItemsFieldWidget. But watch out: when you delete a content item that this field points to, Plone will do no cleanup for you. For relations, this does happen.

What about Volto?

• The related items field is not displayed.
• RelationChoice is broken
• None of the new widget types work

We need to fix those, and I have filed issues for them. Also, we may want to have an endpoint in plone.restapi to query relations.

As a kid, I played tennis. I was taught to hit the ball hard, and as close as possible over the net. Nowadays, trainers tell you to hit the ball slower, hit it longer, giving you more control, with topspin. So that is a trade-off between power and control.

A traditional, classic CMS is usually stuck in the past. Using dead technologies, like jQueryUI, an old stack. That is partially true for Plone 5 as well, although it looks prettier than most of the others.

WordPress uses the Gutenberg editor. Whenever I try out WordPress again, I keep having the feeling: I am not smart enough for this. I add a few images, and want to make them look the same size. They have lots of controls for that. Eventually I succeed, because I am a web developer. For text, you can choose lots of sizes and colors.

But: I am not a designer. I can accidentally pick a color combination that does not work for colorblind people. I don't know all this, so I tinker around and end up with a bad product.

The web is hard. You need a consistent design. Designers themselves are specialized into UI or UX. It needs to be responsive.

Plone 6 is not a classic CMS. It is a modern CMS providing both power and easy of use, and I think it is the only enterprise CMS that offers this.

Albert Casado created the Pastanaga UI. In the toolbar you see options to add or edit or order content, and the rest is still there, but hidden. For image alignment we show four options, and for size three options. This is simple, but it already gives you twelve possible combinations.

The Plone 6 UI is all about blocks, blocks, blocks. Responsive design means you usually have only one column, instead of the three that you can have in Plone 5.2. That single column will be a stream of blocks.

In Plone 6 you can use grid layouts. We started from scratch a couple of times on this, but we have something good now.

We have a teaser block. This is often used for landing pages. You add a teaser block that is linked to an existing content item, and it will show its image, title, description.

Plone 6 will ship with a few default blocks, like text, image, video, table of contents, etcetera. There are about a hundred Plone packages on npm now which have their own blocks. The Plone company Eau de Web works for the EEA (European Environment Agency) and they open source all their blocks, for example a faceted search block. RedTurtle created a forms block. Some others did as well, and then we usually cooperate and end up with an improved version.

We have "No Code Content Types". You can create contenttypes TTW in Plone, but what was always missing, was templates so you can customize how they look. We now have that.

The Volto frontend that will be in Plone 6 is in production use since 2019. A top German government institution uses Plone 6, American universities, Osaka University in Japan, EEA in Europe, many municipalities in Italy.

Today you can use battle tested Plone 5.2 plus Plone REST api plus Volto. That is already Plone 6-ish. You can also use the real Plone 6 alpha release.

In the past, all Plone versions were supported for many many years, but we never really advertised it. Now the Release Team and Security Team have said they will support Plone 6 for at least five years.

If you are not ready yet and need more time before you jump on Volto, then you can use Plone Classic UI. There is no need to rush, we have got you covered.

Summary: Plone 6 provides something really unique.