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.

I am Tiberiu Ichim from Rumania. I have 12+ years experience with Plone and 2+ years with Kotti. I started small projects with Kotti. I am going to show some of my experience with it. How can you use it, benefit from it? When should you favor it over Plone or some other solution?

Kotti was started in 2011 at a Plone conference. The developers have Plone as common history, so Kotti will show this heritage inside of it. You will see familiar concepts, even though the platform is completely different. It is already stable for many years, you can just use it.

License: BSD. About 9,000 downloads per month, so still small, but an active, healthy and welcoming community.

Kotti: fast, light, flexible, well tested. That is its philosophy.

Create an add-on for Kotti:

$ bin/pip install Kotti
$ bin/pcreate -s kotti kotti_myaddon
...
$ cd kotti_myaddon
$ ../bin/pserve development.ini

This scaffold of a new add-on is tested in the core Kotti tests, so you know it will create a correct add-on.

The Node base class gives you traversal, as you are used to in Plone. It uses the adjacency list pattern, with parent and children. From a single root Node you can traverse a node tree. Access children with the dictionary protocol.

Class hierarchy is broken up among dependent tables. Each content class has its own SQL table. Transactions work, so changes are rolled back when a transaction is aborted on an error.

View definitions are done with a decorator.

You can use Zope page templates, specifically Chameleon. In a template you can use api.render_template('kotti:templates/views/tags.pt') to render a template.

deform and colander are used for schema definitions and form validation. Standard add and edit forms are just a few lines to define.

Configuration is done with .ini files. Kotti is a WSGI app.

Choices made by Kotti:

• Pyramid as framework.
• SQLAlchemy as most advanced object relational mapper for Python.
• Bootstrap css.
• Colander and deform (version 2) for forms.
• repoze.workflow, very similar to DCWorkflow
• filedepot for blob storage. You can store them on custom backends: file system, Amazon S3, GridFS, roll your own. It integrates nicely with SQLAlchemy and is transaction aware.
• Bleach, Babel, Alembic, py.test, jquery, etc.

95 percent test coverage of python code, using py.test.

You can use a lot of other pyramid extensions.

It is an alternative for Plone, Django, SubstanceD:

• Plone has a lot more features, many add-ons, TTW development. Heavy on resources, lot of features that you may not need for your site, hard to understand and get into development for newcomers. Many competing technologies: Dexterity / Archetypes, Zope2 / ZCA / Grok, Diazo / browser views / portal_view_customizations / portal_skins, z3c.form / CMFFormController / zope.formlib / plone.autoform / Archetypes. Plone is of course a source of inspiration for Kotti. Kotti is similar to core CMF in scope. With Kotti you have only one global site, instead of possibly multiple sites in one application, so Kotti has no local settings stored in the database, no need for GenericSetup, no need for most portal utilities. Also no need for the portal_catalog, as you can search with SQLAlchemy.
• Django has many add-ons, large community. Also opinionated. Not quite a CMS. Weird for a Zope or Plone developer, especially looking at templates and the ORM.
• SubstanceD: very good pedigree. Made by Pyramid developers. Similar features on the surfaces. Uses the ZODB instead of SQLAlchemy.

Kotti avoids burnout:

• smaller development stack
• starts faster
• faster test runs
• no lengthy builds

If you already know Kotti, it is easier to dive into Plone, compared to starting with Plone first.

If you are a Plone developer: yes, you can use the ZCA and write zcml. There is no undo or versioning yet. Smaller number of extensions, less builtin features. Not tweakable by editors, no TTW development, composable layouts, portlet management. But you could create it.

In the future, Kotti wants to say "lean and mean in all the right ways." Keep the base package light, suitable for everyone. Python 3 support is almost done. Probably undo and versioning using sqlalchemy-continuum. A REST api partially implementing JSONAPI.

See http://kotti.pylonsproject.org and https://github.com/Kotti/kotti and #kotti and the freenode irc channel.