TYPO3 Core

pending in core list

Patch tested and it seems to do the job. Thanks Jo!

So can you give a +1 in the core list please?

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/16838

Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/16838

Patch set 3 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/16838

Patch set 4 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/16838

Patch set 1 for branch TYPO3_6-0 has been pushed to the review server.
It is available at http://review.typo3.org/16917

Patch set 2 for branch TYPO3_4-7 has been pushed to the review server.
It is available at http://review.typo3.org/16815

Patch set 1 for branch TYPO3_4-6 has been pushed to the review server.
It is available at http://review.typo3.org/16920

Patch set 1 for branch TYPO3_4-5 has been pushed to the review server.
It is available at http://review.typo3.org/16921

Patch set 2 for branch TYPO3_4-5 has been pushed to the review server.
It is available at http://review.typo3.org/16921

Patch set 2 for branch TYPO3_4-6 has been pushed to the review server.
It is available at http://review.typo3.org/16920

Patch set 3 for branch TYPO3_4-7 has been pushed to the review server.
It is available at http://review.typo3.org/16815

This patch introduced regressions and is reverted in all versions for now:

We have problems with multiple extensions: For example we see warnings in list module with direct_mail and imagecycle, and ext:realty throws a db error.

Most warnings can be fixed pretty easily by making sure the first parameter ($items) is an array. In tcemain, this is ensured by initItemArray() that is called on $items before they are fed to procItem. A simple fix in list module would be:

$items = is_array($fieldSetup['config']['items']) ? $fieldSetup['config']['items'] : array();
$GLOBALS['TCA'][$table]['columns'][$field]['config']['items'] = $formEngine->procItems(
   $items,
   ...

• config['displayCond'] must be evaluated. For example ext:realty executes the itemsProcFunc for select only, if dispalyCond "$city > 0" is true.
• The list module does not work with select * of the database row in question, but only has the fields that are actually shown. tcemain always works with the whole $row, so list module must fetch complete row if calling itemProc(), too.
• As far as I can see from tcemain, itemProc is only called for tca types select, radio and check. Entry methods in tcemain are the getSingleField_type* methods.
• initItemArray() must be called before calling procItem()
• If config = select, further additional things must be done: addSelectOptionsToItemArray(), keepItems handling, addItems handling, removeItems handling (after procItems call). They should all work and have several funny dependencies that all must be checked.

Imho the above list is definately not trivial and a real fix should probably even clean up things in tcemain before, to simplify the whole stuff for easier re-usage in list module or at other places where rows are shown.

As a result, I'll for now have to revert the patch in all versions. Furthermore, the issue is now marked as "feature" and will not be backported to stable versions again to not risk another regression again.

Would be great if someone could work on all this stuff.

Thanks for the analysis and reverting the change, Christian. I've stumbled over that bug also starting with 4.5.23.

For the record: the buggy behaviour introduced by this change started in

• 4.5.23
• 4.6.16
• 4.7.8
• 6.0.1

And will now be fixed in the next releases:

• 4.5.26
• 4.7.11
• 6.0.5

Cheers,
Ernesto

Thx Ernesto. Actually, I reverted this one also in 4.6, just in case we are forced to still release another 4.6 again I don't want the regression to be in there.

I'm currently stuck at this problem. Tried the original patch which has many flaws, as Christian already pointed out.

A solid fix for the problem would probably require additional configuration flags to enable/disable the processing for each entry, because otherwise this can likely become a performance killer.

In my case however, it would already be enough if the value is displayed as stored in the database:

                unset($GLOBALS['TCA'][$table]['columns'][$field]['config']['items']);
                unset($GLOBALS['TCA'][$table]['columns'][$field]['config']['itemsProcFunc']);
                $GLOBALS['TCA'][$table]['columns'][$field]['config']['type'] = 'text';

Does that sound acceptable as a workaround? At least it's better than an empty value, which is currently the case...

Let me know then I'll prepare a patch.

Related tickets:
#100855
#102616

see https://review.typo3.org/c/Packages/TYPO3.CMS/+/82148