Mehrere Presets für CKeditor verwenden

Um für ein Inputfeld ein von der Standardvorlage abweichendes RTE Preset zu verwenden, muss man wie folgt vorgehen:

 

Zunächst wird das Preset als .yaml Datei im Verzeichnis Configuration/RTE/ angelegt (in diesem Beispiel Custom.yaml). Hier kann als Vorlage zunächst die Default.yaml kopiert werden.

In ext_localconf.php wird nun eine Bezeichnung für das neue Preset definiert:

$GLOBALS['TYPO3_CONF_VARS']['RTE']['Presets']['custom'] = 'EXT:vendor_namespace/Configuration/RTE/Custom.yaml';

Um dieses Preset per TCA einem Inputfeld zuweisen zu können, muss in der RTE.tsconfig unter Configuration/TsConfig/Page/ die eben gewählte Bezeichnung einem im TCA verfügbaren Wert zugeordnet werden:

RTE {
  custom {
    preset = custom
  }
}

Sollte hier die Standardvorlage per default gesetzt sein, muss diese zwingend entfernet werden, da zusätzlich angelegte Presets sonst ignoriert werden.

Die Standardvorlage muss dann stattdessen ebenfalls über die ext_localconf.php gesetzt werden:

$GLOBALS['TYPO3_CONF_VARS']['RTE']['Presets']['default'] = 'EXT:vendor_namespace/Configuration/RTE/Default.yaml'

Zuletzt muss dem Inputfeld im Bereich config das eben definierte Preset zugewiesen werden:

'config' => [
  'richtextConfiguration' => 'custom'
],

Das neue Preset kann jetzt nach Belieben bearbeitet werden, eine Liste der konfigurierbaren Optionen findet man hier: https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_config.html

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

Mac Firefox vs. Chrome

Im Screenshot haben wir einmal das Problem, dass der Firefox die Schriften anders darstellt als im Chrome.

1. Font-Smoothing

body {
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
font-smoothing: antialiased;
}

Firefox benötigt an dieser Stelle den Wert grayscale statt antialiased.

 

2. Inputfelder

Inputfelder werden im Firefox um 2px höher dargestellt als im Chrome. Dies ist nicht unbedingt ein offensichtliches Problem aber bei Fieldsets mit Hintergrund, welche nebeneinander platziert sind, wird es einen Versatz geben.

Dieses Problem konnten wir wie folgt lösen:

input{
margin-top:-2px;
line-height:34px;
}

Die line-height muss natürlich entsprechend angepasst werden.

Reports – Remaining updates

Im Reports-Modul stieß ich letzens auf eine Meldung, die mich verwunderte:

„This installation is not configured for the TYPO3 version it is running.“

 

2016-02-04 15-28-09

Die TYPO3-Instanz war jedoch eine frisch aufgesetzte Installation…

Bei weitergehender Analyse, wie das Modul hierauf kommt, fand sich rasch die Ursache: die Datenbankstruktur stimmte nicht mit den Erwartungen/der hinterlegten Definitionen überein. Im Installtool unter Important actions findet sich der Database analyzer, der nähere Infos liefert.

Dubletten-Ansicht für Website-Benutzer

Wenn in größeren (aber auch generell) fe_users-Tabellen eines TYPO3 Dubletten vorhanden sind (was eigentlich nicht passieren dürfte*), kommt das Indexmanagement des mysql sehr schnell an seine Lastgrenzen.
Wenn dann gejointe Abfragen gestartet werden, gibt es einen erheblichen Performance-Unterschied wenn auch nur eine einzige Dublette im username vorhanden ist.
 
Um diese schnell finden zu können, kann man sich einfach die unten folgenden VIEWS in seine Datenbank packen (einfach im SQL-Feld des phpmyadmin abfeuern) und hat sofort eine wunderbare Übersicht über Dubletten.
Da VIEWS nur Ansichten sind, brauchen sie „keinen“ Speicherplatz und fressen auch sonst kein Brot 😉

  • Die VIEW „fe_users_dupes_witherrors_list“ stellt alle Dubletten dar, welche sogar aus Sicht von TYPO3 selbst fehlerhaft sind.
  • Die VIEW „fe_users_dupes_list“ stellt alle Dubletten dar, welche aus Sicht von TYPO3 fehlerhaft sind, aber zusätzlich auch alle die bei oben genannten Abfragen die Performance signifikant in den Keller ziehen.

Wenn man also ein sauberes TYPO3 haben möchte, welches noch dazu in der Performance keine künstlichen Bremsen im mysql haben soll, sollte also dafür sorgen das diese VIEWS immer 0 Datensätze als ergebnis liefern!

CREATE OR REPLACE VIEW `fe_users_dupes` AS
SELECT COUNT(`uid`) AS `Zeilen`,`username`,`pid`
FROM `fe_users`
GROUP BY `username`,`pid`
HAVING COUNT(`uid`)>1
ORDER BY `Zeilen` DESC
;


CREATE OR REPLACE VIEW `fe_users_dupes_list` AS
SELECT
`fe_users_dupes`.`Zeilen`,
`fe_users`.*
FROM `fe_users_dupes`
LEFT JOIN `fe_users`
ON `fe_users_dupes`.`username`=`fe_users`.`username`
;


CREATE OR REPLACE VIEW `fe_users_dupes_witherrors` AS
SELECT COUNT(`uid`) AS `Zeilen`,`username`
FROM `fe_users`
GROUP BY `username`,`pid`,`disable`,`deleted`
HAVING COUNT(`uid`)>1
ORDER BY `Zeilen` DESC
;


CREATE OR REPLACE VIEW `fe_users_dupes_witherrors_list` AS
SELECT
`fe_users_dupes_witherrors`.`Zeilen`,
`fe_users`.*
FROM `fe_users_dupes_witherrors`
LEFT JOIN `fe_users`
ON `fe_users_dupes_witherrors`.`username`=`fe_users`.`username`
;

* Das darf schon vorkommen. FE-User sind nur innerhalb ihrer Seite eindeutig (=> uniqueInPid: „Requires the field to be unique for the current PID (among other records on the same page). (Evaluated on the server only).“). Sofern FE-User aber am TCA/TYPO3 vorbei angelegt werden (z.B. Import-Routinen), greift diese Evaluierung nicht (weil eben nicht direkt in der Datenbank die Bedingung festgenagelt ist, sondern „nur“ im TCA).