Bug #33220
Empty content object when select.pidInList=0 set in TS
Status: | Closed | Start date: | 2012-01-16 | |
---|---|---|---|---|
Priority: | Should have | Due date: | ||
Assigned To: | - | % Done: | 0% |
|
Category: | TypoScript | Spent time: | - | |
Target version: | 4.6.4 | |||
TYPO3 Version: | 4.6 | Is Regression: | ||
PHP Version: | Sprint Focus: | |||
Complexity: |
Description
Hello,
I get an empty return value while rendering dropdown list for countries from the static_info_tables extension. I use following TS:
lib.country = CONTENT lib.country { table = static_countries select { pidInList = 0 orderBy = cn_short_en selectFields = uid,cn_iso_3 } ... }
While tracking the SELECT query in tslib_content, I found out in tslib_content::getQuery() that the logical operator NOT (!) is used to check all select proporties if they exist. This operator does not differ between 0 and empty.
foreach($properties as $property) { ... if(!$conf[$property]) { unset($conf[$property]); } ... }
Even select.pidInList = 0 is set in TS, the condition is fulfilled and $conf['pidInList'] is removed.
In next step, $conf['pidInList'] will be compared with ''
if(!strcmp($conf['pidInList'], '')) { $conf['pidInList'] = 'this'; }
and afterwards 'this' will be replaced with
$GLOBALS['TSFE']->contentPid
This leads to a wrong SQL-query because the ID of current page (4) is taken instead of the pid value (0) set in TS.
SELECT cn_iso_3, cn_short_en FROM static_countries WHERE static_countries.pid IN (4) AND static_countries.deleted=0
In my view, it would be more accurate if to use !isset() instead of NOT in the foreach loop. This will exclude the 0 value in TS.
foreach($properties as $property) { ... - if(!$conf[$property]) { + if(!isset($conf[$property])) { unset($conf[$property]); } ...
Many thanks and best regards,
Alain
Related issues
History
#1 Updated by Markus Klein over 3 years ago
if(!isset($conf[$property])) { unset($conf[$property]); }
seems to be a bit useless?!
#2 Updated by Jigal van Hemert over 3 years ago
- Status changed from New to Needs Feedback
I think it has been fixed with https://review.typo3.org/#change,7839
It should have worked because of a special exception for static_* tables, and in current master (4.7-dev) it already works correctly. In 4.6.3 it didn't work for me.
Can you test if the mentioned change solves the problem for you?
#3 Updated by Alain over 3 years ago
Hello Jigal,
thanks for feedback.
I apply this patch in 4.6.3 and it works great for me.
The same patch is also available at https://review.typo3.org/#change,7826 but it is under review.
Best regards,
Alain
#4 Updated by Ernesto Baschny over 3 years ago
- Category set to TypoScript
- Status changed from Needs Feedback to Closed
- Target version set to 4.6.4
Solution is already merged in #32374, so it will be available in 4.6.4 to be released soon. Thanks for your report and feedback!