Simplify the process to create custom content elements

Archive Initiative Ideas
1

Hi guys,

while the steps to create a custom content element are quite straight forward it still requires duplicate definitions. I understand that some things have to be configured at different locations (TS, tt_content.php, …), yet there are parts that can and should be simplified in my opinion. So, convention over configuration. Following things I would like to simplify:

  1. Definition of the Icon at one location, but not three or even more
    1.1 Either configure it once. For example in TCA
    1.2 It is expected to be located at a specific path. For example ext:my_ext/Resources/Icons/CType/ctype-name.svg

  2. Add the keys “label” and “description” to CType definition, which is used whereever these data are required and defined at the moment.

  3. Simplify the CType - addTcaSelectItem process
    3.1 For example by adding a helper method which figures out the icon and label by itself.
    ExtensionManagementUtility::addCTypeSelectItem(‘new-ctype-name’, ‘textmedia’, ‘after’);

  4. Simplify PageTS. Currently we define the icon and title here as well and we need to define the defValue CType here. We have defined them in the TCA, Overrides/tt_content.php already and it’s obvious which CType should be set here. So, I don’t see a reason why we should provide it.

I am looking forward for your feedback and if there are certain decisions why it has been implemented like that and therefore should not be changed, let me know :slight_smile:

Best regards,

Alex

2

Thanks for your ideas! IMO there need to be a lot more thoughts about creating content elements:

  • How to have content elements self contained and shippable to other projects
  • How to reduce the complete registration of content elements which containts title, description, …
  • How to remove the tsconfig for new content element wizard and auto register elements
  • Which TCA is really needed
3

1.1. Agree, we could make other code places read the TCA option. In general, checking the TCA to verify the presence of the CType makes it possible to warn about “unusable CType” in backend instead of frontend.
1.2. Disagree, we want to make it possible for third parties to change icons, secondarily we don’t want esoteric means of configuring icons for a plugin (list CType).
2. Somewhat agree; these pieces of info are already set by traditional API for registering content types, we might not want to bloat/break TS by demanding these two properties. Additionally, TS is for frontend and the proposed labels are for backend.
3.1. Disagree, we already have existing API for this and we do not need methods specific for a single field. The proposal also doesn’t take list CType into account.
4. Disagree; pageTSconfig has responsibilities different from TCA (and you can btw use pageTSconfig to modify TCA). DefValues serves customisation purposes that cannot be determined by simply reading TCA (any column can be configured with an overridden or default value by this method).

I’d advise against further fragmenting the API to register content types. I’d also refer to the “structured content initiative” who have taken it upon themselves to reinvent the content type registration API; their proposed methods are quite different from the ones proposed here. See https://github.com/TYPO3-Initiatives/structured-content/blob/master/Documentation/ContentBlocks/ContentBlockRegistration.md

4

Thanks for your quick response.

In regards of 4. Isn’t the CType an exception? Is there any scenario in which we want to have a different default value for CType?

Not saying to drop the defValue-feature in general, just saying that the defValue is set automatically to the CType which is registered in that context.

5

Is there any scenario in which we want to have a different default value for CType?

Certainly, yes. You can use this to create virtual “pre-configured” types where you have several virtual CType registrations in pageTSconfig and have each one set different default values of fields. The default values for a given CType should, in my opinion, be explicit and not based on convention. If CType is added to defValues in an intransparent (non-explicit) way this makes the system less predictable.

And it also doesn’t take list_type into account (this field is also passed as defValues when you have individual - virtual - CType entries for plugins and sub-plugins).

A compromise could be a separate module or even web service (browser-accessible) which generates the necessary resources for you to insert in pageTSconfig, TCA, TS etc. but I strongly belive we need to preserve the explicit nature of pageTSconfig.

6

I see your point. In regards of the generate-service. If there’s a generate service, it perhaps create the structure + files as well. I recently saw that the bootstrap_package has different files for each CType and such.

Yet, as suggested in slack, I will work on the overall proposal. Hopefully I find this evening time.

7

Indeed I agree a simplified process would be a benefit. Let me know if I can be of help

8

I did not had time to update the idea. Yet, I am currently working on a workaround to simplify the creation process. So, I am still on this :blush:

9

Hi Alex,

as Claus mentioned the simplification of the registration process for content elements/ content blocks is one of our main topics in the Structured Content Initiative. We developed a technical concept on how it might be like in the future: https://github.com/TYPO3-Initiatives/structured-content/blob/master/Documentation/ContentBlocks/ContentBlockRegistration.md

Now we need some more examples and are currently planing the process for an API prototype. But there are still some points to discuss.

You, and everyone else interested in this topic, are highly welcome to join our calls on Slack in #cig-structuredcontent and #cig-structuredcontent-contentblockcreation. We definitely need more support on this topic! Your contact person would be me :wink:

Btw: Our next call will be tomorow at 7 p.m. CET

10

We have setup a certain directory structure a while ago, which fee I would like to discuss / propose as best practice - so, will be added to the current documentation. However, I am unsure whether I should update this thread or create a new one. It feels more appropriate to create a new thread. Although this approach is based on ideas coming from this thread.

What’s your opinion?

11

Thanks, was pretty busy recently. I definitely will keep an eye on that. Yet, for now I prefer sth. which can smooth up the development rather sooner than later :slight_smile: