A “stalled” extension is a TYPO3 extension, where the active development seems to have stopped. There are seven ways to deal with it and to get the issues solved.

This question was raised by a participant at the TYPO3camp Munich last weekend. Probably everybody running a website was already hit by this question.

Reasons

There may be several reasons for the extension author not to currently maintain the extension:

• illness
• too much daily work
• other priorities
• lost interest in the extension and / or TYPO3 at all.
• and many more …

Each of them are valid reasons.

But you need to cope with this situation. In the following paragraphs, I will show you, what I do in such a situation. All these steps are not meant to be taken one after the other, they may appear at the same time.

Reach out to the author

The first thing is, that I open a ticket, where the extension is hosted (Github, Bitbucket, TYPO3 Forge). If there is no answer in a reasonable amount of time (usually several weeks), I reach out to the author in a friendly manner and ask for his plans for the extension, whether he has something already in progress and whether I can support him with code or financially.

Fork the extension and fix it

If I can and want to provide the fix, I fork the extension code from the original source repository. The next steps are to create a new branch, change the code, push it to my repository and make a pull request (PR). Until the PR is merged, I can use my own repository easily in composer based installations, just by adding the corresponding repository and branch name to the composer.json.

In one of the next blogposts, I will describe this contribution process in detail.

Use default extension and patch it

If the extension code is not available in a public repository or I do not want or am allowed to share the code publicly, then this is the way to go. Prerequisite is also that the installation is composer based.

Here I do not modify the code in a repository, but use the original code coming from the extension repository or packagist. Then I modify the code on my local instance and create a patch. I place this patch file into the project directory. Using the composer packages cweagans/composer-patches, I can patch the original source on the fly, while running composer install.

The documentation of the composer plugin is very good and it should not be much hassle to use this way. Or check out my post on this topic here: https://typo3worx.eu/2017/08/patch-typo3-using-composer/

No composer?

On an installation, which is not composer based, there is the possibility to modify the coder directly in the extension directory. This change only “stays alive”, when the stability in the file ext_emconf.phpis set to excludeFromUpdates, otherwise the extension will get updated with a newer version and the applied changes will get lost.

In my opinion: This is bad practice and such installations should be moved to composer as soon as possible. On docs.typo3.org is a very good tutorial, how to convert a “normal” TYPO3 installation to a composer based one: https://docs.typo3.org/typo3cms/InstallationGuide/MigrateToComposer/Index.html. Thanks Albrecht for writing that down.

Look for other solutions

If the effort to make the extension work or it is beyond my knowledge, I look for other solutions. For most topics there is more than one extension available. I test these solutions, compare the features and plan a migration path.

Another way can be an own development. In many cases I do not need the full feature set of an extension, but only small parts. The question is:

“How can I achieve the same result and stick as much as possible with TYPO3 native functions?”

If the solution is using TYPO3 native solution, upgrading to next major versions is much easier. Each major TYPO3 version comes with upgrade wizards and extensive upgrade documentation, that provides all necessary information for a successful upgrade.

Remove the functionality

One of the last resorts is to remove the functionality. This is also a valid solution, if the business value does not justify the effort to maintain the functions. To be honest: This question should be answered in many more cases with “NO”. This prevents also the piling up of legacy code, which is hard to maintain.

Ask Coders.Care

Last but not least, there is the possibility to use the help of third parties. This can be a TYPO3 agency or Coders.Care. Coders.Care provide service level agreements for maintaining extensions. The agreements cover bug fixes, security updates and upgrades to the next TYPO3 major versions. They work hand in hand with many extension authors to guarantee these services. If you want to know more about it, you can get in contact with Petra and Joey.

Conclusion

My favorite way to cope with the issue are the possibilities “Reach out to the author” and “Fork and Fix it”. Especially regarding the TYPO3 claim “Inspiring People to Share”, this is a perfect way to give back to the community,

If you likes the post or know somebody, who could profit from it, please share this post via your favorite social network: “Sharing is caring” ;-)

Credits

I want to thank my supporters via patreon.com, who make this blog post possible and who support me over many, many months.

If you appreciate my blog and want to support me, you can say “Thank You!”. Find out the possiblities here:

I found the blog post image on unsplash . It was published by rawpixel under the Unsplash license . It was modified by myself using pablo on buffer.