As a casual minimalist I often try to apply the same pattern to software and development. Here is my journey to a minimal TYPO3 driven website.
Long live TYPO3
TYPO3 came a long way. The content management system (CMS) was first presented in 1998 by Kasper Skårhøj. Until TYPO3 7.6 there was no easy, deployable configuration for TYPO3 extensions, as far as I know. You had to install TYPO3 by downloading an archive, unzipping it, linking files and do some manual configuration.
With TYPO3 9.5 LTS came a big change for the future: TYPO3 System Extension as standalone packages. It basically was the mirrored separation of all TYPO3 system extensions into individual repositories. It worked also for TYPO 8.7 LTS and 7.6 LTS, as long as you used Composer. The road to a modern Composer-based TYPO3 world was ready, but most developers I knew where not as exited as I was.
Learn more about the change at usetypo3.com.
Benefits of package management
After TYPO3 was set up for Composer, you were able to easily install TYPO3 with as little as one command and some initial setup. This was a time saver as well as lowering the barrier to start with TYPO3 development and simplifying the installation.
As I previously stated, it also allows — if compatible — modular installations, by requiring the needed packages. The typo3/minimal package is a great example, what is only needed to run TYPO3.
How we do TYPO3 development
In the wild, we often see TYPO3 websites using dozens of third party extensions, but why? We at visuellverstehen believe that we can provide the best suitable solution by writing most code beyond TYPO3 ourselves. In the past this mentality was often proven right by making changes quick and exactly how the customer wants it. This can safe money, not only in the long run. We are so used to writing custom code for TYPO3, that we have build a lot of knowledge for building most stuff.
TYPO3 updates are often way faster, because we wrote the code. We don’t need to wait for third parties to migrate their extensions and templates. Therefore we suggest removing third party extensions such as DCE with custom build templates. GridElements can be replaced with thoughtful backend layouts and frontend extensions like jQuery Lightbox can be migrated to custom CType elements.
Remove dead weight
If you ever looked closely at every single extension in the extension manager, you probably saw that you cannot disable every extension and that’s a good thing. Imagine how easy backend users could break the site, if they had access. Why would you disable the core, right? But there are system extensions, which you can safely remove using Composer. Here's a list of extensions, we at visuellverstehen rarely use:
- typo3/cms-about
- typo3/cms-adminpanel
- typo3/cms-belog
- typo3/cms-dashboard
- typo3/cms-felogin
- typo3/cms-filemetadata
- typo3/cms-form
- typo3/cms-impexp
- typo3/cms-indexed-search
- typo3/cms-info
- typo3/cms-linkvalidator
- typo3/cms-lowlevel
- typo3/cms-opendocs
- typo3/cms-recycler
- typo3/cms-reports
- typo3/cms-setup
- typo3/cms-sys-note
- typo3/cms-t3editor
- typo3/cms-tstemplate
- typo3/cms-viewpage
- typo3/cms-workspaces
Of course this depends heavily upon the project. If you have frontend users you probably have to use typo3/cms-felogin or if you need to draft content, you have to use typo3/cms-workspaces. These are only extensions we rarely use, but you could remove as well.
Some words about localization
If your site is only available in one language, you can remove localization overhead in your extension. The following database and TCEFORM can be removed, by our experience:
- origUid
- transOrigPointerField
- transOrigDiffSourceField
- translationSource
Remove backend clutter
Removing core and third parties extensions is nice, but what about backend users? In a default TYPO3 installation a lot of stuff is shown to the backend user, because TYPO3 provides a lot of functionality out of the box. This can be great, but can also confuse backend users. Luckily there is a simple solution: TSconfig. You can hide unused fields and modules, you can hide features and configure certain aspects.
Wanna hide the header link field? Easy:
TCEFORM.tt_content.header_link.disabled = 1
You want to hide a backend module to prevent backend users overriding your site configuration? Easy:
options.hideModules.site = configuration
No one uses the bookmark feature? No problem:
options.enableBookmarks = 0
As you can see, there are a lot of possibilities to configure the backend in favor of simplicity. We have a default TSconfig file, which disables and hides stuff we rarely use. It is included in every project we start. In the beginning it might be a lot of work to determine what you use and how to disable clutter.
Conclusion
While this is probably the most minimal it can get for production sites, it might be too minimal for you. If your site has multiple languages or you have to draft content the TYPO3 installation needs certain (core) extensions and this is fine. Choose what you are comfortable with.
Second, we advise using core functionality wherever possible. As TYPO3 versions progress, many functions that were previously contributed by third party extensions are available in core. Best examples are RealURL which was replaced by the core routing and the TYPO3 Console which slowly migrated into the core. An update is a perfect opportunity to downsize your list of extensions and get rid of unused code. This is one of the best ways to make sure the site won’t break during the next update or upgrade.
Feel free to comment your thoughts on reducing as many extensions as possible and as much code as possible.
Top comments (1)
I like that type of minimalizm. Also I do NOT create custom content elements for every little Frontend Component the clients wants. Sometimes the default HTML content element is just good enough to display certain (static) things, especially when you use a framework like Bootstrap, or even the TYPO3 Bootstrap Package.