Haiku is a software as a service CMS utilising Plone as the engine. Haiku is aimed at research and higher education institutes. With over 140 websites at Oxford University using Haiku, we will talk about some of its key features and the long anticipated upgrade from Plone 4 to Plone 6, covering the good, the bad, and the epic. We will cover the small fish in the logistical pond, as well as the whales under the water.

The University of Oxford lets you do what you want to do. No one tells you. You can hire your nephew to build a website. Not always good for stability.

After a few pilot projects we are at 140 websites running Haiku. Non technical site owners can theme their site.

Now we want to move this beast to Plone 6. With a small team we had fear of the unknown: what dangers did we not know about? So we asked Philip Bauer and Lukas Zdych as external consultants and programmers.

Requirements for the migration: Keep all features and UX. Usually not a good idea, you would use a relaunch, do new things or theming. But here it looked good already, so it was okay to do it this way.

• Content: everything was already Dexterity, so that is modern.
• A ton on code, 2000 Python files, 500 page templates, good quality. The test coverage was not good though, so it was hard to say if a change was good.
• collective.cover was used a lot. I thought of going to Mosaic, but there was already work getting pretty close to Plone 5.2, so we went for it.

Since it was Dexterity already, we chose in-place migration. Now I am not so sure, exportimport would have been good too. We targeted Plone 6 alpha as soon as possible.

Initial task: update application code for Python 3. Lots is automated, but there is still manual work. After a while we got everything working on Python 3, and we could export and import the content, so we decided to change plans: use exportimport.

With exportimport you do not write upgrade steps when you need something special, but you write migration hooks. The project lead to some code and examples added in exportimport. For details on migration code, see the migration best practices training.

Lessons learned:

• collective.cover is actually great.
• collective.exportimport can solve even the toughest migrations, and is faster by magnitudes. You also get earlier results: you can export and import just one content type, or one part of the site. It makes migrations affordable. About 15 procent of the time Philip billed for this project was for the real migration of data, the rest for improvements in the code.

We have context behaviours to enable features on content items.

Comment from Kim: you can replace Oxford with Leuven and give basically the same presentation.

Module Federation is a JavaScript technology based on webpack that handles dependency resolution and the loading/importing of modules, even if they come from external, remote bundles.

A bundle is a set of JavaScript modules which provides some functionality and can be run on its own. A typical web project often includes multiple bundles to provide all the necessary JavaScript functionality. In Plone, Module Federation helps us to prevent loading the same dependencies multiple times.

Think of a Plone add-on with a JavaScript bundle which uses Leaflet, Select2 and jQuery. Those dependencies are also used by the Plone core JavaScript bundle "Mockup" and other add-ons. These dependencies can - and should - be shared among the different bundles.

This talk explains the concepts behind Module Federation and how we use it in Plone to optimize loading speed.

Module Federation is a feature that landen in webpack 5. It helps for loading javascript only once, and in smaller chunks, as needed. Recently it was extracted as separate library.

Think of two bundles that both load a version of Patternslib. With Module Federation, we load the highest compatible version, which is specified in package.json.

Module Federation was invented by Zack Jackson in 2018. He wanted multiple small applications to work together without loading code multiple times.

For Plone 6, the whole Mockup stack was rewritten, this was ongoing. But how would we do add-ons? If they just needed jQuery, it should be alright, but how about add-ons that need more. I then found out about Module Federation. Manfred Steyer helped me, he lives close to me and he already spoke about Angular at the Plone conference in Barcelona. At the BuschenschankSprint we managed to merge this approach and release Mockup 8. Zack Jackson added an issue in Patternslib with some more possible improvements. It is nice that these people at the core of Module Federation are involved in Patternslib.

To use this in a new add-on, use bobtemplates.plone 6.0b14/15 or higher, or use a template.

Question: Could this help Volto too?
Answer: Yes, that should help. For Classic Plone, the main bundle went from 1.5 MB minified to 300 kB normal. Plus the chunks then, but those are only loaded when needed.

This demo covers how the automated release works on Plone 6 projects ( frontend and backend ) for the github.com/eea Volto add-ons and Python eggs.

On each release on frontend and backend projects, a text is extracted that contains all the relevant information using the changelog of the updated Volto add-ons, Python eggs and the Plone/Volto releases. The unified changelog is then saved on the release on GitHub, and can later be viewed in the control panel from volto-eea-kitkat addon.

The GitHub repositories eea/eea-website-frontend and eea/eea-website-backend will be used in the demo. The automation jobs are running in Jenkins.

How is this done? On the backend you have a Plone site with eea.kitkat and on the front end volto-eea-kitkat. This saves old versions and update date in Plone registry. Plus Volto code.

We have the eea/plone-backend Docker image, based on plone/plone-backend. And then an image per project.

For Python egg releases, we use the GitFlow procedure, using eea.docker.gitflow. This means any commit to master is considered to be fine for a release. We extract the change log text from the commits, and is reviewed before merge.

On the front end we use auto-changelog.

When we release a new version of a Volto add-on, a script goes to all our other add-ons, and edits the package.json to update the version.

Theming by use case for Classic UI. Creating a theme for Plone from scratch was never that easy! The talk shows how to create simple but beautiful themes for Plone's Classic UI with different use cases in mind.

 I am sad, I wanted to stand here with a few shiny new themes for the conference. But I got a cold and it did not work out. Some will come though.

The good news: theming is fun again. The markup of Plone 6 Classic UI is Bootstrap 5. You can create beautiful things in minutes by simply using specific classes, copying some examples from Bootstrap. I will show screen shots, and especially check out the ones with forms: they have no styles, they just like fine already. If you need javascript, the story is much simpler. If you only need jQuery, it is there already.

You can check the training documentation to see how theming works, in various ways depending on your use case. Spoiler: it is easy.

We use Bootstrap variables. There is basic behaviour like rounded corners. You may just need five lines to end up with a very different look and feel. You can base your theme on the default Plone theme called Barceloneta, or you can simply start from scratch. Copy an example and you are done. In most cases you can copy the code also in the TinyMCE editor and it will work. You might need to allow a few more attributes in the html filter, which is there for security.

You can use all Bootstrap icons.

Example theme: plonetheme.tokyo. Example site and code. This is for Plone 5.2. I had no time to update it to Plone 6 yet, but it is mostly deleting code. Let me know what changes you would like to see.

Another example, plonetheme.munich. Two columns, portlets aside from the content. I do not recommend to use this in a project, or extend this. But look at it as an example of how you can have a minimalistic approach of what is necessary.

I do not like the default toolbar much. I have created collective.sidebar instead. Bring toolbar and navigation together.

Main take away: create a minimal theme, adjust some templates, it is fine to change the main template, cleanup, be lazy and use Bootstrap.

Full title of the talk is Plone for managers: how to achieve good ROI for your organisation and really use and value the strengths of Plone.

During my 15+ experience as a Plone consultant, developer, trainer and project manager, the online software ecosystem has exploded into a complex but essential part of most organisations and their core processes. I have consulted quite a few organisations in the last few years where Plone has fallen out of grace of management and the responsible manager is looking for a replacement CMS.

Almost always (and there's not a milder way to put this) the reason is one of mis-management because of wrong expectations and assumptions about what is required nowadays and which organisational resources are required to operate a large CMS backed website besides the software itself. By the time I get involved it's almost always too late: it's easier to save your face as a manager by switching to another CMS and blame the software than admit you are responsible by not understanding and underfunding the context in which the software really can and will shine.

Actually: the responsible manager is often not to blame as well because it's the developers and integrators like me and the Plone community itself that does a poor job of giving context and guidance on a management level.

This talk is not only for said managers, but even more for integrators, developers and the Plone community at large providing Plone to clients.

Disclaimer: I will exaggerate and 'inflate' situations and processes to make a point. It is not my intention to annoy, be rude, or hurt people.

This is not just about Plone. The same can happen when you support a Wordpress site, Drupal, Django.

In most cases evolution is better than revolution. If you have to replace the complete system, this is usually bad. It is not just the software, it is also a whole organisation that needs to adapt. Editors will have to be retrained. Internal knowledge is thrown out, and this comes at a cost.

Problem: ICT and the web are revolution.

As a manager: do not bet your organisation on a hype. What is popular today, may not be popular or supported tomorrow.

Also, your website is not a project with a beginning and end date. It is ongoing. For most companies it is core business, ongoing work, never finished.

I have too many topics for this presentation, hard to see a thread. There are separate topics, but all related. See what you can pick out for yourself.

My model: look at the TCO, total cost of ownership. What does it take to run an online presence or do online marketing for a growing organisation 'well' for many many years. Where are the costs?

• Software stack.
• You need hardware, hosting.
• You need to actually create content. A developer can create lots of code and features, but if it is not used and you only have twenty pages, then it is a waste of money.
• Support for editors and users
• Third party tools and services, like marketing automation.
• You need management attention and involvement.

If the TCO goes more than 30-50 percent to the software stack and hosting, something is wrong. You do not spend enough on the other parts.

If the TCO goes less than 30-50 percent to the software stack and hosting, something is wrong as well. The software will get outdated.

You can spread development and hosting. Do everything in house, hire external developers for parts, or for the whole, or use SAAS. Tip: make a split between who does the hosting and who does the development. If one company goes down, the other can still take over and save the day.

My personal belief: a cooperative model between an in-house work force and external assistance is the most flexible model with the least risk.

Let's talk about attention spans. Over generalised:

• PR / communications team has an attention span of 1 to 3 weeks.
• Marketing is into campaigns, 3 weeks to 3 months
• IT-department: 3 months to 3 years.

Can you see the problem when IT people speak directly to PR people? IT cares about stability, security, backups. PR: fix a PR problem, publish a news item and forget.

Should your marketing manager be responsible for the website and TCO domains? Think about a different example: is the sales manager responsible for the ERP system?

End users care about new features. IT wants to sink the system to the bottom of the ocean so it is stable. A bit unusable though. You know I am exaggerating, right?

Is organisational knowledge kept? Or is an interim manager responsible for the website, and replaces every year, with no knowledge transfer happening? The developers are pushed into a help desk role then, training the new manager every year. This is costly. Have a help desk in house. Let editors support each other.

Other these interim managers or marketing managers use Plone one or two years, and then move on to a different company that uses Drupal or Wordpress. So it is not in their interest to gain and retain much Plone knowledge. Mid or higher level managers need to keep the longer term in mind: ensure that knowledge stays in the organisation when people leave or move to a different part of the organisation.

With Plone we like to focus on content editing, but these days more is involved: marketing automation, analytics, privacy, GDPR, etc. And we want to grow, grow, grow.

A lot of companies prefer hiring externals over internal employees: you cannot easily get rid of employees, so it is a risk. But then you have no knowledge at all in your company.

There is also venture capital and the software lottery. Financial companies invest lots of money in a few startups, in the hope that one of them becomes a unicorn, becomes very successful. The others die, and if you have moved your site to such a failed startup, you might have one year to move your website somewhere else. And if you bet on the successful one, their prices may go up because they have you locked in.

Because Plone is completely free, there is not one company that decides the future. See also Erico's talk. We are small companies and need to cooperate. Apply the Pareto principle: use 20 percent of your time to give back to the community.

Corporate social responsibility. Do you throw away websites after three months? Do you invest in your local economy or do you help a big American IT company?

Fine a balance in the total cost of ownership of your website. Regularly scan your current setup. Reconfigure, extend, expand. Talk to your customer about it.

Here is a link to the slides on dropbox, including many, many skipped ones.