realURL: optimierte Multi-Domain-Konfiguration

Ausgangssituation

In einem Projekt waren in einer TYPO3-Instanz über den Seitenbaum mehrere Marken in verschiedenen Ländern mit jeweils eigenen (Teil-)Seitenbaum abgebildet. Die einzelnen Websites waren inhaltlich-strukturell sehr ähnlich, und es waren viele spezifische Plugins im Einsatz. Insgesamt entstand so für die rund 100 Einstiegseiten eine (via realURL-Autoconfiguration erzeugte) rund 4,5 MB große Konfiguration. Die war uns ein Dorn im Auge.

Weiterlesen»

locallang-Einträge werden nicht übernommen

Manchmal könnte man fast verzweifeln. Die neue Extension für den Kunden ist endlich fertig, es soll nur noch schnell ein Textchen mehr an einer Stelle rein. Kein Problem, locallang.xml ergänzt und im Fluidtemplate auch noch eine Zeile ergänzt – im Frontend bleibt die Stelle jedoch leer. Eine Überprüfung, ob der Key denn auch korrekt ist, bestätigt: ja, ist korrekt 🙁

Ursache ist (wie leider so oft) der Cache, der es (zu) gut meint.

Lösung:
Seit TYPO3 4.6 cacht der l10n-Parser (basierend auf dem Caching Framework) die Übersetzungen. Ein Löschen dieses Caches bringt dann den neu hinzugekommenen Wert auch zum Vorschein.

Durch Setzen des nachfolgenden Wertes in der localconf.php bzw. LocalConfiguration.php wird das Menü zum Cacheleeren um einen Eintrag für Übersetzungen erweitert:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['lang']['cache']['clear_menu'] = TRUE;

Quellen:

Typolink + realurl in Scheduler-Tasks

Anforderung war, dass aus einem Scheduler-Task heraus korrekte sprechende URLs erzeugt werden. Der einfachste Weg hierfür ist eine der typolink-Methode des cObjects. Leider steht ein solches aber in Tasks von Haus aus nicht zur Verfügung. Anleitung, wie man sich ein solches erzeugen kann, finden sich im Internet viele – leider aber auch zahlreiche, die nicht (mehr) funktionieren oder riesen woodoo treiben. Nach einigen Recherchen und Tests kann ich nun einen Weg zur Problemlösung festhalten.

Weiterlesen»

PHP array_merge_recursive() + realurl „fixedPostVars“

Einige Zeit hat es mich heute gekostet, um festzustellen, warum meine Erweiterung der realurl-Konfiguration via Hook zur Autoconfiguration fehlerhaft in der Konfiguration ankommt. Ursache ist ein Fehlverhalten der PHP-Funktion array_merge_recursive().

array_merge_recursive()

Zunächst, die Beschreibung der Funktion aus der Dokumentation:

array_merge_recursive() merges the elements of one or more arrays together so that the values of one are appended to the end of the previous one. It returns the resulting array.

If the input arrays have the same string keys, then the values for these keys are merged together into an array, and this is done recursively, so that if one of the values is an array itself, the function will merge it with a corresponding entry in another array too. If, however, the arrays have the same numeric key, the later value will not overwrite the original value, but will be appended.

Beachtenswert ist hier der letzte Satz, insbesondere „same numeric key“ und „same numeric key“.

Was ist hier so seltsam bzw. fehlerhaft?
Weiterlesen»

TYPO3 – Suche erweitern

Wer des öfteren mal die Funktionalität von TYPO3 mit eigenen Extensions erweitert, wird des Öfteren auf das Problem stoßen, dass bei der Erweiterung von Tabellen oder beim anlegen von Extension-spezifischen Datenbanktabellen bei der hauseigenen Suche außen vor bleiben.
Hier ist es sinnvoll, der Suche mitzuteilen, es möge doch bei der Suche auch zusätzliche Felder berücksichtigen. Dies lässt sich einfach und – im Gegensatz zu IF-Abfragen – einfach über TypoScript lösen.

Um der Suche die neuen Datenbank-Tabellen und/oder Felder mitzuteilen, geht man folgendermaßen vor.

Standard-Wert für "Überschriften und Schlagwörter": 
tt_content.search.30.dataArray.20.valueArray.10.value = pages.title-subtitle-keywords-description
Standard-Wert für "Seiteninhalt": 
tt_content.search.30.dataArray.20.valueArray.20.value = pages.title-subtitle-keywords-description : tt_content.header-bodytext-imagecaption

Zur neuen Definition leert man diese zuerst:

tt_content.search.30.dataArray.20.valueArray.10.value >
tt_content.search.30.dataArray.20.valueArray.20.value >

Danach definiert man den Wert neu indem man dem Standard die jeweiligen Felder anhängt:

tt_content.search.30.dataArray.20.valueArray.10.value = pages.title-subtitle-keywords-description-[zusätzliche Werte in der Tabelle "pages"]:[eine zusätzliche Tabelle]-[zusätzliche Felder dieser Tabelle]
tt_content.search.30.dataArray.20.valueArray.20.value = pages.title-subtitle-keywords-description:tt_content.header-bodytext-imagecaption-[zusätzliche Werte in der Tabelle "pages"] : [eine zusätzliche Tabelle]-[zusätzliche Felder dieser Tabelle]

Damit wird auch der Mechanismus klar, wie die zu durchsuchenden Felder definiert werden. Tabellen werden mit Doppelpunkt getrennt, die in der jeweiligen Tabelle zu durchsuchenden Spalten werden mit Dashes („-„) angehängt.

Abschließend muss man die Felder noch als zulässige Suchfelder definieren:

tt_content.search.20.allowedCols = [sämtliche Felder, die als Suchfelder definiert wurden, müssen hier im selben Schema eingetragen werden]

Zusätzlich zur Erweiterung der vorhandenen Filter („Überschriften und Schlagwörter“ und „Seiteninhalt“) ist es ebenso möglich, zusätzliche Filter einzufügen. Dazu fügt man dem Array

tt_content.search.30.dataArray.20.valueArray

einfach ein neues Element hinzu:

tt_content.search.30.dataArray.20.valueArray.30{
    label = Eine neue Option im Selectfeld
    value = [die mit dieser Option zu durchsuchenden Datenbank-Tabellen und Felder, Schema identisch]
}

Natürlich kann man analog auch Optionen entfernen.