Contao tries database update for custom element field

[fritzmg]

Since 1.3.5 (I think) I have a weird problem with a specific custom element that I use in an installation.

Whenever I want to insert a new Content Element into a fresh page, i.e. into an empty article, I get the following error:

Fatal error: Uncaught exception Exception with message Query error: Unknown column 'rsce_field_floating' in 'field list' (INSERT INTO tl_content (type, floating, sortOrder, perRow, sliderSpeed, sliderStartSlide, com_order, com_template, sh5_type, rsce_field_floating, pid, sorting, ptable, tstamp) VALUES ('text', 'above', 'ascending', 4, 300, 0, 'ascending', 'com_default', 'div', 'none', 75, 128, 'tl_article', 0)) thrown in system/modules/core/library/Contao/Database/Statement.php on line 295

#0 system/modules/core/library/Contao/Database/Statement.php(264): Contao\Database\Statement->query()
#1 system/modules/core/drivers/DC_Table.php(685): Contao\Database\Statement->execute()
#2 system/modules/core/classes/Backend.php(650): Contao\DC_Table->create()
#3 system/modules/core/controllers/BackendMain.php(131): Contao\Backend->getBackendModule('article')
#4 contao/main.php(20): Contao\BackendMain->run()
#5 {main}

For some reason Contao tries to insert data into the database for the custom element field "floating" (rsce_field_floating), which I have defined in one of the custom elements.

The minimum config of the custom element, that causes this error looks like this:

<?php

return array(
    'fields' => array(
        'floating' => array(
            'label' => array(
                'de' => array('Textumfluss','Textumfluss Einstellungen des Elements.'),
                'en' => array('Floating','Floating setting of the element.')
            ),
            'inputType' => 'radio',
            'default'   => 'none',
            'options'   => array('none','left','right'),
            'reference' => &$GLOBALS['TL_LANG']['rsce_factbox_config']['floating']
        )
    )
);

The problem does not occur, if I try to insert a content element into an article, that already has other content elements, it only occurs within empty articles. This is within a Contao 3.5.4 installation, with Rocksolid Custom Elements 1.3.5. The internal cache is disabled and I also tried to delete the RSCE cache.

The problem might not even be specific to this custom element, may be it just happens to be the first one in the list of custom content elements (alphabetically).

Unfortunately, I was not able to reproduce this problem in a separate fresh installation, even when I install all other extensions, that are present in the installation with the error.

But I was hoping that you might have a clue, why Contao would try to insert data into the database for a custom element field.

// edit: I just found out that it also happens in Articles that already have content elements - but only if you try to insert the new content element on the first position.

[ausi]

Does the error also appear if you disable all other extensions?

[fritzmg]

Yes, when I disable every extension except RSCE, the error appers.
(When I disable all extensions, including RSCE, the error does not appear.)

[fritzmg]

It seems to be related to an existing entry in the tl_content table. If I completely truncate tl_content, the error does not appear. When I re-import the previous SQL dump, the error occurs again.

If I delete all tl_content entries that belong to the custom elements containing the floating variable, the error does not occur. Hmm, maybe one of the custom elements has an invalid rsce_data value? Could that be the cause?

[fritzmg]

I have narrowed it down to one specific custom element in the database causing this problem. However, I do not notice anything wrong with it.

Even if I re-save the custom element causing the problem, it does not get rid of the error.

[fritzmg]

Weird. I copied the custom content element (via the backend, not via MySQL) and deleted the original. Now the error does not occur anymore.

I made an exact comparison of the old and the new SQL data, but the only differences are in the id, sorting and tstamp fields. Everything else is exactly the same.

[ausi]

Is the ID of the problematic content element the same as the ID of the article?

[fritzmg]

Ah, yep! It is/was. That also explains why this problem did not always occur in each article, only in specific ones. It seems the problem only occurs in articles that have an ID for which also a custom element exists with the same ID.

[ausi]

May be related to 4ea4ee8

[ausi]

Could you please try if the latest version from the master branch solves the issue in your installation?

[fritzmg]

Yep, that works.

[fritzmg]

Will there be a new release with this bug fix soon?

[ausi]

Version 1.3.6 is now released.