We, Plone developers, are architects. We build a sand castle. Then users play with it, love it, and break it. Children play with it and it gets broken. (Watch short video Les Vacances.) Conflict: users love it and want new features, and we despair. So we build a nuclear power plant. Unbreakable, but the users cannot play with that any longer. Well, maybe terrorists can play with it, but they are not are target audience.

Pharmakon: any medicine is also a poison.

Build an inflatable castle instead: it is bouncy (more fun for the children), robust (more fun for us), and terrorists do not like it.

Hackability is a feature. It is not a flow. It must be provided as a tool, something on top. If we lose this, we will lose part of our audience. We should have a hacking tool, not a hackable system. A moderen and pleasant web interface.

And we have it: the ZMI. Well... Using framesets, really?

We have the Plone theming editor. It is already a hacking tool. Non-Plone experts can change the entire theme. The Diazo theory behind it, is: "We write XSLT so you don't have to." In reality I am writing tons of XSLT, because there is a really detailed theme layout and lots of pieces of content that need to be hand-picked into it.

We need on-the-fly content changes with before and after: on-the-fly content insertion, also from 'remote' to insert a small page. We have this working, but it is not merged yet.

We want more. Create our own chunks of content and scripts when you only know Python and javascript, and some simple diazo to include it in your rules. This is what Rapido offers. Rapido is not a new Plomino, it is something different.

Rapido lives in the theme. Editable in the Plone UI or in the source. And then we use Diazo to inject it into Plone.

It is very simple. No zca, no zpt (or any templating language), no jbot, just html and python.

Demo. [Looks quite nice, check the video once it is uploaded.]

We use souper for persistance. You can store on the context, or on the user, or what you want

Is it secure? Python scripts are executed by zope.security.untrustedpython. All the regular security stack is applied, like current user privileges, CSRF policy, PostOnly. Just as secure as Diazo.

Rapido comes with a complete REST api with GET, POST, PUT, DELETE, PATCH. It is a ready-to-use JSON backend.

Rapido is Mosaic compliant, but does not depend on it. We just make a tile available to insert a Rapido element.

Questions?

Yes, you can import and export it and include it in a package or have it as a zip file, so you have it on the file system.

When will it be included in core? Not now. We may talk with the security team.

Debugging? More difficult: you cannot add a pdb, same as in the Python skin scripts. We can make something possible, at least show on which line something goes wrong.

Philip: You still need to know Plone when you access for example the portal root in the code you create. I am not sold on it, just like I was never a fan of .cpy files. You lose debuggability. But yes, it lowers the barrier of entry. I am not the target audience.

There are of course permissions, so you can decide who can use this. And you can use access lists in a yaml file.

Use the PageSpeed tool to measure your page and get hints for improvement.

Move javascript from the head to the bottom.

• You can do that with Diazo rules or through the web.
• But you can get flashes of unstyled content. Check this. There is no one silver bullet solution. See if you can do some transformations not in javascript but in a different way with css.
• Random javascript could break, if it expects jQuery or other javascript already available, especially if they get loaded inline. Usually loading on document ready should solve this.
• Plone core may move the javascript to the bottom some day, there is discussion.

On Plone 4, with portal_css and portal_javascripts, you can reorder the css and javascript to fit more together. Currently you often have for example member.css in the middle, restricted to only members, and this condition splits the top and bottom css files in two. Move the member.css and then anonymous users need just one combined css.

Check the caching rules, especially for files like the favicon and the logo that will almost never change.

Online tools and background information for css:

• Use http://csslint.net to check your css.
• Another tool: http://www.stylestats.org
• Make your css as simply as possible: http://csswizardry.com/2015/04/cyclomatic-complexity-logic-in-css/

Optimize your javascript:

• PhantomJS-based web performance metrics collector and monitoring tool: https://github.com/macbre/phantomas

Document decisions and best practices in a style guide.

• Eric Steele: "I think we should set up a style guide for the core UI." See https://github.com/plone/Products.CMFPlone/issues/589
• There are automated style guides, for example kss-node, StyleDoccu, DocumentCSS, Hologram. Many need different stacks, and the generated guide may come out very ugly.
• The EEA style guide: http://www.eea.europa.eu/code/design-elements
• Plone has the test_rendering page that has all (or most) design elements of Plone. We could run https://github.com/filamentgroup/X-rayHTML over this. Add a data attribute and then this shows the generated page and makes the html itself visible.
• Make it easy to maintain, by having the style guide in the same website that it is meant for.
• Further reading: http://styleguides.io
• Documentation: add comments in css explaining why you do something.

We need to monitor for regressions.

• Automate tests with Travis, using headless browsers.
• psi command line tool
• Grunt-PerfBudget

In closing:

• Measure your site performance regularly.
• Presentation by Addy Osmani: https://speakerdeck.com/addyosmani/css-performance-tooling
• Style guides from github: https://github.com/styleguide

Plone has a good back end. On the front end lots of stuff is happening with javascript framework, in the brave new Javascript world. The three of us have some personal opinions on the front.

JSON is used to let front and back end talk to each other, for the client and server architecture.

A json rpc api would do a POST to somehost/api, with a method like create_content and give it a type, title, container UID. This is brittle: as soon as you change a detail in this api, you break this. And you do not notice, until someone uses it, unlike a python error that you often discover when the server fails to start up.

You can use multiple URLs. POST to somehost/api/my-folder. Slightly better, you do not need to pass the UID.

You could use all HTTP methods: GET, POST, PUT, DELETE, using the same url with extra parameters. This is what people talk about when doing web apis: REST. An other way to talk about it, is CRUD: Create, Read, Update, Destroy

New package: plone.rest. Register an http method in zcml for an interface of a content item. In your request, tell Plone that you accept json, and plone.rest will return json to you.

You have REST, which is a set of restraints to what such an api should do, and you have hypermedia. This decouples front and back end, in a way that allows you to change the api and without needing to change your client. The client goes to a single entry point and follows links from there. For a proof of concept we used JSON LD and Hydra. You get json with a list of links to members of a folder, including operations that you can do there.

So what is the current status? We have plone.rest and plone.restapi packages.

Ramon: Plone has lots of layers. The rest api is a way to reduce this. Something like PAS (PluggableAuthService) is in essence simple: get the user, get his global and local roles, check which permissions those roles have, and you are done. So why is it so complex? Especially when you use LDAP, making it slow. We are working on getting and storing this info outside of Plone. Then you can use elasticsearch to get roles and permissions. Rely on LDAP and for example docker to get this info. It is an idea. But for some kinds of installations, this may be a good idea, so if you are looking at this, talk to us.

Nathan: page rendering. User accesses a url, python goes to work, and gives an html response. Zope has a Publisher, which in the end gets you this html, using page templates, Chameleon, portlets, etc, some Diazo and Mosaic included, javascript doing some more transformation at the end. Most frameworks like Angular have their own template engines. With Diazo you could actually do the transformation in the browser if you want, there is code for that. We might no longer care about how forms are rendered, letting this be done by a front end framework. For Mosaic, things stay the same, except the rendering that is moved to javascript. So you move a lot of processing over to the browser. Plone server runs REST api, static css and javascript served by apache or nginx, javascript doing the real rendering. Problems: page loads would not include any html, so that is bad for SEO. But you could use NodeJS for this. And search engines are playing nicer with javascript.

Further topics. Forms done by some javascript framework. Search: not ZCatalog but solr or elasticsearch. Diazo: will we still need that? Dexterity will most likely stay: we will still need content types. Hackability, keep that in mind.

This is work in progress. We are discussing ideas. We are not saying that Plone 6 will look like this. These packages will work with your existing Plone sites and not break anything, so you can test this with whatever javascript framework you like.

Javascript frameworks are a moving target: yes, that is hard. For some projects you may want to use React, for others Angular 1.3 or 2. We will provide the restful api as common ground. People can build on top of that. We are not sure this is where the web is going, but we are pretty sure this is a good way that will work.

We have a good front end that is great for a lot of use cases. We are not breaking that. But we are adding possibilities.

Martin: Web sites are generally becoming more complex, with more features, plugin possibilities. If others can talk to you this helps. What matters is accessibility and integrateability, making it nicer for others. If we design the api really good, it can make Plone really successful.

Why another migration tool for Plone? plone.app.contenttypes already has migration for Archetypes to Dexterity. This atct_migrator is in most cases the right tool. Watch and listen to Philip Bauer's talk (tomorrow) about this: How to upgrade sites to Plone 5.

We have Plone 3.3.5, more than 20,000 items. Custom content types, with archetypes.schemaextender. Merging of content from different sites, cluster of five sites sharing a mounted zeo. This live implementation was actually uninstallable anywhere else, so we could not get a good test migration using the default ways.

interaktiv.migrator gets source as json and pushes it to the target.

Pro:

• import content directly to a newer Plone version.
• migrate our own content types without mapping fields that were already matching
• archetypes.schemaextender data worked fine with this
• This could be done from a live system.
• You get a new and clean database.

Contra:

• Only content is migrated, so settings and users are lost. So you should do something else to get this part of your setup back.
• References have to be migrated at a second run.

I wrote a transmogrifier based workflow to export and import the data.

In the old site there is a configuration form for the migrator, with a target url and for security reasons an api key that must match between source and target. On the target site, you set mappings for types, fields, views.

Live demo, migrating some content, with portlets and local roles on the Sharing tab.

After migration some things still need to be done:

• Go to portal_workflow and update the security settings (button).
• Go to portal_catalog and clear and rebuild the catalog (button).

You can write code to export only some portal_types, or only published items, or only content from one folder.

• interaktiv.migrator is in beta.
• Target audience: developers.
• Does not work yet for collections.
• Only migrates from Archetypes to Dexterity.
• Content gets a different uid currently.
• Needs better documentation, testing, refactoring.

Code:

• https://github.com/jmevissen/interaktiv.migrator
• https://github.com/jmevissen/interaktiv.migrator_p3

Questions:

• Are dates migrated correctly, so creation and modification date? No, but for example we added this for the Creators field and this took only half an hour to implement.
• Which Plone versions? Tested on migrating from Plone 3 or 4 to 5.
• plone.app.contenttypes migrates schemaextender, dates, uids, etcetera. Did you report any issues there? No.