Caching Framework: automatisch Cache leeren bei Datensatzänderung

Das Caching Framework lässt sich gut verwenden, um aufwändig generierte/abgefragte Daten zur Wiederverwendung schneller parat zu haben. Die prinzipielle Funktionsweise haben wir in „Caching Framework nutzen“ erklärt und findet sich auch in der Doku sowie in zahlreichen anderen Blogs.
Was aber oftmals fehlt: wie aktualisiert man den Cache bzw. invalidert ihn bei Veränderung der Daten?

Häufig hängt der Inhalt des Caches von Datensätzen ab. D.h. der Cache-Inhalt veraltet, wenn sich ein Datensatz verändert. Und damit ist auch der Ansatzpunkt für die Invalidierung klar: der processDatamap_afterDatabaseOperations-Hook im DataHandler. Er wird immer nach Datenbankoperationen („new“ bzw. „update“) aufgerufen und bekommt auch den Taballennamen mit übergeben. Somit ist es recht einfach, die eigenen Datensätze zu erkennen und auf die Veränderung zu reagieren:

EXT:my_extension/Classes/Hooks/DataHandler.php:

<?php
namespace Netzhaut\MyExtension\Hooks;

use TYPO3\CMS\Core\Cache\CacheManager;
use TYPO3\CMS\Core\Utility\GeneralUtility;

class DataHandler
{
    public function processDatamap_afterDatabaseOperations($status, $tableName, $recordId, array $databaseData, \TYPO3\CMS\Core\DataHandling\DataHandler $dataHandler)
    {
        if ($tableName === 'tx_myextension_domain_model_example') {
            $cache = GeneralUtility::makeInstance(CacheManager::class)->getCache('myCache');
            $cache->flushByTag('tag_123');
        }
    }
}

Dann noch am Hook registrieren, und fertig:

EXT:my_extension/ext_localconf.php

$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processDatamapClass']['myextension_clearcfcache'] = 'Netzhaut\\MyExtension\\Hooks\\DataHandler';

Links

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»