Database field too short for FieldType color

[wini2]

When using the FieldType color with opacity the automatically created db-field ist varchar(7); only long enough for regular hex-values.

- identifier: hg-color
  type: Color
  opacity: true
  autocomplete: true
  default: '#0000FF'
  valuePicker:
    items:
      - [ 'helleres Grau', 'rgba(225, 222, 222, 0.2)']

This seems to be a little to short for rgba(xxx, xxx,xxx,0.5) or named colors like LightGoldenrodYellow. After changing it to a longer value in the db directly, the BE Analyze Database Structure suggests to resize it back to 7. This can be a little bit confusing.

content-blocks v1.3.19

[sbuerk]

disclaimer Not part ofthe content-blocks team.

Not sure about the conrete implementation, but I assume now that content-blocks
simply translates the type: Color to the TCA type='color'.

Not sure if opacity is set to TCA the same way.

TYPO3 main (v14) DefaultTcaSchema defines the DB field length depending on the opacitiy setting:

case $fieldType instanceof ColorFieldType:
    $tables[$tableName]->addColumn(
        $this->quote($fieldName),
        Types::STRING,
        [
            'length' => $fieldType->supportsOpacity() ? 9 : 7,
            'default' => ($fieldType->isNullable() ? null : ''),
            'notnull' => !$fieldType->isNullable(),
        ]
    );
    break;

which is literally included for TYPO3 v13 as:

case 'color':
    $opacity = (bool)($fieldConfig['config']['opacity'] ?? false);
    if ($fieldConfig['config']['nullable'] ?? false) {
        $tables[$tableName]->addColumn(
            $this->quote($fieldName),
            Types::STRING,
            [
                'length' => $opacity ? 9 : 7,
                'default' => null,
                'notnull' => false,
            ]
        );
    } else {
        $tables[$tableName]->addColumn(
            $this->quote($fieldName),
            Types::STRING,
            [
                'length' => $opacity ? 9 : 7,
                'default' => '',
                'notnull' => true,
            ]
        );
    }

TYPO3 v12 did not had that type or does not contained the default schema definition for that TCAtype (like a lot of others).

Taken from the mentioned content-block version you are on a TYPO3 v13 instance.
The 1.x version got quite some minor and patchlevel versions since the mentioned
version, so:

• Have you tried to upgrade to the latest 1.x version of content-blocks, possible that it has been fixed already ?

• Have you also tried to flush all (system caches) after changing the yaml file and before executing the DB Analyzer ? (Not into the whole process, never used content-blocks on my own - only guess work for that point).

From a quick look into the code, and as far as I understand it, I'd say that your reportis kind of weired.

• ColorFieldType does not define a custom getSQL() method.
• AbstractFieldType (parent of ColorFieldType) does define one returning an empty string.
• SqlGenerator::generate() loops over the definition, and only if getSQL() returns an non-empty string it provides sql create DDL statements for the Database Analyzer overriding the DefaultTcaSchema creating for that field. This is not the case here.

On the otherhand, the opacitiy is to TCA by the TcaGenerator from the ColorFieldType, see:

content-blocks/Classes/FieldType/ColorFieldType.php

Line 90 in 8c0bd7d

$config['opacity'] = true;

Only from reading the code this should work.

• Do you have most likely a ext_tables.sql in any extension (sitepackge) that defines the length/field of that table column (field) ?
• Do you have a TCA Override in place manipulating the TCA of that table/field which drops the opacity: true setting ?
• Have you checked TCA in the configuration module for that table/field if the tca is correct (like expected) and has the opacity set to true ?
• IS any PSR-14 event listener in place adding the sql ddl for that table/field with an other field specification ?

TBH - not checked, verified this in any instance, just reading the code here on GitHub and the issue combined with knowledge from the TYPO3 Core DefaultTcaSchema handling.

After changing it to a longer value in the db directly, the BE Analyze Database Structure suggests to resize it back to 7.

That sounds like opacity is not set to true in TCA, for what ever reason (see above).

Opacity TCA support exists since TYPO3 13.3 but I would assume that you are at least on a LTS version of v13, you are right ?

Otherwise the maintainers here have mostelikly better ideas than me and knowning this extension by hard.

[nhovratov]

I guess this is another: We put things in columnsOverrides and therefore the auto-db configuration of Core isn't working. We had the same already with options like max (length).

[sbuerk]

I guess this is another: We put things in columnsOverrides and therefore the auto-db configuration of Core isn't working. We had the same already with options like max (length).

Ah okay, I missed that looking on GitHub into the code. That would explain this, because DefaultTcaSchema does not take columnsOverrides into account. And not sure if that is reasonable to do. Correct me (I'm possible wrong) columnsOverride is a form engine only thing, or not ?

[nhovratov]

@sbuerk

The conflict is:

• Content Blocks wants to use columnsOverrides, so fields can be re-used with different configuration. E.g. one base color field is used in two or more CEs. One has opacity, but the other doesn't => This isn't possible right now with pure TCA.
• The DefaultTcaSchema wants to read the TCA without context of CEs and define the Schema based on this => Only works if relevant options are defined in the base definition of a column, not in columnsOverrides (There is a lot of magic involved and expects users to not use columnsOverride for those options, which they don't really know).

I'm keeping a list with options that can't / shouldn't be overridden by columnsOverrides for exactly this reason.

content-blocks/Classes/Generator/TcaGenerator.php

Lines 425 to 458 in 40da900

	$nonOverridableOptions = [
	'type',
	'relationship',
	'dbType',
	'nullable',
	'MM',
	'MM_opposite_field',
	'MM_hasUidField',
	'MM_oppositeUsage',
	[
	'type' => 'Relation',
	'option' => 'allowed',
	],
	'foreign_table',
	'foreign_field',
	'foreign_table_field',
	'foreign_match_fields',
	'foreign_sortby',
	'foreign_default_sortby',
	'symmetric_field',
	'symmetric_sortby',
	'exclude',
	// @todo This should be handled correctly with columnsOverrides in TYPO3 Core FormSlugAjaxController
	'generatorOptions',
	'behaviour.allowLanguageSynchronization',
	[
	'type' => 'Number',
	'option' => 'format',
	],
	'l10n_mode',
	'dbFieldLength',
	'items',
	'multiple',
	];

Possible solution:

• TCA could provide alternative options to define the db field length (like dbFieldLength in type Select).
• DefaultTcaSchema somehow respects columnsOverrides and picks the db definition, which is appropriate for all contexts (Use the most generous / widest definition)

Correct me (I'm possible wrong) columnsOverride is a form engine only thing, or not ?

I don't think anymore, at least it should now be evaluated in DataHandler: https://review.typo3.org/c/Packages/TYPO3.CMS/+/92371

[nhovratov]

@wini2 Fixed in Content Blocks v1.4.5

I keep this issue open for further discussion.

[wini2]

Thanks a lot for this instant help and support. After updating to v1.4.5 with my TYPO3 v13 Installation the opacity is respected like expected, so the annoying message for altering field in the DB Analyzer is gone.

[nhovratov]

Closing this. This discussions needs to be moved to Core channels. For Content Blocks this issue is solved for now.