TYPO3 QA and v14 upgrade parity for an industrial electronics maker

The client is a German maker of industrial electronics with a multilingual TYPO3 site. The work came through a German web agency.

It began in 2023 with a mobile check of the site. In 2026 the agency came back with a larger job: the site had moved from TYPO3 v11 to v14, and the new version had to match the old one exactly. I compared every page and closed the gaps through pull requests, measuring each change against the old site locally and again on staging.

Projects

1. 2023

   Mobile QA audit of a TYPO3 site on a real iPhone

   I checked the site on a real iPhone, read-only, for the developer who maintained it.

   A real iPhone catches what an emulator can miss. I sent a recording of the two main problems first. Then I sent the agency screenshots and the page URLs where the problems showed, as material for the site’s developer.

   Stack: TYPO3

2. 2026Came back after three years

   TYPO3 v14 upgrade: front-end parity with the old site

   On staging the TYPO3 v14 upgrade no longer matched the accepted v11 site: styles were missing, sliders were broken and the header was three times taller on phones. I brought the front end back to the old site.

   We agreed at the start that I would fix things directly in the repository. The brief was to match the old site exactly, with no redesign. I captured every page from the sitemap on both versions and compared them by CSS classes, markup and computed styles.

   Most gaps were styles v14 no longer delivered: standard content styles, rules tied to renamed classes, and module CSS left out of the new build. I restored them in the site package and left the content data alone. Then I brought back the team cards, the active menu colour, heading colours, outlined buttons and table borders. The slider arrows went back outside the slider, and the header slider on phones went from 540 px back to 165 px.

   I added a TYPO3 cache flush with a timeout to the deploy, so a failed flush cannot break it. I traced three content-data issues in a database dump and documented them for whoever holds write access. I checked every change locally, then on staging after each deploy, at five widths from 1440 to 375 px.

   Every pull request was merged. Across the whole sitemap, the number of pages whose height differed from the old site went from 21 to 0 at desktop width and from 41 to 0 at tablet width.

   Stack: TYPO3, TypoScript, Fluid, Sass, JavaScript, GitHub Actions