itemsProcFunc is not taken into account while generating labels for select items in the list module
While working with records listings in the list module you can activate different fields to be shown in the list of records of any table that is present in the current page.
Attached patch will apply the itemsProcFunc before using t3lib_BEfunc::getProcessedValueExtra to make sure the array of items matches the one that is used by the page module.
The list will show checkbox, radio and/or select fields as well and display the selected values for each record in the list.
But this display does not respect any changes to the list done by itemsProcFunc although the labels are changed when you open a record to edit it. This results in a completely different set of labels used by the list module, which can be easily triggered when using the new grid view.
While there are lots of new columns and labels available in the page module, there is still just Left, Normal, Right, Border for the values 1,0,2,3 in the list view, leaving the rest of the possible values with an empty label.
(issue imported from #M17682)
Updated by Christian Kuhn over 10 years ago
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, ...But the realty db error is not fixed by that and digging into this leads deep into the rabbit-hole. A new patch should at least do these things (grepped from the surrounding calling code of procItem calls in tcemain):
- 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.
Updated by Ernesto Baschny over 10 years ago
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
And will now be fixed in the next releases:
Updated by Michael Stucki over 8 years ago
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.
Updated by Riccardo De Contardi over 4 years ago
I tried the following test with TYPO3 9.5.8 and the latest version of gridelements
1) Install EXT:gridelements and check "Enable nesting in list module" in its configuration
2) Create a new Backend Layout item with three colPos:
- 0 with label "Main"
- 1 with label "Bottom"
- 100 with label "Other"
3) Create a new CE Backend Layout with two colPos:
- 200 with label "Left pos 200"
- 201 with label "Right pos 201"
4) assign the BE layout to a page; create some content in it and add also a Gridelement CE; put some content in it
5) Switch to List view
- the labels of the Backend Layout are taken ("Default", "Bottom", "Other")
- the labels of the CE Backend layout are not shown; just "200" and "201"
See attached Cattura.PNG screenshot.