Ein Blog von netzhaut.de

0

Fehler 500 mit TYPO3 beim Versenden von E-Mails

TYPO3 (zumindest bis zur Version 4.3.3) hat einen bekannten, nicht geschlossenen Bug der – je nach Serverkonfiguration – eine weiße Seite oder einen 500 Servererror liefert. Der Fehler tritt auf, wenn PHP mit Suhosin als fastCGI installiert ist, was allerdings mittlerweile sehr üblich ist. Hier ist der Fehler nochmal näher beschrieben: http://bugs.typo3.org/view.php?id=13701 Abhilfe schafft das auskommentieren der entsprechenden ini_set Zeile in t3lib/class.t3lib_htmlmail.php Mit einem Texteditor, oder z.B. wie folgt: sed -i ’s,@ini_set\(\’sendmail_from,//@ini_set\(\’sendmail_from,1′ t3lib/class.t3lib_htmlmail.php Ein Patch zum sauberen Fixen wurde im Zuge des RFC #13701 an die Core-Liste versandt, stieß aber auf wenig Interesse bzw. Zustimmung, sodass er nicht in den...

0

Clustered LVM auf Debian Lenny ohne RHCS

Die Debian Pakete des clvmd werden ueblicherweise gegen die RHEL Cluster Suite gebaut. Nachdem fuer die RHCS etliche Tools und umstaendliche Konfigurationen notwendig sind und generell nur ein Lockmanager gebraucht wird, bietet sich an openAIS als Lockmanager einzusetzen. Dieser wird in den Repositories angeboten, allerdings ist der clvmd aus den Repositories nicht dagegen gebaut. Ergo wird ein eigenes clvm Paket benoetigt – und wie folgt gebaut: apt-get install dpkg-dev apt-get build-dep clvm apt-get install libopenais-dev cd /usr/local/src/ apt-get source clvm In den Quellen muss ein wenig umgebaut werden: rm lvm2-2.02.39/debian/clvm.init wget -O lvm2-2.02.39/debian/clvm.init https://wissen.netzhaut.de/wp-content/uploads/2010/05/clvm.init chmod 644 lvm2-2.02.39/debian/clvm.init rm lvm2-2.02.39/debian/control wget...

0

wraps sind (k)ein Fluch

wraps bzw. stdWraps finden sich in TYPO3 an vielen Stellen. Manchmal sind sie Fluch, manchmal Segen. wrap-Dschungel im TMENU Immer wieder kommt es vor, dass gerade in Menüs in speziellen Fällen an eine bestimmte Stelle etwas hinzugefügt werden muss – sei es ein Klassenname, ein Icon,…. Oft stellt sich dann die Frage: Welcher Wrap ist dafür geeignet? Wie bleibt mein HTML-Code weiterhin semantisch und syntaktisch korrekt? Und wozu gibt es eigentlich dermaßen viele Wraps und Einfüge-Möglichkeiten in TMENU-Objekten??? Nachfolgend eine kleine Übersicht, die in einem Pseudocode lediglich die Verschachtelung der Wraps und weiteren Möglichkeiten von TS veranschaulichen soll: <wrapItemAndSub> <allWrap>...

0

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: Caching in Extensions http://danosipov.com/blog/?p=322 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‘]...

0

Extbase & Fluid

Die Basis für Extensions in TYPO3 v5 wird das PHP-Framework FLOW3 und die Template-Engine Fluid bilden. Daher sollten langsam aber sicher Extension aufwärstkompartibel programmiert werden. Seit TYPO3 4.3 stehen mit den Extensions extbase und fluid die passenden Rahmenbedingungen bereit. Lesenswertes und weiterführende Infos: Extbase MVC Framework http://forge.typo3.org/wiki/typo3v4-mvc/Collection_of_Documentation Extbase-Dokumentation (130 Seiten) http://www.mittwald.de/extbase-dokumentation/

5

Server mit memcached, php-memcache und aktiviertem TYPO3 (>4.3.0) Caching Framework

memcached ist perfekt zum cachen eigener Inhalte. Damit der Server damit ausgeruestet ist: apt-get install memcached Ist ein Server mit mehr als 2 Kernen ausgestattet, sollte das threaded Paket installiert. Der memcached sollte den freien RAM vollstaendig ausnutzen (nicht ueberbuchen, damit’s nicht ins SWAP geht). Die Speichermenge kann in /etc/memcached.conf eingestellt werden. PHP kann eine API anbieten (die Applikationen muessen sich aber schon selbstaendig um die Verwendung und Organisation des Caches kuemmern: z.B. TYPO3 Extensions koennen vom TYPO3 Core Caching Framework via memcache profitieren ) Um die PHP Erweiterung zu installieren: apt-get install php5-dev pecl install memcache-3.0.6 Ideale PHP Werte...

1

eaccelerator best practice

Vernuenftige Einstellungen fuer den eaccelerator in der php.ini /etc/php5/conf.d/eaccelerator.ini … sollte enthalten: zend_extension=“/usr/lib/php5/20060613/eaccelerator.so“ eaccelerator.shm_size=“64″ eaccelerator.enable=“1″ eaccelerator.optimizer=“1″ eaccelerator.check_mtime=“1″ eaccelerator.debug=“0″ eaccelerator.filter=““ eaccelerator.shm_max=“0″ eaccelerator.shm_ttl=“0″ eaccelerator.shm_prune_period=“0″ eaccelerator.shm_only=“1″ eaccelerator.compress=“1″ eaccelerator.compress_level=“5″ Wird check_mtime auf 0 gesetzt, beschleunigt der Cache noch deutlich schneller, allerdings finden updates erst mit sehr deutlicher Verzoegerung statt -> nix fuer CMS

0

eaccelerator update

Wird PHP aktualisiert und ist kein geeignetes re2c (fast nie) verfuegbar, kann in der Regel PHP nicht mehr starten, bzw. verursacht haessliche Fehler. Abhilfe schafft, den eaccelerator neu zu kompilieren: /etc/init.d/apache2 stop kill -9 `pidof php5-cgi` cd /usr/local/src/eaccelerator-0.9* make clean phpize ./configure –enable-eaccelerator –without-eaccelerator-use-inode make make install /etc/init.d/apache2 start