The TYPO3 demo site is available at demo.typo3.org. The goal of the project is to provide an instance where anyone is able to log in and get an overview of how TYPO3 works. Visitors are able to log into the backend and play with content editing. The installation is maintained in a repostitory at git.typo3.org by the TYPO3 Demo Project team.
QA Best Practices Initiative
The QA Best Practices initiative is a group working to model best practices in TYPO3 implementation and extension development. Previously, the initiative worked on providing best practices for extension development. Now the team is focussing on best practices for projects. Have a look at their Tea extension for unit testing and best practices:
Best Practices From demo.typo3.org
The following are some of the best practices implemented within the demo installation. This is by no means an exhaustive list. Feel free to have a look yourself.
Custom Content Elements
Most TYPO3 installations use custom content elements to suit customer needs. The demo installation has several custom content elements like Ingredients and Main Teaser. They are available via the TYPO3 native content element wizard.
Using the Content Defender extension, we make sure only those elements suitable for a given page type or content area (colPos) are available for editors to choose from. And each content element also has its own preview within the TYPO3 Page module. There are plans to migrate to b13’s extension, backendpreviews, in the future.
All in all, the demo installation demonstrates how to properly design content within TYPO3 and make it available to editors in a clean consistent way.
100% VCS TypoScript + TSconfig
Many projects have already moved their TypoScript and TSConfig out of the database into a version control system (VCS) like Git. This is also true for the example project. The setup uses the bolt extension to track changes to configuration, and for deployment of configuration alongside other changes within the installation.
To render images in different sizes and resolutions we use the third-party extension picture. This enables us to use a replacement ViewHelper to render images in multiple resolutions. It also adds modern image formats to the mix (for example, rendering a <picture> tag).
Split Up CSS
An important part of a website is keeping asset sizes low to ensure a fast page load. Using TYPO3’s out-of-the-box capabilities, the demo project showcases how to include certain assets only when needed. An example would be loading the CSS directives used for our contact form only on pages that have a contact form (see the Form template).
Inline SVG Assets
We use the third-party extension Asset Collector to dynamically include SVG files in the pages where needed.
Connect Custom Doktypes And Backend Layouts
This is a burden for many projects. Custom doktypes have been a core feature for a long time and often need a specific backend layout. The demo installation demonstrates that the backend layout can be derived from the actual doktype via a hook. This reduces maintenance overhead, removes possible bugs from the installation and reduces the list of fields an editor sees in the page properties. There are plans to migrate this setup to b13’s extension, doktypemapper, which eases integration even further.
Gather Insights and Improve Your Own Project
Feel free to check out the sources of the demo project, as well as the QA extension. Everyone is welcome to provide feedback via our TYPO3 Slack channel #cig-typo3-demo and #qa-best-practices. Also feel free to create issues and Pull Requests / Merge Requests on the projects.