TYPO3 Core

I had an element with some text (and a list) and several pipes in it. The content was just cut off somewhere and the output of the content elements after that element did not respect the image floating setting anymore. After replacing the pipes with a comma, the output was like it is expected.

Can you post the sample text please? Or try to generate a minimum example for reproduction?

I dived a little deeper into that problem. It seems that it works when the content is normally output through styles.content.get. But in that project, I have a website which has one page sections beginning at entry level 4 (pages in the backend with level 4 or 5 are output as one page sections with anchors and not as classic pages). If the element with the pipes is on a page of a one page section, the problem occurs. If the element is on a classic page (with classic output through styles.content.get), then there is no problem. The typoscript I use for the one page sections is like this:

lib.content.onepage = COA
lib.content.onepage {
# Output content of the page on third level itself
10 < lib.content.maincol
# Output content of the subpages as one page sections -> here is the problem
    20 = HMENU
    20 {
        #excludeDoktypes < lib.navigation.subnavigation.10.excludeDoktypes
      entryLevel = 4
        1 = TMENU
        1 {
            expAll = 1
            noBlur = 1
            NO = 1
            NO {
                doNotLinkIt = 1
                doNotShowLink = 1
                stdWrap2 {
                    cObject = COA
                    cObject {
                        10 = LOAD_REGISTER
                        10 {
                            foo.cObject = TEXT
                            foo.cObject {
                                field = uid
                            }
                          curentPageId.cObject = TEXT
                            curentPageId.cObject {
                                field = uid
                            }
                            sectionID.cObject = TEXT
                            sectionID.cObject {
                                field = alias
                              ifEmpty < temp.titleSectionId
                                #ifEmpty = p{field:uid}
                                ifEmpty.insertData = 1
                            }
                        }
                          20 = CONTENT
                          20 {
                            table = tt_content
                            select {
                              pidInList = {register:curentPageId}
                              pidInList.insertData = 1
                              #pidInList.field = uid
                              orderBy = sorting
                              where = colPos = 0
                              }
                            stdWrap.dataWrap = <section id="{register:sectionID}">|</section>
                            wrap.insertData = 1
                          stdWrap.required = 1
                            }
                  }
                  wrapItemAndSub = |
              }
        }
        2 < .1
    }
    90 = RESTORE_REGISTER
}
}

So maybe it is a bug of the core?

Well I do not trust the insertData things you use. That is just too dangerous in general for me, especially with content from the user.

We use a similar config for rendering pages into tabs, which looks like this:

tt_content.menu.40 = CASE
tt_content.menu.40 {
  key.field = menu_type
  tabs = HMENU
  tabs {
    special = directory
    special.value.field = pages
    wrap = <div class="container-fluid tab-container"><div class="row bg-box"><div class="container"><div class="row tab-content">|</div></div></div></div>

    1 = TMENU
    1.NO {
      doNotShowLink = 1
      wrapItemAndSub = |
      wrapItemAndSub.dataWrap = <div role="tabpanel" class="tab-pane active" id="t{field:uid}">|</div> || <div role="tabpanel" class="tab-pane" id="t{field:uid}">|</div>
      allStdWrap.cObject < styles.content.get
      allStdWrap.cObject.select.pidInList.field = uid
    }
  }
}

Thanks for that typoscript, I will try to adopt it! But why is insertData dangerous? So it is an “insertData Bug“?

I'm not sure whether it's an insertData bug. Generally inserData is dangerous when applied on data that stems from a non-trusted source, so basically anything you didn't write yourself.

e.g. non-safe is

temp.foo = TEXT
temp.foo.value.field = title
temp.foo.value.insertData = 1

If the user enters a title like "My custom content: {DB : tt_content:234:header}" in the content element you have a perfect possiblity to have information disclosure at minimum.

I just tested your advice, but it is still the same. I replaced the 20 = CONTENT part with the following:

20 < styles.content.get
20.select.pidInList.field = uid
20.stdWrap.dataWrap = <section id="{register:sectionID}">|</section>

So it is not insertData related. Another hint? I think it has something to do with the fact, that 20 is part of a TMENU wrap and the system thinks it is an option split wrap.

I have just found the problem. I just replaced stdWrap2 with allStdWrap and it works fine now. So is it an stdWrap2 bug?

Interseting indeed, but I have to look up, where stdWrap2 is applied here.

I'll not have time to invest this closer now and since there is a working solution and I'm not aware of any changes in this area I suggest to close this issue.
Would you agree?

I don’t mind, but the bug still exists.

But nevermind my problem is solved and if nobody else cares than I also won’t do (until the next one finds this bug)…