You are currently viewing Code Quality of TYPO3 Extensions

Code Quality of TYPO3 Extensions

Code quality tools measure the code quality against defined rulesets. SInce a couple of months a website exists, which is monitoring all TYPO3 extensions available in the TER. What is checked and how can you benefit from this service?

The service is based on, an open source project. It’s goal is to support enhance code quality continuously. It is possible to integrate it in continuous integration environments like JenkinsCI or Travis. But it is also possible to provide the analysis via a stand-alone website, where the various projects are imported and analyzed.

This is the approach, that Marketing Factory Consulting has choosen, to monitor all TYPO3 extensions, which are available via the TYPO3 Extension Repository. As of the time of writing over 7300 extensions are checked. A check is done, whenever an extension is uploaded to the TER. The service is available at


There are some concepts behind sonarcube: Rules, quality profiles, levels of violations and quality gates.


A rule is the smallest entity of the concepts. It defines a violation, which is detected in the code. Sonarqube delivers over 120 rules for php. An overview of all rules is available here .

Quality profiles

A quality profile consists of a set of rules, which can be defined by the sonarcube admin. Several profiles are available by default for Drupal and PSR-2. The setting for TYPO3 is based on the “Sonar way”. At the time of writing it is a set of 62 rules.

Levels of violations

To each rule a violation level is assigned. There are three of them: Bugs, vulnerabilities and code smells.

Bugs are “issues that represents something wrong in the code. If this has not broken yet, it will, and probably at the worst possible moment. This needs to be fixed. Yesterday.”

A vulnerability is a security-related issue which represents a potential backdoor for attackers. More information about these rules is available at

The scope of code smells is about the maintainability of the code. The better the rating in this area the easier it is for its maintainers to work on the code.

Quality gates

In the official documentation this is defined as a set of conditions, which must be met by the project to be released to production. If this set is not matched, the project cannot be released. In case of TYPO3 extensions, this is “just” a marker, whether a new release complies will pass the quality gate.

Each level of violation has its own limitations, that must be met by the project:

  • new bugs: no new bugs allowed
  • new vulnerabilities: no new vulnerabilities allowed
  • code smell ratio (aka “Technical Debt Ratio on New Code”): max 5% in new code

But now enough of the theory, let’s have a look at the website.

Project list and filters

The main entry point is the project overview at Without any filters you get a list of all extensions covered by the website. They are sorted by the upload date to the TER starting with the youngest.

An example is the extension “groupdelegation”:

Examble of code quality of the extension "groupdelegation"

On each extension entry there are six ratings available. Each rating can have a status from A (best) to E (worst).

Quality gate shows whether the extension passed the quality gate as described above.

The Reliability Rating reflects the severity of bugs.

The Security Rating sums up the vulnerabilities found in the code.

The Maintanablilty Rating shows a ratio between the cost of development and the cost of fixing all issues found. If the time needed is less than 5% of the original development time, it gets the rating “A”, if it is more than 21%, then the extension is rated “D”.

The Coverage percentage is always zero. The sonarqube docs are writing about the coverage by unit tests. But I can’t believe, that there are no unit tests in extensions.

Duplications show the blocks of code which are similar throughout the project. For php projects the limit is ten lines of code. Differences in indentations and string literals are ignored.

The Size of the code reflects the number of lines of code in this project.

On the left side are several filters to reduce the number of shown extensions or you may want to search for your own extension(s).

Project view

After clicking on a project title, the “homepage” of the extension is shown.

Code quality overview of TYPO3 extension "groupdelegation"

This is a more detailed overview about the issues of the extension. The “code smell” section lists the number of smells and the estimated time to remove them.


The issues view lists all issues which should be solved and tells in detail where the problem is. If you have a project with many issues, you can use the filter on the left sidebar, to narrow down on what you would like to work on.

Issues found of extension "groupdelegation"


This is a really cool tool provided by Marketing Factory Consulting to check extensions against a common ruleset. This is valid especially for you as an extension author.

Please keep in mind that this is not a rating of the functionality of an extension or whether it is bug free or not. An extension can have a rating “D” in every field, but can fit to your needs in every way!

For this initiative, I have got three wishes:

1) Let it run under an official domain.

This can be really helpful for extension authors and will help to enhance their code quality.

2) Create official rules

It would be helpful, if the defined quality profile is endorsed by the TYPO3 core team to have commonly acknowledged rules for every extension.

3) Include TYPO3 core

When there are the rules for extensions, why shouldn’t they be valid for the TYPO3 core. So I would like to see the TYPO3 core in this initiative too (having in mind that there is much “legacy” code in it).


I want to thank my supporters via, who make the blog posts possible:

Martin Nürnberger

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 pixabay . It was published by Free Photos under the CC0 public domain license. It was modified by myself using pablo on buffer.

This Post Has 5 Comments

  1. Joey

    Well – I took a look at some of the “Major” or “Critical” so called bugs in this case for my own extension, which is Gridelements. The “Reliability” rating is D, because stuff like this:
    is considered to be a bug.

    So the ruleset seems to be at least questionable, which is why especially 2) would be mandatory before 1) and 3) should be accomplished.

    1. Daniel

      This tool was originally setup as a tool from developers for developers. It should give us the opportunity to write more reliable code with higher quality. It can give you also an expertise on deciding if you want to use an extension in your projects or not.

      The ruleset which is configured, is the ruleset we also use on our internal projects, and is mostly based on the official Ruleset which is used for the Drupal Project. I’ve recently seen that there was an update on the Base Ruleset, which is now active. The mentioned line of code would be now considered as a “minor Bug”. We can and should consider about the ruleset and its weighting in the future.

      Feel free to contribute to this project, you can get in touch with me on the TYPO3 Slack via @derdanne, or meet me and my collegues at the TYPO3camp-RheinRuhr.

      By the way, you already can find the TYPO3 CMS tested via sonarqube at

      Best regards,

    2. Sven Teuber

      Well, that particular bit of code is a bit more complicated than the functional logic requires, so there is a higher probability of introducing errors here when altering or expanding the code in the future.

      Took me a few minutes to “get” what’s happening, although it is really rather “simple” and should’ve taken seconds to grasp. Following the intended logic of the process, I’d structure that code more like this – getting rid of the “double” line that was deemed a “bug” in the first place:

      $typoScriptSetup = [];
      if ($layoutId && isset($this->typoScriptSetup['setup.'][$layoutId . '.'])) {
      // If there is a TS setup for the given layout id, use it
      $typoScriptSetup = $this->typoScriptSetup['setup.'][$layoutId . '.'];
      } elseif (isset($this->typoScriptSetup['setup.']['default.'])) {
      // Else fall back to a given TS default setup, if it exists
      $typoScriptSetup = $this->typoScriptSetup['setup.']['default.'];

      // If neither a specific nor a default setup was found,
      // use a reference to the tt_content setup as a default renderObj
      if (empty($typoScriptSetup)) {
      $typoScriptSetup['columns.']['default.']['renderObj'] = '<tt_content';

      Now, the code follows the logical path: Look for a particular layout setting. Use a standard setting if no layout-specific setting exists. Fall back to a very basic version if there is not even a standard setting. You can almost read the code “like a book”, without “backtracing thoughts”.

      So, yes, I think it is correct to mark this double line as “take a look at this, please”, and yes, refactoring it will enhance the reliability of the code because it will be easier to understand and easiert to introduce changes. It’s not a “major bug” in the developer-sense of a bug breaking the functionality, but it is a “conceptional bug” in the sense that it could be implemented easier and more clearly, which will indeed enhance the reliability of the software.

  2. Anonymous


Leave a Reply