FFH for TYPO3

Industry-specific TYPO3 extensions don’t fail on technology, they fail on maintenance

FFH is a typical example of a whole category of TYPO3 extensions: built for one client or one industry, functional, but never maintained for a wider audience. The TYPO3 Extension Repository (TER) holds hundreds of them. Some see 5 downloads a year, have no documentation and a last commit from 3 years ago. That doesn’t make them bad. It means they need maintenance that the original developer no longer provides.

If your organization depends on an extension like this, the question is a practical one: keep using it and maintain it yourself, migrate to an alternative, or rebuild it. All three paths are viable. The right one depends on how complex the extension is, whether alternatives exist and how much pressure the TYPO3 release cycle puts on you.

Typical use cases

Industry associations with specialized requirements. Chambers of trade, sports federations and professional bodies run TYPO3 websites with features no standard plugin covers: member directories with radius search, event management that tracks continuing education credits, industry registers showing certification status. These run on custom extensions built 5-8 years ago and barely updated since. The feature works, but every TYPO3 update becomes a risk.

Media companies with editorial workflows. Radio stations, publishers and media groups run TYPO3 with extensions for playlists, program scheduling, media archives or content syndication. These extensions were often built in-house or by an agency that no longer supports the project. The code runs on TYPO3 v9, but the migration to v12 stalls on outdated APIs.

Public institutions with regulatory requirements. Schools, museums and libraries use extensions to manage opening hours, search catalogs or take event bookings. The requirements are specific (for example, an integration with library software such as Koha or Alma), and the extension was built once and never updated.

Technical architecture

Industry-specific TYPO3 extensions typically follow the Extbase/Fluid pattern: a domain model (PHP classes), repositories (database access), controllers (business logic) and Fluid templates (rendering). The data lives in dedicated database tables with the tx_extensionname_ prefix.

The most common architectural patterns are plugin-based extensions with frontend output (list view, detail view, filtering), backend modules for data maintenance and scheduler tasks for import and export. Many industry-specific extensions connect to external systems through REST APIs or CSV imports.

Code quality varies widely. Extensions from professional agencies follow the TYPO3 coding standards, use dependency injection and come with unit tests. In-house builds and rushed contract work often have hard-coded configuration, missing type declarations and no tests at all. Both can be maintained, but the effort differs by a factor of 3 to 5.

A typical analysis of an industry-specific extension covers four steps: measure its size (lines of code, number of classes, number of database tables), check its dependencies (which TYPO3 APIs it uses and which of them are deprecated in v12/v13), assess testability (are there unit tests, is the code structured so it can be tested) and estimate the migration effort.

Common problems and solutions

Deprecated APIs block the TYPO3 upgrade. The extension uses $GLOBALS['TSFE'], GeneralUtility::_GP() or ObjectManager::get(), all of them deprecated or removed in TYPO3 v12. Solution: systematic refactoring. Every deprecated API has a documented replacement in the TYPO3 changelog. For an extension with 5,000 lines of code, refactoring takes 3-7 days, depending on the number of deprecations.

No maintainer available. The original developer has left the company, the agency no longer exists, the TER package is orphaned. Solution: fork the code on GitHub, add the extension to your own Composer repository and maintain it yourself, or bring in an external service provider. Forking raises no legal issues as long as the extension is licensed under the GPL, which is the standard for TYPO3 extensions.

No documentation. Neither inline comments nor external docs. New developers have to read the code to understand what it does. Solution: write technical documentation before any refactoring starts. For an extension with 3,000-5,000 lines of code, 2-4 hours of analysis are enough to document its architecture, data model and business logic.

Migration and version compatibility

By their nature, industry-specific extensions have no official v12/v13 support. Each migration has to be handled individually, and the effort depends on three factors.

First: which TYPO3 version are you starting from? Moving from v9 to v12 is considerably more work than moving from v11 to v12, because v10 introduced dependency injection via Symfony and PSR-14 events; the new way of registering backend modules arrives with v12 on both paths.

Second: how many deprecated APIs does the extension use? The TYPO3 Extension Scanner (in the Install Tool) reports this automatically. An extension with 5 deprecations takes a day, one with 50 takes a week.

Third: how well is the code structured? Clean Extbase code can be migrated almost mechanically. Procedural code with direct database calls has to be rewritten.

That leaves three options: porting (adapting the extension to the new TYPO3 version, 3-10 days), rebuilding (same functionality, clean architecture, 2-4 weeks) or switching to an alternative (a standard extension that covers 80% of the functionality, plus custom adjustments). Gosign has analyzed, ported and rebuilt hundreds of industry-specific TYPO3 extensions and advises on the most cost-effective option.