Bug #50785


FlexForm does not substitute markers in foreign_table_where

Added by Gabriel Kaufmann / Typoworx NewMedia almost 11 years ago. Updated almost 6 years ago.

Must have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


We tried to use a field-to-select condition in a flexform.

Simple example:

We have a FlexForm containing two Select-Fields:
1. StoragePid (Selecting from Pages-Table)
2. Any foreign record (like tt_address) that should show all records matching the FlexForm "StoragePid".

As FlexForm simply consists of XML'ified TCA we thought we can use ###REC_FIELD_StoragePid### (whereas "StoragePid" is the XML-Name of our Storage Selector form pages).

We noticed that the markers are not working correctly by reading/substituting those values from FlexForm XML.


class.t3lib_tceform.php_forge-50785.patch (2.84 KB) class.t3lib_tceform.php_forge-50785.patch Gabriel Kaufmann / Typoworx NewMedia, 2013-08-12 10:43

Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #30354: FlexForm select fields can't replace makers in their foreign_table_where clauseClosed2011-09-27

Related to TYPO3 Core - Bug #16392: Page-TSconfig ###PAGE_TSCONFIG_STR### not evaluated correctly in BackendClosed2006-07-21

Actions #1

Updated by Gabriel Kaufmann / Typoworx NewMedia almost 11 years ago

May be also related to: #30354

Actions #2

Updated by Gabriel Kaufmann / Typoworx NewMedia almost 11 years ago

Well I didn't find the right entry-point for a Core-Patch yet.

  1. The ##REC_FIELD_[ ROW-FIELD ] is substituted within t3lib_befunc::exec_foreign_table_where_query.
  2. The parsing of different Field-Types for TCA is done in t3lib_flexformtools.
  3. Setting a "Dummy" Field within t3lib_flexformtools::traverseFlexFormXMLData (f.e.) doesn't work as t3lib_befunc is accessing the row using $TSconfig['_THIS_ROW']

Anyone having ideas how to solve this?

Of course I could also use an ItemProcFunc on EACH PROJECT I ever need this. But I really think there should be one place to solve this problem and this would be the Core to have a one-place solution that is working for all.

Actions #3

Updated by Gabriel Kaufmann / Typoworx NewMedia almost 11 years ago

Since this issue/feature seems to be more complicated than I expected, I have to fall-back to itemProcFunc in FlexForm.

I believe we have to patch t3lib_BEfunc::exec_foreign_table_where_query()
as there the REC_FIELD's are substituted.

Too bad - there is no "row" argument used f.e. t3lib_transferdata::renderRecord_flexProc. Instead t3lib_BEfunc::exec_foreign_table_where_query() uses $TSconfig['_THIS_ROW'] build somewhere else.

I believe the integration way for this FlexForm-Feature would be:
  1. Check if the current-field renderes is inside FlexForm (refer to t3lib_transferdata::renderRecord_flexProc).
  2. Map all FlexForm-Values (of course we should respect lDEF and a possible localisation!) to the DB-Row temporarely (for Flex-Field rendering only).
  3. May be t3 t3lib-Rendering needs a complete clean-up to have one Storage for the current row?

Any ideas or suggestions are welcome!

Actions #4

Updated by Gabriel Kaufmann / Typoworx NewMedia almost 11 years ago

I have worked-out a patch that is fixing the missing fields for the "###REC_FIELD_" markers.

For this I patched "t3lib_tceforms" (see patch file provided).

I would be glad for approval and submitting to Trunk. The patch has been created on TYPO3 4.7.12.

About the patch:
I had to set a class-variable around the flex-rendering to let sub-processess (also used by normal TCE rendering) that it is currently acting within FlexForm-Fields.

All "Flex" fields (marked as type "flex" in TCA) are processed now.

The current patch provides the following syntax:
###REC_FIELD_[ flex-fieldname ].[ flexform-field ]###

f.e. to access a field from TemplaVoila FlexForm field named "field_storagePid":

The original field is prepended to avoid conflicts between multiple database-fields that may have the same name!

I would be glad about any feedback here.

Actions #5

Updated by Wouter Wolters about 10 years ago

  • Status changed from New to Resolved
  • Is Regression set to No

Resolved with #16392

Actions #6

Updated by Benni Mack almost 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF