Practice

Evaluating TYPO3 Extensions Before You Install Them

An extension is quick to install and hard to get rid of. Because it has to be carried along at the next major update, the choice decides effort that falls due years later.

Why the choice counts later

At the update to a new TYPO3 version, the effort rarely arises in the core. It arises in the extensions: each needs a compatible release, otherwise you need a replacement or a solution of your own.

Every extension installed today is therefore a commitment for later. That perspective is missing in the moment you install it, because there you are solving an immediate problem.

The criteria before installing

State of maintenance. When did the last release appear, and was the current TYPO3 version supported promptly? An extension that took a year at the last major jump will hold you up at the next one too.

How widely it is used. Widely used extensions are more likely to keep being maintained, and more likely to have answers available when something jams.

Dependencies. Some extensions bring others with them. One installation turns into three, and each has to be carried along at update time. Composer makes those dependencies visible before you take them on.

Feature set against need. An extension that can do twenty things, two of which you need, brings eighteen potential sources of trouble with it.

How deep it reaches. Extensions that hook deeply into the system or change core behaviour cost more at update time than ones that stay within their own territory.

The cost of getting out. What happens if the extension stops being maintained in two years? Does the data sit in a structure of its own that can be read out, or would it be lost?

The existing list as a task of its own

In installations that have grown over years you regularly find extensions that were installed once for a particular occasion and forgotten afterwards. They cost effort at every update without anyone missing their function.

So reviewing what is installed is worth doing before every larger update. The same question applies to each one: is this still used, and if so, by whom?

Experience says a portion of them can be removed with no replacement. That is the cheapest form of reducing effort, because it costs nothing beyond the review.

When an extension falls away

It happens that an extension you need is no longer available for the target version. There are then three routes.

An actively maintained replacement, if one exists that serves the same purpose. The data migration is the actual work there, not the installation.

A custom implementation of the part actually used. That is often less than the scope of the original extension suggests.

Or going without, if it turns out the feature is barely used. That option gets considered too rarely.

Common questions

How do you tell whether an extension is maintained?

From several signs together: when did the last release appear? Is the current TYPO3 version supported, and how quickly did that support arrive after it came out? Do reported bugs get answers?

The most telling indicator is the behaviour at the last major jump of TYPO3. Whoever caught up promptly then will probably do it again.

Is a custom implementation better than an extension?

Not as a rule. A maintained extension that does exactly what is needed is almost always the better choice, because its ongoing development is shared across many users.

A custom implementation is worth it when only a small part of the feature set is needed and the extension brings a lot of ballast with it, or when the requirement is so specific that any extension would have to be adapted anyway.

Terms used on this page

Too many extensions installed?

We will look at the list and sort it by state of maintenance and actual use. Often a part of it can go with no replacement.