Add custom typoscript to Content-Block

[subjacked]

Supply a way to enrich content-blocks with custom typoscript Rendering, e.g. DataProcessors like Menu. This should happen in the folder of the specific content-block to maintain the easyness of copying the blocks.

[subjacked]

My solution for now looks like this

[peterkraume]

I like the idea, but I would prefer a solution where a specific TypoScript file within a content block is included automatically if it is present. From there I could then include more files if necessary.

[krausandre]

Despite I understand the wish and the need to have this, I don't think this is a good idea, because we want to keep content blocks as easy as possible. And therefore there are results in the concept saying no PHP, no TypoScript and so on.

[jonaseberle]

Maybe not in the form of a generic TypoScript but rather just the possibility to define (and configure) additional DataProcessors?

[krausandre]

@jonaseberle do you mean something like adding DataProcessors via the config yaml?

[schliesser]

Could be a nice way. Here a current example with conditions in the dataProcessing configuration

My typoscript

# Menu Cards (selected or subpages of selected)
tt_content.vendor_menucards {
  dataProcessing {
    200 = menu
    200 {
      # Show selected pages
      if.isFalse.field = vendor_show_subpages
      special = list
      special.value.field = pages
      dataProcessing {
        10 = record-transformation
      }
    }
    300 = menu
    300 {
      # Show subpages of selected pages
      if.isTrue.field = vendor_show_subpages
      special = directory
      special.value.field = pages
      dataProcessing {
        10 = record-transformation
      }
    }
  }
}

Idea for definition in config.yaml

name: vendor/menu-cards
typeName: vendor_menucards
group: menu
prefixFields: true
prefixType: vendor
fields:
  - identifier: TYPO3/Header
    type: Basic
  - identifier: pages
    useExistingField: true
    minitems: 1
  - identifier: show_subpages
    type: Checkbox
    renderType: checkboxToggle
basics:
  - TYPO3/Appearance
  - TYPO3/Links
dataProcessing:
  - type: menu
    config:
      if.isFalse.field: vendor_show_subpages
      special: list
      special.value.field: pages
      dataProcessing:
        - type: record-transformation
  - type: menu
    config:
      if.isTrue.field: vendor_show_subpages
      special: list
      special.value.field: pages
      dataProcessing:
        - type: record-transformation

[krausandre]

If we talk about possibilities to configure data processing for a content block, then IMHO this is another topic than bringing TypoScript to Content Blocks. And this is a feature, we should definitely think about a concept. (I want to make the point, that this might have dependencies to the outside, which can not be resolved by a content block, e.g. "bring your own DataProcessor".) But configuring data processing is an often needed situation, I would say.

To go ahead with this thought: adding templateRootPaths / partialRootPaths / layoutRootPaths or overwriting the templateName is another task, what we have to do with typoscript.

Is there anything left?

[lukaszuznanski]

If you think of headless approach, then we use typoscript as a place to define final rendering of your element, e.g.
https://github.com/TYPO3-Headless/headless/blob/master/Configuration/TypoScript/ContentElement/Text.typoscript
I understand that it's not core and it's 3rd party extension, but it would be nice if there would be possibility to automatically load typoscript files from content block.

[krausandre]

@lukaszuznanski looks like duplicate work for me. I would suggest finding a way to directly take the config.yaml of each content block, so you don't have to define the fields twice. Wouldn't that be much more convenient?

[jonaseberle]

We talked about this in our Content Types Team meeting.

We are currently undecided, but here are some points we gathered:

• Currently config.yaml is backend-centric
• A custom data-processor would be the first external dependency (apart from Basics) outside of the Content Block folder
• Idea: it could be defined at the field (“this field is filled by this DataProcessor”)
• Idea: Could by a Field Type that adds a DataProcessor configuration

[schliesser]

We talked about this in our Content Types Team meeting.

We are currently undecided, but here are some points we gathered:

• Currently config.yaml is backend-centric
• A custom data-processor would be the first external dependency (apart from Basics) outside of the Content Block folder
• Idea: it could be defined at the field (“this field is filled by this DataProcessor”)
• Idea: Could by a Field Type that adds a DataProcessor configuration

I thought about a separate field type first, but doesn't seem right to me, as all fields correspond to some backend field or field beaviour (Linebreak). In my described usecase the fluid variable "menu" is filled by one of the two data processors, depending on the state of another field. I'm not sure how this could be defined on field-level where the identifier matches the fluid variable name? 🤔