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.

We are not in the docker-world yet, at least not for deploying sites. Last year we had to publish several Volto sites in production and needed some automated way to handle those deployments because Volto's build process takes so time. We have manged to build a CI-CD pipeline using Gitlab-CI and several other tools to release, build and publish volto addons and sites in an automated way. Earlier this year we published a blog-post explaining this process and this talk will be the extended version of the blog-post.

Why are we not using Docker? We are migrating Plone 4.3 to 5.2. We use DigitalOcean standard droplets. We are used to Buildout. These are not Docker deployments. We are starting some Volto developments, and did not want to change our standard deployment yet.

Running yarn build on the server took half an hour, and then broke, so that was not a solution. We had to upgrade the server to run the build.

The solution was to automate the process. Automate add-on package creation, frontend package compilation.

Problem: we are using private repositories, so could not use the public npmjs registry for packages. Do something private? This is not that easy.

Verdaccio to the rescue. This is a private npm repository, which proxies to the real npmjs for public packages. We configured this to work only in authenticated mode. We needed to configure npm and yarn to use authentication.

We setup a pipeline in GitLab. When a pull request of a Volto add-on is merged, a package is created and published. When a pull request for the front end is merged, the frontend is built and copied to the server with scp and then a supervisor restart. When finished an e-mail is sent through MailJet api.

GitLab CI configuration is hard. You have stages, steps, artefacts. Artefacts are shared beween jobs, but not between pipelines. Use artefacts to cache already built things. Use variables for everything. We share configuration in a GitHub repos and sync it to other repos with a Python script.

Links to the configuration can be seen at labur.eus/deploy-volto.

Thank you Imio and Affinitic for organising this conference. Special thanks to Martin Peeters and Joël Lambillotte who lead these companies.

Plone is multiple things:

• a product and api
• a community
• a foundation (organisation)

For the first part, our four release managers will talk about it in the keynote on Friday. As Plone Foundation president I will talk about the first and second parts.

The Plone community is global, online, open source, multilingual. We started as an online community: Alan Runyan and Alex Limi started Plone by talking on IRC, which is how old people like me used to communicate.

A good part of Plone is that we are truly open source and free. There is no big company behind it that can remove parts of the software or suddenly start asking money for it.

Plone started from the Zope community. Other communities came from Plone, like Guillotina, with people still here at the conference today.

In my home country of Brazil, the Plone community was started before the Python community. The first seven Python conferences in Brazil were organised by the Plone community.

I was welcomed into the global Plone community by people like Jens and Hanno, which was impressive to me. But mostly I thought: hey, these are nice, normal people, that you can talk to.

The community will embrace you. The community will help you overcome your fears, like I had of running for the Plone board.

I had two role models: Dorneless Treméa and Jean Ferri. They left us way too early in life. What I learned:

• Lead by example. No one wants to organise a conference? Let's do it.
• Be generous with your time.
• Help people.

How can you help when you are not a developer, but a user?

• Ask questions on community.plone.org.
• Help with documentation. Thank you Katja Süss and Steve Piercy for doing a lot of work here. I am nervous when I add documentation because English is not my native language. Don't worry, Steve will fix it for you.
• Translate Plone in your language.
• Make designs for Plone. Maybe a nice photo to go with a news item.
• Share your experience.
• Work with issues, do code review. The past week or so, on every issue or pull request in Plone, there was a comment from either David Glick, Alessandro Pisa or Wesley Barroso.
• Spread the word, like Rikupekka Oksanen.
• We had Google Summer of Code students this year: Bhutan R J, Avi Mishra, Md Sahil, Robot Singh, helped by Eric Brehault and others.

Plone Foundation

The Plone Foundation is an organisation that supports the community. We promote and protect Plone. We are the legal shield for threats, or preventing companies taking over Plone, or saying they are the largest. We support community meetings and sprints. We had the World Plone Day, with lots of video content.

If you want to organise a sprint or a meeting in your region, talk to us. We can help with money or with organisation.

We had ten new Foundation members the last twelve months. I know most people here who are no members have imposter syndrome: I am not good enough. That is not true. That you are here is proof enough. Nominate yourself.

You can sponsor Plone.

Please consider joining the Plone board.

We are a diverse community. If your English is bad, you are still welcome in our community. We don't have enough women here, or people from the south of the planet.

We need to generate more content. Do a podcast, a video, a success story. In your language.

We need more events. They don't have to be big. Just a local meetup. We need to present the software and the community in other places, like Pycon or React conferences. We are going to have a new version of the Plone Symposium in Brazil, on November 18, 2022.

World Plone day will be April 26, 2023. It is great if you organise a local meeting that day.

I see that a lot of people are here at a Plone conference for the first time. There are young people here. People leave the community, others join, some come back after a while. The Plone community stays with you even after you leave.

Distilled from the latest work done in Volto, we're showcasing some patterns, features, or enhancements that have landed in Volto from the last year to the present. We will also have a glimpse of what is ahead in the future of Volto with the new features roadmap.

In the past year we had four major releases, 40 minor releases, 36 alpha releases, 25 patch releases, for a total of 105 releases. Plus some new tooling and tool releases, like plone i18n and plone generator.

New Volto config, dubbed as Volto's Configuration Registry, introduced to fix circular import dependency problems. Hot Module Reloader was fixed. Read the upgrade guide.

New i18n (internationalisation) infrastructure. This is now a separate package. Same is used for generation of i18n in add-ons.Read the upgrade guide.

Forms as schema. Forms should be constructed from schemas instead of by hand. InlineForm allows us to create forms for blocks from a schema. Blocks can have variations, or we can extend it. Read the edit component documentation.

New widgets:

• Object List Widget. Similar to the original DataGridField. Used in core by the Search Block facets.
• Object Browser Widget is now a separate widget, instead of part of a block, and now allows the addition of external content.
• Querystring Widget. Behaves like its counterpart from plone.app.querystring. Allows to create search criteria, used by the search block.
• URL Widget. Used on text inputs, it knows to validate their value as a url, both internal and external.
• Vocabulary Terms Widget for a JSONField, acts as a source for a SimpleVocabulary or Choice field. Play with it in the storybook.

New core blocks:

• Search block
• Teaser block (ongoing work).

Pluggable framework, similar to React's Portal component. See the talk by Tiberiu and see the Pluggables development recipe.

Storybook provides a sandbox to build and test visual components in isolation. Currently it is only setup to be used by Volto core. We need help with work to have storybook setup with adding. See the Storybook talk held by Victor, and see the storybook itself.

Critical CSS: inline the critical CSS for improved performance. Run critical-cli to output critical.css. This is then inlined in the headers, while regular CSS is moved to the bottom of the body. See the deployment documentation.

Lazy Loading utilities. Introduced injectLazyLibs HOC wrapper to inject lazy-loaded libraries as properties to your components. These components are only loaded once all your main libs are loaded.

Express.js middleware. Volto uses this for SSR and static resources serving. You can now write custom middleware and add it to settings.expressMiddleware.

API expanders allow the expansion of different API endpoints from Volto with calls from your custom endpoints. Avoid adding too many expanders if they are not critical to the initial page.

External routes: useful when another application is published under the same top domain as Volto. If Volto would fetch the content for that path, it will break. You can disable this path in config.settings.externalRoutes. You can also use regular expressions.

Seamless mode, introduced in Volto 13, enhanced in Volto 14, which has already seen a lot of alpha releases. Originally, we tried to unify both frontend and backend servers under the same path, but this was tricky, causing various problems. We settled on a new ++api++ traversal for getting information from the backend. Also, to come closer to zero config, you can now pass environment variables at runtime instead of build time. This means you can generate one build, and use this in all environments (testing, production). Read the deployment documentation.

Context navigation component. This is a navigation portlet component, similar to Classic Plone. The view is there, but you need to enable it. See the development recipe.

There is some work in progress:

• Slots are Volto's answer to portlets, see the Volto Slots talk by Tiberiu Ichim for more details.
• Image proxy: image scale generation done by a middleware instead of plone.scale.
• Authentication from backend.
• Replace Draft.js editor with Volto Slate. What is missing is a migration tool from one to the other. But work has started on a block conversion tool.
• Async blocks that work with SSR.
• Defaults in blocks form.

Future work:

• Defaults in all widgets
• Enable blocks enhancers in all blocks
• Storybook in add-ons
• Use newest react-intl package
• Refactor the folder contents component
• Form editing text enhancements, making it easier to modify text inputs.
• A "group block" included with Volto
• Quanta toolbar

I did nothing, I just brag about what others have done. So thank you Volto early adopter community!

This presentation is an introduction to the new Volto developer-targeted feature, the Pluggables framework. It is more an argument for extensibility in CMS UI and in Volto.

Basically, with Pluggable a central component provides a pluggable slot that other components can fill, like this:

<div className="toolbar">
  <Pluggable name="toolbar-main" />
</div>
// ...
<Plug id="quicklinks" pluggable="toobar-main">
  <Button />
</Plug>

This is a Volto port of https://github.com/robik/react-view-slot.

The big picture:

• I work with Eaudeweb Romania
• Our client EEA is an early adopter of Volto
• The strategy is: move everything to Volto
• But the EEA sites are less brochure, the CMS side is really strong.
• We build powerful UIs for power users.
• The EEA already has 91 Volto repositories on GitHub. How can we scale that? Can we write an add-on to make it easier to write an add-on?

In React, data flow is top to bottom. A parent component passes properties to children and children communicate with the parent by emitting events. This makes sense and works well. For "out of tree" data you need Redux. There is no protocol for add-hoc communication between components.

UI state is fluid. Extensibility means reusability and scalability. This is hard. You need to design upfront. Plone backend uses the Zope Component Architecture, which means pluggability is baked in, it is very natural. You can view Pluggables as viewlets-on-demand, but they are really not. But yes, you can think about a Pluggable as a viewletmanager and a Plug as a viewlet.

You can overwrite a Plug with a Plug, by registering it with the same id. So if the original Plug gives you color blue, you can overwrite it with color red.
You can do custom rendering of Plugs within your Pluggable, by iterating over all Plugs and for example wrapping each in a div with a class name.

Showcase: volto-workflow-progress (main toolbar plugin) and volto-editing-progress ("sidebar" for plugin).

Limitations:

• No Server Side Rendering
• Watch out for dependency lists.
• Limited adoption for now.

Implementation in pseudocode:

First the context:

<PluggablesProvider>
  <Pluggable name="top" />
  <Plug name="delete" />
</PluggablesProvider>

Then the dumb version of the Plug:

const Plug = ({id, children}) => {
  const { register } = useContext(PluggablesProvider.Context);

  React.useEffect(() => {
    register(id, () => children);
  });

  return null;
}

Takes a bit of study, but in the end it is not so hard.
The Pluggable becomes a bit simpler:

const Pluggable = (name) => {
  const { getPlugs } => useContext(PluggablesProvider.Context);
  return getPlugs(name).map(f => f());
}