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.

TYPO3 Migration – Vorbereitungshelfer

Vermutlich jeder kennt es: ein etwas angestaubtes TYPO3 soll auf Vordermann gebracht werden. Sei es, dass „nur“ ein Core-Upgrade erfolgen soll, oder gleich ein ganzer Relaunch samt TYPO3-Core-Upgrade – aber mit Beibehaltung der Inhalte. In der Datenbank zeigen sich hunderte Contentelemente und Seiten; zig Extensions sind installiert, manche nicht (mehr) installiert, aber da; … und dokumentiert ist auch nichts oder nicht viel, warum die TYPO3-Instanz so ist, wie sie jetzt ist.

Welche Extensions sind überhaupt (noch) im Einsatz? Welche Contentelemente werden genutzt? Was muss bei einem Upgrade alles beachtet werden respektive nach dem Upgrade wieder laufen bzw. weiterhin möglich sein?

Im TER stieß ich heute auch eine Extension gefunden, die hierzu ein wenig Überblick verschaffen will:
Useful informations in the reports module

Über Erfahrungen und Kommentare würde ich mich freuen…

Dokumentation von Extensions

RTFM – wenn denn wirklich eines da wäre… Viel zu oft trifft man auf TYPO3-Extensions – auch eigene – deren Dokumentation mit etwas Glück mager ausgefallen ist, oft aber schlicht nicht existiert. Dies ist ärgerlich, weil man dadurch im TER nur schwer abschätzen kann, ob eine vorhandene Extension die gesuchte Funktionalität bietet, und weil bei individuellen (Kunden-)Extensions nach gewisser Zeit oft Kollegen (und man selbst) auch nicht mehr so genau weiß, was die Extension tut, wie sie es tut oder warum sie es so tut.
Aber warum dokumentieren wir so wenig? Mit ein paar wenigen Schritten und mit Vorlagen erleichtern wir uns selbst, unseren Kollegen und der Community das Leben. Also auf geht’s!

In „How typo3.org works“ beschreibt Kasper Automatismen rund um die TYPO3-Plattform incl. TER. Uns interessiert hierbei insbesondere der Abschnitt „1.3. Writing documentation for TYPO3“. Dort wird erklärt, wie aus einem einfachen OpenOffice-Manual die Online-Ansichten der Manuals entstehen, und warum die Struktur und Formatierung dabei entscheidend ist.
Ein Documentation template für korrekt formatierte Manuals mit zahlreichen Hinweisen steht im TER bereit.

Es ist wirklich kein Hexenwerk. Packen wir also mal wieder unseren inneren Schweinehund, und dokumentieren unsere Extensions.

Links:

Scheduler in eigenen Extensions nutzen

Benni (Release Manager, TYPO3 4.4) hat in seinem Blog einen Artikel verfasst, um uns allen das Erstellen von Tasks für den neuen Scheduler (seit TYPO3 4.3) zu ermöglichen. Damit sollten irgendwelche händischen Cronjobs und vielleicht auch CLI-Skripte der Vergangenheit angehören.
Update 2012-04-26: Der Artikel von Benni existiert leider nicht mehr, jedoch findet sich auch bei Stefan im Blog ein Tutorial.

Achtung!

Der Scheduler (bzw. genauer der Autoloader) scheint Probleme zu haben, wenn sich eine Extension im user_-Namespace befindet (obgleich das Extensions tun sollten, wenn sie nur für eine einzelne Installation erstellt sind).

CSH – Context Sensitive Help für additionalFields

Um die eigenen Felder etwas verständlicher zu machen, lassen sich Details via CSH einbinden. Hierzu sind zwei Schritte nötig:

locallang_csh*.xml anlegen

Zum Beispiel für das Feld example

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3locallang>
    <meta type="array">
        <description>Contents of scheduler csh</description>
        <type>CSH</type>
        <csh_table>_MOD_tools_txschedulerM1</csh_table>
        <fileId>EXT:scheduler/mod1/locallang_csh_scheduler.xml</fileId>
        <labelContext type="array"></labelContext>
    </meta>
    <data type="array">
        <languageKey index="default" type="array">
            <label index="example.alttitle">Title</label>
            <label index="example.description">Short Description</label>
            <label index="example.details">Details</label>
        </languageKey>
    </data>
</T3locallang>

In ext_tables.php die Datei bekanntgeben:

t3lib_extMgm::addLLrefForTCAdescr('_MOD_tools_txschedulerM1', 'EXT:' . $_EXTKEY . '/locallang_csh.xml');

Links

Edit: Aufruf des Schedulers in der crontab ergaenzt.

# crontab -l -u [WEB BENUTZER]
# m h  dom mon dow   command

*/2 * * * *	/var/www/[PFAD ZUM WEB]/htdocs/typo3/cli_dispatch.phpsh scheduler 2>/dev/null >/dev/null

Caching Framework in Extensions

Extensions sollten um horizontal zu skalieren, Caches nicht in eigens gebauten $_SESSION Arrays oder Temporaeren SQL Tabellen halten, sondern das ab TYPO3 4.3.0 eingebaute und ab 4.3.1 vollstaendig umgesetzte Caching Framework (ein Backport aus der FLOW3 Entwicklung) verwenden.

Ein guter Artikel ist:

Bei der Entwicklung der Extensions ist natuerlich darauf zu achten, dass diese in der Form auch erst ab 4.3.1 korrekt arbeiten, und auf aelteren Installationen nicht funktionieren werden.

In kurzen Auszuegen:
In die ext_localconf.php folgendes hinzufuegen, wenn Memcached verwendet werden soll:

// If cache is not already defined, define it
if (!is_array($TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['my_extension'])) {
   $TYPO3_CONF_VARS['SYS']['caching'] ['cacheConfigurations']['my_extension'] = array(
      'backend' => 't3lib_cache_backend_MemcachedBackend', 'options' => array( 'servers' => array('localhost:11211'), ))
   );
}

In der Extension muss das cache Object erzeugt und initialisiert werden:

if (TYPO3_UseCachingFramework) {
   // Create the cache
   try {
      $GLOBALS['typo3CacheFactory']->create(
         'my_extension',
         't3lib_cache_frontend_VariableFrontend',
         $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['my_extension']['backend'],
         $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['my_extension']['options']
      );
   } catch(t3lib_cache_exception_DuplicateIdentifier $e) {
      // do nothing, the cache already exists
   }
   // Initialize the cache
   try {
      $this->cache = $GLOBALS['typo3CacheManager']->getCache(
         'my_extension'
      );
   } catch(t3lib_cache_exception_NoSuchCache $e) {
      // Unable to load
   }
}

Um jetzt mit dem Cache arbeiten zu koennen sind folgende Methoden vorhanden:

$this->cache->has($id);
$this->cache->get($id);
$this->cache->set($id, $content, $tags, $lifetime);

Um id, content, tags und lifetime muss man sich selber kuemmern…

Bei MemcacheBackend gilt zu beachten: Idealerweise keine $id laenger als 255 Byte und idealerweise keinen $content mit mehr als 1MByte … das TYPO3 Caching Framework bricht diese Grenzwerte zwar auf, allerdings ist die Performance dann so im Keller, dass man den Zwischenspeicher auch gleich auf Pergament schreiben kann.