Fluid-based PageLayout module

Do you know how editors prefer never to delete their content? They like to rewrite and reorganize it, but deleting content elements? That's usually not an option! You might need it again! What else is the "hide" function for?

If you're now wondering why this can be a problem, you've never looked for the one content element on a page in the backend that isn't working and is destroying the frontend, and had to scroll through dozens of other content elements. But wait - that's what the option to not show hidden content elements is for. That's right! But it doesn't help if you're looking for a hidden element - what editor is going to leave it visible if it breaks the page?

We normally use backend layouts to give the page a little more structure in PageView mode. For example, an editor can also maintain the content for the right-hand column in the frontend layout in the backend, or fill different areas that appear one below the other in the frontend in the same way in the backend. But I confess, with 5 different areas and many content elements, I find it difficult to quickly find the start of the next area. So far, we have of course been able to help a little with more or less legible CSS - e.g. with background colors. So why is a fluid-based PageLayout module so much nicer now?

In the easiest case, I can write readable and therefore low-maintenance CSS to design something like this, for example:

All classes used to change the spacing, background colors and font sizes now have descriptive names. The inline SVGs for the icons in front of the sections are made possible by the customizability of the HTML - each section can be fully customized. Similarly, I could throw away the entire HTML table and replace it with a CSS layout combined with a few div elements.

In addition, I have added two things above the page in this example that are helpful for editors: the display of some page properties such as the SEO and navigation title as well as links to the top of each content area. This makes it even easier to navigate the page in the backend.

And if that's not enough, you can also customize the output of the content elements using Fluid templates and add additional information to the header or footer, for example.

Fluid-based frontend login form

The frontend login now exists in a new Extbase and Fluid version. The previous PiBase variant with marker-based templates continues to work, but is deactivated from v10 onwards during a new installation and the new modern Extbase variant is automatically used.

The PiBase variant can be reactivated via the feature toggles in the backend if required (Admin Tools → Settings → Feature Toggles), e.g. during a migration or a TYPO3 update:

An update wizard called Migrate felogin plugins to use extbase CType is available for migrating existing frontend registration form plugins. The wizard can also be used to switch from the Extbase variant back to PiBase.

The marker-based templates have had their day and we welcome the long overdue fluid-based templates. The marker version previously only came with a single template in which all the necessary areas were covered by the corresponding subparts. The Fluid version shows the familiar modern image with templates and partials:

There is also an e-mail template in HTML/fluid and plain text for password recovery, as well as password validators that can be used to configure the password restrictions.

TYPO3 Dashboard

The focus of a website project is often on the frontend and its features and layouts. The backend, on the other hand, tends to receive less attention, is often overloaded and can sometimes be off-putting for editors.

So I'm all the more pleased that the dashboard is a great new feature for backend users in TYPO3.

The dashboard is an area that the user can customize with the help of predefined widgets. The widgets can be moved and arranged using drag & drop, and small widgets can also be placed next to each other. If one dashboard is not enough, the user can also create additional dashboards and add widgets as required.

For integrators, the dashboard also offers the option of defining ready-made dashboards with widgets in advance. The user can then select this as a template when creating a new dashboard.

The dashboard currently only offers a small selection of prepared widgets. These are widgets with information about the system or current news from the TYPO3 world.

These widgets are therefore mainly aimed at administrators who want to keep up to date with the system and TYPO3. One example is the "TYPO3 security advisories" widget with current information on security vulnerabilities and security updates.

But what about editors?

No problem: the dashboard can be extended quite easily with additional, custom widgets.

Using a simple YAML configuration, you can create your own variants with a customized configuration based on the existing widgets. For example, you can create your own RSS feed widget without writing a single line of PHP code.

If this is not enough, you can of course also develop your own widgets and register them again via YAML and make them available in the backend.
In this way, you can provide editors with pretty much any desired information as a widget, such as:

• Which pages and content in my area or from my favorites were last changed?
• Are other colleagues (users with the same BE group) currently online?
• Are there new features for editors?

The possibilities here are almost unlimited.

If editors do need some encouragement, why not offer a "joke of the day" widget that randomly selects and displays a joke from a secure source (e.g. a trustworthy web service)?

There were already colleagues here who wanted to create a random cat picture widget, but fortunately we were able to stop them. After all, we are serious developers....