TYPO3

Eingebette Objekte (object, embed, iframe) im RTE von TYPO3

caticonslite_bm_alt

Standardmäßig ist es im Rich Text Editor (RTE) von TYPO3 nicht möglich eingebettete Objekte (z.B. Flickr-Stream, Vimeo– oder YouTube-Video) einzufügen. Abhängig von der Quelle erfolgt die Einbindung entweder mit den HTML-Tags object, param und embed, oder als iframe. Die folgende Konfiguration des RTE ist grundsätzlich über sämtliche Plug-ins hinweg gültig und funktioniert somit auch im RTE von tt_news, tx_news, usw.

Zuerst müssen die erforderlichen HTML-Tags zu den erlaubten Tags hinzugefügt werden – hierfür ergänzt man die RTE-Konfiguration im PageTS wie folgt:

RTE.default.proc {
	allowTags := addToList(object,param,embed,iframe)
	allowTagsOutside := addToList(object,embed,iframe)
	entryHTMLparser_db.allowTags < .allowTags
}

Tags die bei „allowTagsOutside“ angegeben werden, können auch außerhalb eines Block-Elements wie „p“ oder „div“ eingefügt werden.

Anschließend muss noch die Parser-Funktion des RTE im TypoScript-Setup angepasst werden: 

lib.parseFunc_RTE.allowTags := addToList(object,param,embed,iframe)

Installation von TYPO3 6.1 mit Git

caticonslite_bm_alt

TYPO3 verwendet bereits seit längerer Zeit (seit 1. März 2011 um genau zu sein) Git als Versionverwaltung (Version Control System – VCS). Aus diesem Grund bietet es sich an, auch für eigene TYPO3-Projekte Git einzusetzen, da sich daraus einige Vorteile ergeben, z.B. die Einbindung und somit einfache Aktualisierung des TYPO3-Core als Submodule.

1. Laden des „Dummy“-Archivs (in diesem Fall Version 6.1.1):

wget http://prdownloads.sourceforge.net/typo3/dummy-6.1.1.tar.gz?download

2. Entpacken und verschieben des „Dummy“-Archivs (in diesem Fall in den Ordner „public_html“):

tar xzf dummy-6.1.1.tar.gz?download
mv dummy-6.1.1 public_html

Das „Dummy“-Archiv wird nicht mehr benötigt und kann daher gelöscht werden.

3. Erstellen des Git-Repository (zuerst ins Verzeichnis wechseln):

cd public_html/
git init

4. Entfernen nicht benötigter Dateien/Symlinks (u.a. aus Sicherheitsgründen):

rm *.txt
rm typo3_src

5. TYPO3-Core („typo3_src“) als Git-Submodule einbinden:

git submodule add git://git.typo3.org/Packages/TYPO3.CMS.git typo3_src

6. Checkout von Core und dessen Submodules (Extbase, etc.) in der gewünschten Version (in diesem Fall 6.1.1):

cd typo3_src
git checkout tags/TYPO3_6-1-1
git submodule update --init --recursive
cd ..

Vorhandene Versionen können mit „git tag“ angezeigt werden.

7. Nur „Programmcode“ sollte ins Git-Repository, daher werden „Benutzerdaten“ (z.B. hochgeladene Bilder, Dokumente) und weitere für die Versionverwaltung nicht interessante Dateien/Ordner ausgenommen:

echo "# User
/fileadmin/
/uploads/
# Deprecation-Log
/typo3conf/deprecation*
# Enable Install Tool
/typo3conf/ENABLE_INSTALL_TOOL
# SQL
/typo3conf/*.sql
# Cache
/typo3conf/temp_CACHED*
/typo3conf/temp_fieldInfo.php
# Temp
/typo3temp/
" > .gitignore

8. Initial commit im CommitMessage-Format für TYPO3:

git add .
git commit -a -m "[TASK] initial commit"

Nun kann wie gewohnt mit Git gearbeitet werden.

AllowOverride MultiViews

caticonslite_bm_alt

Apache stellt mit dem Modul „mod_negotiation“ und der Option „MultiViews“ eine automatische Fehlerbehandlung zur Verfügung. Sollte der angeforderte URL nicht existieren, so wird nach Dateien mit dem selben Wortstamm gesucht. Das kann sich bei der Verwendung von „mod_rewrite“ negativ auswirken und zu einer falschen Auflösung von URLs führen. Um Probleme bei der Auflösung von URLs zu verhindern setzen CMS wie Drupal 7 oder TYPO3 NEOS die Option „Options -MultiViews“ in der .htaccess-Datei.

Ist „AllowOverride“ nicht korrekt gesetzt und erlaubt das Überschreiben der Option nicht, so resultiert dies in einem „Internal Server Error“ im Browser bzw. einem „[…]/.htaccess: Option MultiViews not allowed here“ in den Apache-Logs. In den seltensten Fällen möchte man das Überschreiben aller Optionen mit „AllowOverride All“ erlauben, sondern nur gezielt Freigaben hierfür erteilen. Dies kann man beispielsweise mit „AllowOverride AuthConfig FileInfo Indexes Limit Options=All,MultiViews“ erreichen.

PHP-Serverkonfigurationen im Performancetest

caticonslite_bm_alt

Ziel dieses Vergleichs war es, die performantesten PHP-Konfigurationen für Drupal, TYPO3 und WordPress festzustellen und daraus auf die im Allgemeineinsatz performanteste Konfiguration zu schließen. Getestet wurden die Standardinstallationspakete Drupal 7.16,  TYPO3 4.7 Government Package und WordPress 3.4.2 mit Apache Bench für einen Zeitraum von je 30 Sekunden (z.B. „ab -kc 250 -t 30 http://127.0.0.1/drupal/“). Um möglichst faire Bedingungen zu schaffen wurden die involvierten Software-Komponenten vor jedem Test neu gestartet (z.B. „/etc/init.d/nginx restart && /etc/init.d/php5-fpm restart“). Der Testinstanz waren vier Kerne eines E5649-Xeon-Prozessors, 16 GB RAM und zwei SATA-Festplatten im Hardware-RAID 1-Verbund exklusiv zugewiesen. Als Software wurden die Komponenten in ihrer Standardkonfiguration aus dem Debian Wheezy-Repository eingesetzt.

Folgende Konfigurationen wurden getestet:

  • apache2-mpm-prefork + libapache2-mod-fcgid
  • apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  • apache2-mpm-prefork + libapache2-mod-php5
  • apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  • apache2-mpm-prefork + libapache2-mod-suphp
  • apache2-mpm-prefork + libapache2-mod-suphp + php-apc
  • apache2-mpm-worker + libapache2-mod-fcgid
  • apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  • apache2-mpm-worker + libapache2-mod-suphp
  • apache2-mpm-worker + libapache2-mod-suphp + php-apc
  • nginx + php5-fpm
  • nginx + php5-fpm + php-apc

Die performantesten Konfigurationen für Drupal:

  1. 152,94 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  2. 147,12 Requests/s, 250 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  3. 146,68 Requests/s, 100 Concurrency: nginx + php5-fpm + php-apc
  4. 145,83 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  5. 132,43 Requests/s, 50 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  6. 130,92 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  7. 128,88 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc

Die performantesten Konfigurationen für TYPO3:

  1. 180,32 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  2. 179,99 Requests/s, 250 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  3. 173,87 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  4. 166,69 Requests/s, 50 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  5. 166,03 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  6. 163,55 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  7. 111,03 Requests/s, 100 Concurrency: nginx + php5-fpm + php-apc

Die performantesten Konfigurationen für WordPress:

  1. 57,75 Requests/s, 100 Concurrency: nginx + php5-fpm + php-apc
  2. 55,97 Requests/s, 250 Concurrency:  apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  3. 52,21 Requests/s, 50 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  4. 49,93 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  5. 48,99 Requests/s, 250 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  6. 48,09 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  7. 46,7 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc

Download aller Apache Bench-Ergebnisse und der Excel-Auswertung

Fazit:

Dass libapache2-mod-suphp im Vergleich zu den anderen Testkandidaten nicht gut abschneiden und APC die Performance enorm steigern wird, war bereits vor dem Test klar. Enttäuschend war in jedem Fall die Leistung von WordPress, welche auf fehlende Cachingmechanismen im Core zurückzuführen ist. Im allgemeinen Vergleich zeigte besonders libapache2-mod-fcgid bei hohen (250 Concurrency) und moderaten (50 Concurrency) Zugriffszahlen eine gute Performance. Als reiner Webserver mag nginx zwar schneller als Apache sein, im Zusammenspiel mit PHP konnte sich nginx gegen Apache aber nicht durchsetzen.

Mein (klarer) Favorit ist apache2-mpm-worker + libapache2-mod-fcgid + php-apc, wer einfachere Konfigurationen bevorzugt und bei dem Benutzerrechte keine Rolle spielen ist auch mit apache2-mpm-prefork + libapache2-mod-php5 + php-apc gut bedient.

Papierkorb für gelöschte Dateien

caticonslite_bm_alt

Vielen ist bekannt, dass TYPO3 einen Verlauf zum Wiederherstellen von gelöschten Seiten und Inhalten bietet. Dass für Dateien ein ähnliches Feature existiert wissen dagegen nur die wenigsten: Erstellt man unter „fileadmin“ einen Ordner namens „_recycler_“, so dient dieser ab sofort als Papierkorb für gelöschte Dateien. Außerdem ist es möglich in der kompletten Ordnerstruktur unter „fileadmin“ „_recycler_“-Ordner anzulegen, gelöschte Dateien werden daraufhin im in der Hierarchie nächstgelegenen Papierkorb abgelegt – das ist vor allem beim Einsatz von Benutzergruppen interessant.

1 2 3 4 5  nach oben