Meiner Einschätzung nach ist der leere Rückgabewert bei den static_* Tabellen auf die SELECT-Abfrage in tslib_content zurückzuführen.
In tslib_content::getQuery() wird der logische Operator NOT (!) verwendet, um die select-Eigenschaften ausm TS auf ihre Existenz zu überprüfen.
foreach($properties as $property) {
...
if(!$conf[$property]) {
unset($conf[$property]);
}
...
}
Da es hier zwischen 0 und leer nicht unterschieden wird, trifft die Bedingung für select.pidInList=0 auch zu.
Somit wird das Element $conf['pidInList'] gelöscht.
Im nächsten Schritt wird $conf['pidInList'] mit '' verglichen.
if(!strcmp($conf['pidInList'], '')) {
$conf['pidInList'] = 'this';
}
Die Bedingung ist hier erfüllt und es gilt für den nächsten Verlauf
$conf['pidInList'] = 'this';
Und jetzt kommt der entscheidende Punkt: in tslib_content::getWhere() wird dieses 'this' mit dem Wert von
$GLOBALS['TSFE']->contentPid
ersetzt. Angenommen 4 wäre die ID der Seite mit dem Formular, steht somit in der WHERE-Klausel
static_countries.pid IN (4)
Folglich wird die SQL-Abfrage
SELECT cn_iso_3, cn_short_en FROM static_countries WHERE static_countries.pid IN (4) AND static_countries.deleted=0
ausgeführt, die logischerweise NULL-Resultat liefert, weil die gesuchten static-Daten unter pid=0 stehen.
Aus meiner Sicht wäre man mit !isset() in der foreach-Schleife besser dran. Dies schließt den Wert 0 aus.
Damit würde die Eigenschaft nur dann gelöscht, wenn sie wirklich nicht gesetzt ist.
Die Änderung würde alle Tabellen der Erweiterung static_info_tables einschließen.
Mit select.pidInList=0 und
foreach($properties as $property) {
...
- if(!$conf[$property]) {
+ if(!isset($conf[$property])) {
unset($conf[$property]);
}
...
}
können die Datensätze auch gefunden werden.
VG,
LuP