Mehrsprachigkeit in DB-Abfrage

Moin Moin.
Ich bin gerade ein FE-Plugin am schreiben, das ein Formular anzeigt. Das ist nicht weiter wild und funktioniert auch soweit.
Aber es gibt eine Besonderheit: Im Formular gibt es eine Auswahlliste, aus der der Besucher etwas auswählen soll. Die Einträge der Liste soll der Redakteur im Backend anlegen und bearbeiten können. Soweit so gut, im Backend können die Datensätze angelegt werden, ohne Problem. Auch die lokalisierung funktioniert im BE.
Im FE wird das Formular korrekt angezeigt und der Besucher kann aus der Liste auswählen, alles OK.

Die Einträge der Liste haben rein garnichts mit dem Model der Ext am Hut, daher hol ich die Datensätze manuell vom Repository in den Controller, ungefähr so:

public function findRaw(){
	$query = $this->createQuery();
	$query->getQuerySettings()->setReturnRawQueryResult(TRUE);
	$query->statement('SELECT * from tabelleXY');
	return $query->execute();
}

In der Standarsprache funktioniert das, aber sobald die Sprache wechselt, dann wird nur die Standardsprache ausgegeben. Dann hab ich das hier noch gefunden:

$query->getQuerySettings()->setRespectSysLanguage(TRUE);

Was leider auch kein besseres Ergebnis bringt.

Wenn ich gezielt nach sys_language_uid abfrage dann bekomme für die Sprache 1 immer null Zeilen, egal welche Sprache gewählt ist.

Woran könnte das liegen? Jemand einen Tip für mich?

Die Sprache habe ich so konfiguriert:

page.config.linkVars = L,tx_ttnews|tt_news
page.config.uniqueLinkVars = 1
page.config.sys_language_uid = 0
page.config.language = de
page.config.locale_all = de_DE.UTF8
page.config.sys_language_overlay = 1

[globalVar = GP:L = 1]
page.config.sys_language_uid = 1
page.config.language = en
page.config.locale_all = en_EN.UTF8
[global]

Ist daran etwas falsch?
Für Texte habe ich die locallang.xlf bearbeitet und auch eine de.locallang.xlf angelegt. Die Übersetzungen der Sprachtdateien funktionieren, da hab ich kein Problem.

Betrifft Typo3 6.2.4.

Wäre super wenn jemand einen Tipp hat 🙂

MfG

hi muelli,

ich bin etwas irritiert, weil du mit deiner Abfrage
findRaw + $query->statement('SELECT * from tabelleXY');
eigentlich den kompletten Query Manager aushebelst.

Zur Lösung deines Problems könntest du über das Installtool die Einstellung für sqlDebug auf 2 setzen. Dann siehst du zwar im Frontend sämtliche Querys, aber kannst dir deinen eigenen rauspicken und siehst genau, wie dein Query am Ende aussieht. Vielleicht hilft dir das weiter.

Hi,

hm, merkwürdig. Die Abfrage sieht genauso aus wie im Statement.
Ich hab aber festgestellt, wenn ich nur SELECT * FROM tabelleXY abschicke dann sind deutsche sowie englische Datensätze im Result enthalten. Dann läuft das Ergebnis durch die Methode doLanguageAndWorkspaceOverlay, dabei werden alle englischen Datensätze entfernt und nur _Orig_uid werden zurückgegeben.
Bei der RawQuery kommt wirklich nichts dahinter, keine zusätzlichen Spalten. Ich würde das gerne direkt mit dem entsprechenden Repository machen, aber ich bekomme immer einen Fehler 🙁

In meinem Controller habe ich das andere Repository erstmal so versucht einzubinden:

/**
 * andereRepository
 * 
 * @var \ven\ext\Domain\Repository\andereRepository
 * @inject
 */
protected $andereRepository = NULL;

Hm, wenn ich dann aber $this->andereRepository->findAll(); aufrufe, dann bekomme ich leider nur einen Fehler:

Fatal error: Call to a member function findAll() on a non-object in

Einen Tipp wie ich an das Repository rankomme?

Danke 🙂

NULL ist ja nun auch wirklich kein Objekt, oder? 😉

Eigentlich stimmt die Injection von dem Repository, wie sie da oben steht. Vielleicht ein Cache Problem?

Wenn man Extensions entwickelt, kann ich auch nur empfehlen folgendes Typoscript in die TSConfig von deinem Typo3 Nutzer einzufügen:

options.clearCache.system = 1

Das war bei mir Knackpunkt bei diversen Problemen bei der Erstellung von Backendmodulen, dass bestimmte Sachen im System Cache liegen.

Moin,

den Cache hab ich geleert. Im BE hab ich no_cache = 1 und bei Fehler leere ich immer erst das Typo3temp Verzeichnis komplett, um das auszuschließen. Beim Bearbeiten der locallang Dateien kann das temp-Verzeichnis schonmal ganz schön nerven. ClearCache schalte auf jeden fall mal ein, das kannte ich noch nicht.

Die andere Extension, die das repository bereitstellen soll hatte ich als Miscellaneous erstellt, da die nur die Backend-Tabelle für Datensätze bereitstellen soll. Daraus hab ich nun mal ein FE-Plugin gemacht und mir auch die Datensätze im FE ausgegeben. Die normale ausgabe funktioniert in beiden Sprachen.
Die Injection von dem Repository hab ich dann auch mal aus dem Controller der anderen Extension kopiert. Das sieht genauso aus und funktioniert dort wunderbar.

Noch eine Idee? Sollte das Repository evtl. in der Extensions selbst liegen? Ich mein, egal wo es nun liegt, mit dem namespace kann ich doch genau darauf zugreifen... hm.

Anscheinend lag es wirklich am Cache. Jetzt kommt der Fehler nicht mehr, allerdings auch keine Datensätze.

Leider liefert mir findAll() keine Datensätze. Der Controller der anderen Extension bekommt alle Datensätze zurück. In der benötigten Extension kommt nur NULL zurück 🙁

Der Controller kann auf jeden Fall jetzt im Repository die Methoden aufrufen. Habe eine Test-Methode reingeschrieben und der Aufruf funktioniert. Jedoch liefert findAll() nichts zurück. Vielleicht eine Idee?

Also nochmal:

FALSCH

    /**
     * andereRepository
     *
     * @var \ven\ext\Domain\Repository\andereRepository
     * @inject
     */
    protected $andereRepository = NULL;

RICHTIG

    /**
     * andereRepository
     *
     * @var \ven\ext\Domain\Repository\andereRepository
     * @inject
     */
    protected $andereRepository;