Heute: TYPO3 Version 4.5 (im Download)

Die TYPO3 4.5 Stable wurde soeben veröffentlicht.

Habe bei mir bereits aktualisiert. Keine Probleme, Sache von maximal 15 Minuten, lohnt sich.

Upgrade Schnellanleitung (von 4.4.x auf 4.5):

1. Backup des derzeitigen Systems erstellen (Sources + Database Dump).
Mit Plesk geht das ganz unkompliziert mit nur einem Klick: Plesk Backend => Tools und Dienstprogramme => Backup-Manager => Backup erstellen => Inhalt: Serverkonfiguration und Inhalt => Backup starten (hier am Beispiel von Plesk 10.0.1)

2. Die neuen TYPO3 Core Dateien holen, am Besten direkt vom Server oder VDS aus über eine SSH Verbindung:
cd /tmp

wget dl1.typo3.org/TYPO3_4.5.0/typo3_src-4.5.0.tar.gz

Wer mehrere TYPO3-Installation betreut oder mehr als einen FTP-Zugang auf seinen Server hat (SSH), sollte bei Schritt 4 nur Softlinks auf die TYPO3-Sourcen legen; das spart viel Arbeit und Ärger. Außerdem liegen dann die TYPO3-Sourcen nur einmal auf dem Server und müssen nicht mitkopiert und gesichert werden.

Ein weiterer Vorteil ist, dass zwischen den Versionen in wenigen Sekunden geswitched werden kann und die Website damit mit keiner bzw. nur einer sehr kleinen Downtime aktualisiert werden kann.

Wie bei jedem TYPO3-Update sollte man auch verwendete Extensions ausführlich testen.

Viel Spaß mit TYPO3 4.5 LTS (Long Term Support)


Marc

Ergänzend zu Marc´s Bemerkung zu den Softlinks:

cd <mein TYPO3-Verzeichnis>
mv index.php index.php_old
rm typo3_src && ln -s ../typo3_src-4.5.0 typo3_src
rm t3lib && ln -s typo3_src/t3lib
rm typo3 && ln -s typo3_src/typo3
ln -s typo3_src/index.php

Bei meinem Upgrade ist es noch zu folgenden Fehlern gekommen:
Update Graphics, Using Sprites for sys_language Records:
TYPO3 Fatal Error: "Where" clause argument for UPDATE query was not a string in $this->UPDATEquery() !
Weiter liessen sich die Update/Delete des Database Compare nicht durchführen.
Ursache ist die Extension DBAL bugs.TYPO3.org
Als Workaround habe ich die Extension deaktiviert.

Bei der Gelegenheit habe ich noch die Extensions aktualisiert. Bei Static Info Tables hatte ich keine Schreibrechte für "Andere" in typo3conf\\ext\\static_info_tables und das Verzeichnis wurde nur teilweise modifiziert. Fehlermeldung:

PHP Fatal error: require_once() [[a href=\'function.require\']function.require[/a]]: Failed opening required \'/wurzel/typo3/typo3conf/ext/static_info_tables/class.tx_staticinfotables_div.php\' (include_path=\'.:/usr/share/pear/php5\') in /wurzel/typo3/typo3conf/temp_CACHED_ps7cd1_ext_localconf.php on line 929, referer: meine.domain.de/typo3/mod.php

Hi Markus, hi Lutz,

schöne Beiträge, Danke.

P.S.: Warum verwendet ihr statt den Softlinks nicht die TYPO3 Multidomain Funktion? So hat man alle TYPO3 Sites in einer TYPO3 Instanz laufen statt mehrere TYPO3 Instanzen gleichzeitig (und ist damit deutlich performanter weil weniger Serverlast). Gleichzeitig ist die redaktionelle Administration meiner Meinung auch übersichtlicher / einfacher.

Grüße,
Matthias

TYPO3 Multidomain nutze ich schon auch, aber für eine größere Seite und für meine Testseite habe ich extra Instanzen angelegt.
Zu dem Sprite-Generator habe ich nur wenige Informationen gefunden. Ist es richtig, dass er nur für das Backend gedacht ist?

TYPO3-Multidomain ist ein nettes Feature und wird auch von mir benutzt; ich habe aber auch mehrere (Dutzend) TYPO3-Instanzen, aus folgenden Gründen:

* Einfachere Trennung - unterschiedliche Kundenprojekte liegen bei mir niemals in einer Instanz; alles andere wäre eine de-facto-Gängelung der Kunden, niemals von mir wegzukommen. Und ich will ja mit Qualität überzeugen und nicht mit Zwang

* Inkompatibilität einiger weniger Extensions - man bekommt zwar auch in einer Multidomain so ziemlich alles zusammen zum Laufen, aber übersichtlicher wird\'s bei schwierigen Extensions damit nicht.

* saubere Trennung der Backups (v.a. Datenbank) und damit verbunden auch ein einfacheres Restore, falls mal bei der Redaktion was schiefgegangen ist.

* Einfache Trennung, wenn eine Instanz auf einen anderen Server umziehen soll - z.B. aus Performancegründen. Tarball, SQL-Dump und in wenigen Minuten läuft alles auf neuer Hardware.

* Saubere Trennung der Datenbanken, somit auch kein potentielles Sicherheitsproblem wegen evtl. falsch gesetzer Zugriffsrechte von verschiedenen Kunden.

* Einige Kunden möchten/brauchen Zugriff auf die TYPO3-Datenbank (z.B. via phpmyadmin). Spätestens dann ist\'s Zeit für eine eigene Instanz.

Serverlast ist bei vernünftiger Planung und Skalierung der Server eigentlich kein Problem - ob Multidomain oder nicht. Die sehr serverlastigen Domains laufen eh auf einem dedizierten Server, zur Not eben mit Load Balancing - ist mit TYPO3 ja alles machbar

Viele Grüße


Marc

Hallo Marc,

guter Beitrag!

Vor allem hast Du da einen sehr wichtigen Aspekt angesprochen: Kundenprojekte. Diese sollten natürlich auf gar keinen Fall in einer Instanz liegen!

Was aber meiner Meinung nach sinnvoll ist, ist es, die eigenen TYPO3 Projekte in einer Instanz (und einem Backend) zusammenzufassen. So sind u.a. z.B. ganz unkompliziert websiteübergreifende FE Logins möglich, domainübergreifende Tasks oder Daten sind gleich beisammen usw.

Allerdings ist das natürlich eher eine Geschmacksache und eine Frage des jeweiligen Einsatzschwerpunktes. Verschiedene Kunden würde ich z.B. auch niemals in eine TYPO3 Instanz hineinsetzen (oder gar in die Seitenreport Instanz...).
Insgesamt gibt es halt für beide Möglichkeiten jeweils Vorteile und Nachteile (darum setzen wir 3 ja eben auch beide Möglichkeiten ein - je nach Aufgabenschwerpunkt).

Da war mein Post aber auch wirklich etwas unglücklich formuliert... :laugh:

Beste Grüße,
Matthias

seitenreport schrieb:

guter Beitrag!

In der KB hat\'s noch Platz.