Why We Ditched WordPress for Typo3 + NextJS
Our new website has been online since last week and we couldn't be prouder: After a gross project duration of 2 months, we took the plunge from WordPress to Typo3 with NextJS. You can read about what made us do it and why in this article.
No WordPress bashing
First things first: we don't want to talk down the most widely used content management system on the internet, with almost 44% (as of Q3 2024). On the contrary: WordPress has helped us to get a website up and running quickly. By quickly, we mean a week - and in that time, with the help of Elementor and the like, we got a lot done: company presentation, magazine and the launch of a lexicon for software terms.
But the site has grown from month to month.
And that is precisely one of the reasons why we have now turned our backs on WordPress.
Native multilingual support
Initially, our website offered no multilingual content. The decision to create an English version of the website was not made until a few months later.
The problem: multilingualism is not natively supported by WordPress. The solution would be either a third-party plugin or the use of WordPress' native multisite function. However, the latter is actually intended for completely different blogs/websites and not for multilingual versions of a website that is actually identical.
We decided to misuse the multisite function because we wanted to keep the use of third-party solutions to a minimum.
The fact that we now had two different WordPress administration interfaces turned from an advantage into a disadvantage over time: the maintenance effort became immense.
This is where Typo3 came into play: Typo3 not only supports multilingualism out of the box, but is also very user-friendly. Pages and content elements can be easily edited side by side without having to jump to other areas of the administration interface.
Customized extensions
Website builders such as Elementor offer a wide range of customization options. We also created our content elements with Elementor. This saved us the step from the design tool to programming the content elements and allowed us to create them visually directly in the editor instead.
However, Elementor itself is an extension of WordPress, i.e. a plugin. The fact that it comes with many different widgets is all well and good, but when it comes to custom extensions, what then?
“Custom” extensions are, for example, the lexicon or our portfolio, both of which we have gradually developed. The lexicon offers a search function, while we wanted to enhance the portfolio with scroll effects.
Elementor could certainly have been enhanced with another plugin that comes with additional widgets. However, as we wanted to use as few third-party plugins as possible, we decided to write them ourselves.
So we programmed our own widgets, moving away from the convenience of WordPress - what emerged was a hybrid website and no longer a “click-together” website.
Funnily enough, we even had an extra micro-frontend that delivered individual React modules. These included the quiz component for magazine and encyclopedia articles. By using NextJS based on React, we were able to transfer the entire micro-frontend into the main project.
With NextJS and Typo3, we have now developed all content elements from scratch according to our needs. And here we have to thank WordPress again: without the quick ability to create content elements with a click, we would never have been able to get a website up and running so quickly. After the site had been up and running for almost a year, we knew exactly which content elements we needed. And we were able to program these precisely according to the design template.
Eternally low maintenance
Have we already mentioned plugins? With WordPress, plugins are a dime a dozen. And in a way, that's what makes the system what it is. WordPress can be not only a blog, but also an online store, social media platform, intranet and much more.
This is a great advantage, but it also has a decisive disadvantage: the maintenance effort.
Plugins are developed and maintained by third-party providers. This works well to a certain extent, but a “pieced-together” website with 20+ plugins can quickly lead to interactions. The plugins do not know each other and do not take each other into account when updating. This can potentially lead to the entire website crashing - maintenance must therefore be carried out “manually” to rule out these interactions. And that takes time. Anyone who has read this far will understand why we have always avoided third-party plugins in the previous points.
Another negative point is the way the WordPress ecosystem works: Plugins are .zip files that need to be unzipped and can only be obtained via the WordPress plugin marketplace - either via direct download or via WordPress itself. If you work and host in a containerized environment like we do, all plugin data must be transferred to version control file by file. Updates can only be carried out laboriously via the local WordPress backend before they are published with a release.
Typo3 solves this with Composer by adding modules to a file via unique names and versions. The Composer ecosystem is a package management system that already checks dependencies and automatically obtains source code without having to add it to version control. This saves a lot of time.
The modules that we use in Typo3 are kept quite straightforward and updates are not often expected apart from security updates. Once you have a clean Typo3 installation, you can run it sustainably and for years without updates - not recommended, but feasible.
Extensive security aspects
Typo3 offers extensive security aspects out-of-the-box and can also be hosted separately if it is operated headless.
As mentioned at the beginning, WordPress leads the global CMS ranking with just under 44%. Accordingly, it is on the radar of bots and hackers.
WordPress is inherently poor in terms of security tools and measures. And we find that weak - for example, administrator usernames are exposed via the API and brute force attacks are not blocked. We therefore had to fall back on the market leader WordFence to close the best-known security gaps. Below is the evaluation of WordFence login attempts by botnets:
But is that specific to WordPress? Not at all. Can this also happen with other systems? Absolutely.
The only thing we have noticed that is particularly negative is that we simply have too little control over what the plugins used and WordPress itself “do”. Everything can potentially be published via the interface and be useful for attackers. That can't happen to us with NextJS and Typo3: We developed NextJS from scratch, so we know what gets published and what doesn't.
Why we would still use WordPress again
Anyone who has followed us closely up to this point will have noticed that WordPress is well suited to building new websites quickly and easily.
If we had to decide what motivated us to switch the most, it would be the multilingualism. And without it, we would probably have stayed with WordPress for the time being.
But the freedom to build content elements from scratch and reuse them again and again should not be underestimated. You can also do this to a certain extent with Elementor, but the functionality is limited and, in our opinion, more complicated than in Typo3.
Ultimately, it is always a question of the situation: it depends on the needs and experience with the systems. These need to be determined and weighed up as to whether it makes sense to develop a better solution. As experts in the digital field, we are fortunately familiar with a wide variety of systems and their advantages. Do you also have difficulties with your existing systems or are you stuck? - Then get in touch with us.
Other articles.
Trends, news and interesting facts about digitalization and tech.
