Bug #76447

TypoScript Parse Bug

Added by Kevin Dargel about 5 years ago. Updated almost 5 years ago.

Must have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


The current TS-Parsing seems to ignore or take in account commented-out sections of TypoScript containing a condition (like PIDinRootline).

Put this at the end of a TS template and the following TS is not getting parsed (even TS code in the same template directly below those lines):

// [PIDinRootline = 0]

It may be reproducible with even less code lines; I'm unsure about the real cause.
I tested this with the following TS on a SUB-PAGE or on the same page, to verify it really isn't getting parsed/handled:

page.headerData.40 = TEXT
page.headerData.40.value = <meta name="test" />

It won't take effect.
(Reproduced with Typo3 6.2.21, 24 and 25)

Related issues

Related to TYPO3 Core - Feature #16681: C style TypoScript comments with start and end in one line lead to errorsClosed2006-11-01

Related to TYPO3 Core - Bug #41327: jsInline removes closing bracketsAcceptedBenni Mack2012-09-24


Updated by Markus Klein about 5 years ago

Maybe Elmar can take a look at this, he invested some time in this area recently.


Updated by Kevin Dargel about 5 years ago

  • % Done changed from 0 to 90

I found the corresponding code in the Typo3 Source.

Location: TYPO3.CMS/typo3/sysext/core/Classes/TypoScript/Parser/TypoScriptParser.php

Typo3 6.2.25 at line 483
Typo3 CMS (GitHub, Commit d1ecab6) at line 506 (should be v8, isn't it?)

if (strpos($line, '*/') === 0) {

should be changed to

if ((strpos($line, '*/') === 0) || (strripos($line, '*/') !== false)) {

Otherwise, multiline-comments only work if the ending */ is the first string/character group in the line.
Furthermore, this leads to a complete inactivation of every following TS-code (Extensions Templates or other stuff), as the following TypoScript is treated as part of the comment.

This solution checks the presence at the start (as before) and optionally checks for existance of an multiline-comment-ending-string, beginning the search at the end of the string.
Please beware of using an explicit position for the strripos() comparison with this technique, as there may be whitespace characters at the end (in this case, rtrim() is needed).

If this solution is not accepted, the syntax highlighting should be changed, as the commented section is still treated as a comment in the backend template editor, though the comment-end is not detected by this technique. Still, this needs to be verified and checked by somebody for possible problems created. My tests didn't result in any problems.


Updated by Bernd Wilke almost 5 years ago

problems could occur if you include other code (e.g. javascript) as typoscript data which uses the same character strings than typoscript.
so not only the usage of '{','}' is not unique, this might be also possible with '/*' and '*/'.

take the following example:

/* don't use the JS-init at the moment
page {
  JSinline = TEXT
  JSinline.value (
    var i = 1;
    $(document).ready(function () {
      /* init the page */


Updated by Bernd Wilke almost 5 years ago

just two other notices to this ticket:
1. it is documented that all comments beginning with an '/*' at the start of a line have to be closed with a '*/' at the start of a line (no comment-closing somewhere in or at the end of a line).
2. there might be a real error considering that an opened multi-line comment is not ended at the end of the current typoscript template (conditions are always ended at the end of a single template)


Updated by Benni Mack over 1 year ago

  • Related to Bug #41327: jsInline removes closing brackets added

Also available in: Atom PDF