Versions
TYPO3 14: What Is New and What the Update Means
With TYPO3 14 the next LTS version is available. Rather than a feature list, here is the view that counts in a project: what changes for editors and developers, and what it means for an existing installation.
Content Blocks arrive in the core
The most noticeable change concerns something every project needs: custom content elements. Until now they were assembled from several parts in different places, or built with an add-on extension. With Content Blocks, the approach of keeping everything belonging to an element in one place has arrived in the core.
For editors nothing changes. A content element looks the same in the backend regardless of how it was defined. The difference lies in maintainability, and that indirectly affects how quickly change requests get carried out.
Important for existing projects: Mask, the widespread alternative until now, is not being developed for 14. If you use it you have peace up to and including 13, and should fold the conversion into the version jump.
Backend and templating
The backend has been reworked. Changes like that sound cosmetic and are the most noticeable part of an update for editorial teams: anyone working in it daily notices every button that has moved.
So with updates we always schedule a short session to walk the editorial team through the changes. It costs an hour and saves weeks of questions.
On the development side, Fluid 5 brings a new version of the template engine. For well-built templates that is uncritical; where a template holds logic that should never have been there, it gets more involved. What belongs in a template and what does not is set out in the glossary under Fluid.
What carries over from version 13
The additions from 13 have not disappeared; they are the foundation: Site Sets for bundling configuration, and the improved support for modern image formats.
Anyone coming from 12 or earlier gets both at once in the jump to 14, and should take the opportunity to check whether the configuration can be organised into sets.
When the move is worth it
Three cases, three answers.
You run 13: no time pressure. The move can be planned, and there is a lot to be said for combining it with a rebuild that is due anyway.
You run 12: active maintenance has ended. Here it pays to aim straight at 14 rather than taking the intermediate step, since the testing only happens once either way.
You run 11 or older: the question is then not which target version but whether update or relaunch is the more honest route. At that distance the arithmetic frequently tips over.
What to check first
The same list precedes every estimate: current version, installed extensions with their state of maintenance, the extent of the custom code, whether the installation is managed with Composer, and whether the server environment meets the requirements.
Experience says that going through that list makes a portion of the extensions fall away with no replacement, installed for an occasion and forgotten afterwards. That is the cheapest form of reducing effort, because it costs nothing beyond the review.