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).  

Grundkonfiguration von TYPO3 (Stand 2015)

Welche Konfiguration im Install-Tool TYPO3 geschmeidig auf unseren Servern laufen lässt, soll hier kurz erklärt werden. Die Default-Settings passen inzwischen sehr gut zu unserer Infrastruktur und unseren Erfahrungen, sodass kaum mehr Dinge zu verändern sind.

Weiterlesen»

Optimierte .htaccess für TYPO3

Über passende Regeln in der .htaccess-Datei wird die Website noch schöner, schneller und besser. Vor fast 5 Jahren hatten wir bereits im Beitrag Optimierte .htaccess fuer TYPO3 auf Apache2 von Stephan eine alternative .htaccess-Datei veröffentlicht. Die damals von TYPO3 mitgelieferte Version behandelte nur wenige Grundeinstellungen und war für den Produktivbetrieb eher suboptimal. Über die Jahre hat sich vieles getan und holte die Default-htaccess von TYPO3 auf. Ein Punkt von damals gilt aber auch noch heute

  • eine .htaccess wird mit jedem File-Hit geparst, besser wäre es natürlich die Einstellung direkt in der Apache Konfiguration der VirtualHosts vorzunehmen. Das scheitert aber vermutlich meist an entsprechenden Rechten.
  • Dadurch dass es geparst werden muss, sollte man die Datei klein halten, d.h. alle Kommentare entfernen.

Weiterlesen»

robots.txt für TYPO3

Suchmaschinen kann man an die Hand nehmen und ihnen gezielt seine Website zeigen bzw. an mancher Ecke vorbeiführen. Die robots.txt ist dabei eines der Hilfsmittel zur Führung.

Es gibt Ecken in TYPO3 und in der konkreten Website, die für Suchmaschinen inhaltlich irrelevant sind. Warum also sollte man das freundlichen Crawler nicht sagen? Diese werden dankbar sein, dass wir ihnen Arbeit ersparen – und wir sind froh, dass solch irrelevante Teile in keinem Suchindex auftauchen. Hierfür können via Allow gezielt auf Pfade hingewiesen werden, via Disallow hingegen gezielt ausgeschlossen werden.

Vorsicht: Die Angaben in der robots.txt stellen lediglich Bitten/Empfehlungen für Crawler dar. Ob sich ein Crawler tatsächlich dran hält, bleibt ihm überlassen. Echter Zugriffsschutz müsste ggf. anders umgesetzt werden (z.B. via .htaccess).

Eine gute Basis für solch eine robots.txt pflegt Oliver auf Github: robots.txt for TYPO3

Quellen:

robots.txt for TYPO3 (als PDF-Backup)

Chrome: Warnung vor unsicheren Ressourcen

Bildschirmfoto 2015-07-09 um 11.21.29Bei einer Website stießen wir kürzlich auf eine Warnung von Chrome (v 41), wie sie rechts zu sehen ist. Schnell war abgeklärt, dass keine „veraltete Kryptographie“ im Einsatz ist. Also nahmen wir den Teil „Diese Seite enthält jedoch andere, nicht sichere Ressourcen.“ unter die Lupe. Per Durchsicht im HTML-Quellcode konnten wir keine Resourcen-Einbindung mit „http://“-Quellen entdecken. Zur Sicherheit wurden sämtliche Javascripte und CSS-Dateien herausgenommen. Chrome meldete weiterhin seine Bedenken. Aus Clientsicht ließ sich nichts mehr erkennen. Wir guckten uns die Sache daher serverseitig an: welche Resourcen werden denn dort angefordert (nachdem wir externe Quellen ausschließen konnten)? Doch im access-Log tauchten zur Seiten-Anfragen via HTTPS auch nur Folgeanfragen via HTTPS auf. Nach und nach haben wir die Seite weiter minimalisiert – bis der „Schuldige“ gefunden war: ein Formular, das als action-URL einen http-URL enthielt.

Merke:
action-URLs sind zwar keine Resourcen, werden von Chrome aber offenbar als solche angesehen und ggf. bemängelt.

Danke für diese doch so aussagekräftige Fehlermeldung… 🙁