Skip to content
Published on

Same Content, Different CMS: A Talk from TYPO3 Developer Days 2026

Authors

I gave a talk at TYPO3 Developer Days 2026 (T3DD26) called "Same Content, Different CMS." The slides are live and public: talk.shinyhappypages.de. This post is the writeup for anyone who wants the content without sitting through the talk — or wants to go look at the live demo sites afterward.

The premise

There are more than 880 content management systems in active use today. Each one exists because someone had a specific content problem and built something to solve it. Most of us — myself included, until recently — have looked closely at maybe three of them.

I looked at five: TYPO3, Strapi, Pimcore, Storyblok, and Payload. Same content. Same tasks. Five different systems, back to back, to see what actually differs when you sit down and use them rather than read the marketing page.

The talk opens with a story that sets up why this matters: years ago, a colleague working with Hybris (now SAP Commerce) told me "CMS? That's a trivial problem — even Hybris has one built in." I asked him to show me. It was a text field. Per page. No WYSIWYG, no media library, no multi-language support. For what Hybris was built for, that was probably fine — nobody buys industrial e-commerce software because the hero banner copy was well-crafted. But it stuck with me: he wasn't wrong to call it a CMS. It solved a real problem for a real audience. It just wasn't built for our problems. That's the whole talk in one anecdote — every CMS optimizes for something, and the interesting question is what.

The method

One demo site, Acme Outdoor — a fictional outdoor tourism company — built identically in all five systems: two languages (EN/DE), thirteen content element types, real pages and navigation. Same content everywhere; the only variable is the CMS.

Then the same five editorial tasks, performed live, in each system in turn:

  1. Create a new page and place it in the navigation
  2. Add a hero section — headline, image, CTA button
  3. Upload an image and add alt text
  4. Add a German translation of the page headline
  5. Find a published page, change a headline, republish

No polished, pre-recorded demo — live, in front of the room, in whatever state each system happened to be in that day.

The five systems

SystemCategoryNotes from the talk
TYPO3Enterprise CMSPHP, 25 years in production. Multi-language and access rights built in from the ground up.
StrapiHeadless CMSNode.js, API-first. Editing happens in the admin panel, with a preview pane alongside the form.
PimcoreDXPNot just a CMS — CMS, PIM and DAM in one product. Austrian company, commercial licensing since 2023. The one system in the lineup with true inline editing: you type directly into the rendered page itself, not a separate form.
StoryblokHeadless + visual editorSaaS, headless under the hood. Every system here has some form of preview; what stands out about Storyblok is that the preview is clickable — click an element on the rendered page and its edit form opens, instead of hunting for it in a tree or list.
PayloadCode-first CMSTypeScript, schema defined entirely in code. The admin panel is generated from that schema, not built by hand.

The five editorial tasks themselves happened in each system's admin/editing interface, which isn't public — that part only exists as what the room watched live. What you can look at afterward is each demo site's public frontend, the actual output of those five tasks:

Not a ranking

The talk is deliberately not a ranking. Every one of these systems handled at least one of the five tasks better than TYPO3 did, and TYPO3 handled others better than the rest. Pimcore's inline editing — typing directly into the rendered page instead of a separate form — is a genuinely different feel from the other four. Storyblok's clickable preview doesn't go that far, but getting to the right field by clicking the thing itself, rather than finding it in a tree, still beats hunting through a sidebar. Payload's code-first schema means the content model and the codebase can never drift apart, because they're the same artifact. None of that makes TYPO3 the wrong choice for most of the audience in that room — it makes those specific things worth noticing.

The point, for a room full of TYPO3 developers

The talk closes on three things, in order:

You're going to keep using TYPO3, and that's exactly the point. Nobody in that room switches CMS because of a conference talk. But TYPO3 is open source — the people watching aren't just users, they're potential contributors. An idea borrowed from another system's editing experience doesn't have to stay in that other system.

Every CMS solved at least one problem brilliantly. The question is whether you're learning from it or ignoring it. Even a text field per page taught someone something about what their specific editors actually needed.

Your editor spends hours every day in the system you built — and they don't care about your content model. They don't know what TypoScript is, they've never seen a TCA configuration, and they don't want to. They want to publish a page without calling you. Sit with your editor for five minutes before calling a project done. Don't explain anything, don't help — just watch. That's the whole talk.

Thanks to my employer, team neusta, for the time to put this together and for sending me to the conference to give it.

Links