In der Regel sollen weder Administratoren noch Redakteure „live“ an neuen Seiten oder Artikeln arbeiten. Der Besucher soll die neuen Inhalte erst zu sehen bekommen, wenn sie fertig gestellt und im Frontend geprüft worden sind.

Hier kommt die Entwurfsarbeitsumgebung von TYPO3 ins Spiel. Im Seitenbaum lassen sich unter der Rubrik Benutzerwerkzeuge » Arbeitsumgebung beliebig viele eigene Entwurfsarbeitsumgebungen einrichten und bestimmten Benutzern oder Benutzergruppen zuordnen. So kann beispielsweise der Benutzergruppe „Redakteure“ ausschließlich das Arbeiten in der Entwurfsarbeitsumgebung gestattet werden und erst nach Freigabe durch das Lektorat und den Chefredakteuren erfolgt die Onlinestellung.

Nach dem Einrichten einer neuen Entwurfsarbeitsumgebung und der Zuordnung zu bestimmten Benutzern bzw. Benutzergruppen stellt sich folgendes Problem:
In der neuen Entwurfsarbeitsumgebung ist es nicht möglich, Medien wie PDFs, JPGs, GIFs in die Seiten zu integrieren, da der entsprechende Verzeichnisbaum für die Auswahl der Mediadaten fehlt.
Nehmen wir an, die Medien liegen im Standardverzeichnis:
fileadmin/user_upload/

Um eine Freigabe dieses Verzeichnisses in der Entwurfsarbeitsumgebung zu erreichen wird

[1] Ein neuer Datensatz erstellt
[2] Verzeichnisfreigaben ausgewählt

Die Bezeichnung der Freigabe kann frei gewählt werden.
Um die Freigabe von „fileadmin/user_upload/“ zu erreichen, wird unter „Pfad“ eingetragen:
user_upload/
und als Basis die relative Pfadangabe ausgewählt.

Abschließend muss der Arbeitsumgebung diese Verzeichnisfreigabe noch zugeordnet werden:

Gerade bei umfangreicheren Webprojekten hat dies den unerwünschten Nebeneffekt, dass im Seitenbaum (Pagetree) des TYPO3-Backends lange Benennungen angezeigt werden, die nicht unbedingt dazu angetan sind eine schnelle Übersichtlichkeit zu ermöglichen. Spätestens wenn die Redakteure sich darüber beschweren, ist es an der Zeit, über Alternativen nachzudenken.

Im Frontend navigiert man mit Hilfe der Navigationstitel durch die Webseite. Was also liegt näher, als auch im Backend-Seitenbaum statt der Dokumenttitel (title) die Navigationstitel (nav_title) anzuzeigen?

Bis TYPO3 4.1.x war das Problem nur durch Modifikationen am TYPO3-Core möglich. Eine entsprechende Lösung wurde von Thomas Hempel entwickelt:
http://bugs.typo3.org/
Der Aufwand für die Änderungen war allerdings verhältnismäßig hoch und im Falle eines Updates von TYPO3 war dieser Lösungsansatz nicht ideal.

Seit TYPO3 Version 4.2. ist alles wesentlich einfacher:
Eine einfache TypoScript-Codezeile in der User-TSconfig richtet es:

1
2
3

# Navigationstitel (nav_title) statt Seitentitel (title)
# im TYPO3-Backend
options.pageTree.showNavTitle = 1

Hinweis:
Wo findet man die User-TSconfig?
Die User-TSconfig findet sich unter
Admin-Werzeuge > Verwaltung > dort den Benutzer oder Benutzergruppe editieren und den Reiter „Optionen“ wählen. Der TypoScript-Eintrag erfolgt im Feld „TSconfig“.

Somit lässt sich die gewünschte Änderung sowohl für Benutzergruppen als auch einzelne Benutzer festlegen. Dies zeigt allerdings auch den Nachteil dieses Ansatzes:
In der Regel soll die Änderung global für alle Benutzer gelten. Werden Benutzer oder Benutzergruppen neu angelegt, darf der TS-Eintrag nicht vergessen werden.

Ausweg:
Eine entsprechende Codezeile in der localconf.php sorgt für eine globale Gültigkeit:

1
2
3

# Backend-Navigationsmenue: Navigationstitel statt Seitentitel anzeigen. 
# Einstellung fuer alle User der TYPO3-Instanz vornehmen:
t3lib_extMgm::addUserTSConfig('options.pageTree.showNavTitle = 1');

Weiterführende Informationen:
TYPO3-Dokumentation
Zero Seven

Suchmaschinen sind bestrebt, Suchenden möglichst hochwertige Suchergebnisse zu liefern. Selbst der Branchegigant Google kann es sich nicht leisten, irrelevante Suchergebnisse zurückzugeben, sonst schauen sich die Internetbenutzer bald nach alternativen Suchmaschinen um. Würde unter den ersten 10 Suchergebnissen mehrere Webseiten mit gleichem Textinhalt aufgelistet werden, so kann nicht von qualitativ hochwertigen Suchergebnissen gesprochen werden.

Daher werden Webseiten mit doppeltem Content aus den Suchergebnissen ausgeschlossen oder erst sehr weit hinten im Ranking angezeigt. Welche der gefundenen Websites mit doppeltem Content letztendlich vorne erscheint, hängt von der Stärke der jeweiligen Website ab: Wie gut ist ihr Pagerank? Wie viele Backlinks gibt es zu dieser Site? usw. Hier lassen sich die Suchmaschinenbetreiber nicht in die Karten schauen inwieweit welche Faktoren wie gewichtet werden.

Doppelter Content kann mehrere Ursachen haben:

1. Webseitenbetreiber übernehmen (oder weniger gewählt ausgedrückt: klauen) gute Texte von anderen Webportalen, um sie auf ihrer eigenen Webseite anzubieten. Dies geschieht entweder manuell durch copy&paste oder automatisiert durch Spambots.
2. Publizierung von Pressemitteilungen oder massenhaftes Publizieren desselben Artikels in mehreren Artikelverzeichnissen.
3. Der Webmaster schaltet verschiedene Domains/Subdomains auf dieselbe Webseite oder aber die Inhalte sind versehentlich unter verschiedenen URLs auffindbar.

zu 1) Übernahme von Content durch Dritte
Dieses Thema wird unter Betroffenen leidenschaftlich diskutiert. Konsens besteht darin, dass Contentklau Diebstahl am geistigen Eigentum ist. Vor allem, wenn ein Text 1:1 übernommen wird. Websites, die den eigenen Text kurzerhand übernommen haben, lassen sich leicht ausfindig machen, indem repräsentative Textpassagen in Anführungsstrichen in das Suchfeld einer Suchmaschine eingegeben und ggf. zurückgegebene Ergebnisse geprüft werden. Alternativ bieten sich Tool wie Copyscape an.

Werden Webseiten gefunden, die sich der eigenen Textinhalte bedienen, scheiden sich die Geister über das weitere Vorgehen. Mancher schwört darauf, dem „Drittanbieter“ des eigenen Webtextes eine freundliche E-Mail zu schreiben mit der Bitte, den Text zu entnehmen oder umzuformulieren und mit Quellangabe zu versehen. Andere hingegen bedanken sich höflich für das Interesse an dem eigenen Text und schicken schon einmal eine Rechnung für dessen Nutzung mit. Wieder andere leiten rechtliche Schritte ein und verklagen den Contentdieb.

Wie bereits erwähnt kann Content manuell per copy and paste oder auch automatisiert „übernommen“ werden, z.B. durch Spambots. Diese lassen sich durch entsprechende Einträge in der .htaccess-Datei blockieren:

order deny,allow
deny from IP1
deny from IP2
deny from .url.de
allow from all

wobei IP1, IP2,… die IP des Spambots ist und .url.de die jeweilige URL der Website, die ungefragt und ungewollt Content von der eigenen Webpräsenz übernimmt.

Eine .htaccess-Datei lässt sich sehr einfach anlegen. Dazu wird eine Textdatei, z.B. mit Notepad erstellt und .htaccess genannt. Unter Windows ist diese Benennung nicht ohne weiteres möglich. Das Problem lässt sich dadurch umgehen, dass man die Datei htaccess.txt nennt, per FTP auf den Server lädt, dort in .htaccess umbenennt und von dort wieder zurück auf die eigene Festplatte kopiert.

Der Aufwand, nach und nach alle IPs bzw. URLs von Spambots in die .htaccess-Datei einzutragen, kann allerdings sehr groß werden. Hilfe bietet ein nettes PHP-Script von Bot Trap.

zu 3) Die Website ist unter verschiedenen URLs aufrufbar
Ein vermeidbarer Fehler ist, dass Webmaster absichtlich oder unwissentlich selbst für den doppelten Content sorgen. Vermieden werden sollte natürlich, mehrere URls auf denselben Webseiteninhalt zu schalten. Wer seine Domains www.meineDomain1.de, www.meineDomain2.de, www.meineDomain3.de auf denselben Webseiteninhalt leitet, braucht sich über das Auftreten von doppeltem Content nicht zu wundern.
Ein häufiger Fehler ist allerdings auch, dass die Website sowohl unter www.meineDomain.de, als auch unter http://meineDomain.de erreichbar ist (also einmal mit „www“ und einmal ohne). Dieses Problem lässt sich umgehen, indem eine mod_rewrite-Anweisung in die .htaccess-Datei geschrieben wird.
mod_rewrite erfordert entsprechende serverseitige Unterstützung durch das Apache-Modul.
Mit nachfolgendem Eintrag werden die URLs von (z.B.) http://meineDomain.de oder meineDomain.de automatisch auf http://www.meineDomain.de umgeschaltet und der Content ist nur noch unter dieser URL erreichbar:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^meineDomain.de$ [NC]
RewriteRule ^(.*) http://www.meineDomain.de/$1 [L,R=301]

Doppelter Content kann auch auf anderem Wege entstehen. Indem z.B. der Inhalt der Website zusätzlich in druckbarer Form zur Verfügung gestellt wird und damit einmal in der normalen Webseitenansicht und einmal in der Druckversion vorliegt (www.meineDomain.de/interessantes.html, www.meineDomain/interessantes/print.html).

Auch andere Möglichkeiten sind denkbar: So wurde bei einem Kunden unter TYPO3 die Möglichkeit der Schriftgrößenänderung angeboten. Der Besucher kann die Schriftgröße „Normal“, „Größer“ und „Sehr groß“ auswählen. Eingesetzt wurde realURL zum Umschreiben der URL in Besucher- und suchmaschinenfreundliche URLs und mitgegeben wurde die Fontgröße über die URL:

- www.meineDomain.de/verzeichnis1/name.html (normale Schriftgröße)
- www.meineDomain.de/fs0/verzeichnis1/name.html (normale Schriftgröße)
- www.meineDomain.de/fs1/verzeichnis1/name.html (größere Schriftgröße)
- www.meineDomain.de/fs2/verzeichnis1/name.html (sehr große Schriftgröße)

Anmerkung: Eine Anleitung, wie sich Schriftgrößen mit CSS und TYPO3 auswählen lassen, ist nicht Gegenstand dieses Artikels.

Je nach Variable (fs=0, fs=1, fs=2) wird ein anderes CSS-Stylesheet mit entsprechender Fontgrößeneinstellung geladen.
Suchmaschinen haben dadurch den Content unter mehreren URLs gefunden. Unsere Aufgabe war, die Website so zu optimieren, dass kein doppelter Content mehr gefunden wird.
Ausweg: Die URLs mit fs0, fs1, fs2 werden aus der Indizierung ausgeschlossen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#Webseiten ohne "fs" in der URL
[globalVar = GP:Fsize<1]
  page.meta.robots = index,follow
[END]
#fs0 in URL
[globalVar = GP:Fsize=0]
  page.meta.robots = noindex,nofollow
[END]
#fs1 in URL
[globalVar = GP:Fsize=1]
  page.meta.robots = noindex,nofollow
[END]
#fs2 in URL
[globalVar = GP:Fsize=2]
  page.meta.robots = noindex,nofollow
[END]

Der Vollständigkeit halber:
Dabei entspricht das „fs“ aus der URL:
fs0: Fsize=0, fs1: Fsize=1, fs2: Fsize=2.
Dies lässt sich durch eine Ergänzung in der localconf.php erreichen:

1
2
3
4
5
6
7
8
9
10
11
12
13

$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'] = array(
  'preVars' => array(
                      array(
                             'GETvar' => 'Fsize',
                             'valueMap' => array(
                             'fs0' => '0',
                             'fs1' => '1',
                             'fs2'=> '2',
                           ),
                           'noMatch' => 'bypass',
                           ),
                    ),
);

Stattdessen hätten wir aber gerne einen anderen Aufbau und zusätzliche Spalten in folgender Form:

Dafür ist die Datei typo3conf/extTables.php zu editieren und es ist nachstehender Eintrag vorzunehmen:

1
2
3
4
5
6
7
8
9
10
11
12

t3lib_extMgm::addPageTSConfig('
    mod.SHARED.colPos_list = 0,1,2,3,4,5
'); 
 
$TCA['tt_content']['columns']['colPos']['config']['items'] = array (
    '0' => array ('Normal||Normal||||||||','0'),
    '1' => array ('Links||Links||||||||','1'),
    '2' => array ('Rechts||Rechts||||||||','2'),
    '3' => array ('Rand||Rand||||||||','3'),
    '4' => array ('ContentColLinks||ContentColLinks||||||||','4'),
    '5' => array ('ContentColRechts||ContentColRechts||||||||','5'),
);

Die Reihenfolge der ARRAY-Elemente entspricht der Reihenfolge der Spaltenanzeige im Backend (BE). Das ARRAY-Element mit dem Wert „0“ ist dabei dem Hauptcontent (NORMAL) zugeordnet, „1“ der Spalte LINKS, „2“ der Spalte RECHTS und „3“ der Spalte RAND. Weitere Spalten lassen sich hinzufügen, indem unter

1

  mod.SHARED.colPos_list = 0,1,2,3,4,5

entsprechende Werte hinzugefügt und dann im nachstehenden ARRAY eingefügt werden.

Abschließend ist noch die localconf.php um folgende Zeile zu ergänzen:

1

  $typo_db_extTableDef_script = 'extTables.php';

Nehmen wir an, das Grundgerüst des Webauftritts sieht folgendermaßen aus:

Angestrebt wird für eine oder mehrere Einzelseiten aber ein anderer, individueller Aufbau mit zwei Boxen:

Für die Umsetzung sind folgende Schritte erforderlich:

1. Einrichtung zusätzlicher Spaltenelemente für das TYPO3-Backend
2. Erstellung eines eigenen Templates mit den erforderlichen CSS-Stylesheets
3. TypoScript für den Aufruf des Templates mit den beiden Boxen für ausgewählte Sites.

Zu 1: Einrichtung zusätzlicher Spaltenelemente für das TYPO3-Backend
Für die Einrichtung zusätzlicher Spaltenelemente steht ein eigenes Tutorial zur Verfügung.

Zu 2: Erstellung eines eigenen Templates mit den erforderlichen CSS-Stylesheets
Nehmen wir an, das Template mit dem normalen Content heißt “template.html”. Der Content wird in folgenden Marker eingefügt:

1
2
3
4
5

<div id="content">
  <!-- TYPO3SEARCH_begin -->
  ###CONTENT###
  <!-- TYPO3SEARCH_end -->
</div>

Für die Boxenversion wird voriges Template kopiert und bekommt den Namen template_boxen.html. Anschließend wird obiger Code durch nachfolgenden ersetzt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<div id="content">
  <!-- TYPO3SEARCH_begin -->
  <div class="cols">
    <div class="leftcolumn">
      <div class="box">
        ###CONTENT_COL_LINKS###
      </div>
    </div>
    <div class="rightcolumn">
      <div class="box">
        ###CONTENT_COL_RECHTS###
      </div>
    </div>
  </div>
<!-- TYPO3SEARCH_end -->
</div>

Exemplarisch die dazugehörigen CSS-Stylsheets für die Realisation obiger Boxen, die nach individueller Erfordernis angepasst werden können:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

#content .cols {
	margin:10px 0 0 0; padding:0;
	width:544px; line-height:1.8em;
	overflow:hidden;
}
 
#content .cols .leftcolumn {
	margin:0; padding:0;
	float:left;
	width:262px;
}
 
#content .cols .leftcolumn .box {
	margin:0 0 10px 0; padding:10px;
	float:left;
	width:262px;
	border:solid #D1D7DC 1px;
	border-top-width:15px;
	background:url(../images/0_site_hintergrund_box.jpg) top left repeat-x;
	background-color:#e8e8ec;
	height:205px;
}
 
#content .cols .rightcolumn {
	margin:0 0 0 275px; padding:0;
	width:262px;
}
 
#content .cols .rightcolumn .box {
	margin:0 0 10px 0; padding:10px;
	width:262px;
	border:solid #D1D7DC 1px;
	border-top-width:15px;
	background:url(../images/0_site_hintergrund_box.jpg) top left repeat-x;
	background-color:#e8e8ec;
	height:205px;
}

Zu 3: TypoScript für den Aufruf des Templates mit den beiden Boxen für ausgewählte Sites.

Im TypoScript (TS) ist template.html bereits als Template-Datei festgelegt:

1

  page.10.template.file = fileadmin/template.html

Soll die Seite mit der ID 18 auf templates_boxen.html zugreifen, so muss der Zugriff auf die Template-Datei überschrieben werden:

1
2
3
4
5

  #------Template für Content-Bereich mit Boxen überschreiben------
  [globalVar = TSFE:id=18]
    page.10.template.file = fileadmin/template_boxen.html
  [global]
  #------END Template für Content-Bereich mit Boxen überschreiben------

Seiten mit normalem Contentbereich werden wie bisher mit Inhalt gefüllt, indem die Inhalte in der Spalte NORMAL eingetragen werden.

Bei denjenigen Seiten, die im Contentbereich die Boxen enthalten sollen (in obigem Beispiel wäre nur die Site mit der ID 18 dafür gerüstet, weitere Sites lassen sich jedoch einfach durch: TSFE:id=18,TSFE:id=27,TSFE:id=31, etc. hinzugefügen), werden die Spalten CONTENTCOLLINKS und CONTENTCOLRECHTS mit Inhalten belegt. Für jede Box wird ein neuer Datensatz in der Spalte erzeugt und mit Inhalt gefüllt.

Beim Einsatz in WordPress empfiehlt sich die Verwendung des WordPress-Plugins WP-Syntax von Ryan McGeary. In diesem Plugin ist GeSHi bereits enthalten.

Sollte eine neuere Version von GeSHi benötigt werden, weil beispielsweise eine Script- oder Programmiersprache nicht im Paket von WP-Syntax enthalten ist, so kann die aktuelle Version hier bezogen werden: GeSHi – Generic Syntax Highlighter.

Nach dem Entpacken werden die benötigten Sprachdateien aus dem Ordner „geshi/geshi“ auf den Webserver ins Verzeichnis wp-content/plugins/wp-syntax/geshi/geshi kopiert und stehen dann im Reaktionsbereich von WordPress zur Verfügung.

Verwendung: Der Code-Block wird (in der HTML-Ansicht!) folgendermaßen eingeschlossen
<pre lang=“LANGUAGE“ line=“1“>CODE</pre>

Bei LANGUAGE wird die gewünschte (Script-/Programmier-) Sprache angegeben, z.B. java, javascript, php, sql, xml, typoscript. Eine vollständige Auflistung der unterstützten Sprachen findet sich in der Dokumentation von WP-Syntax.

line=”1” ist optional und kann eingefügt werden, wenn die Anzeige von Zeilennummerierung gewünscht wird.

Mit WP-Syntax für die Anzeige aufbereiteter Code sieht dann so aus:

1
2
3
4
5
6
7

<div id="myClass">
  <?php
    function myfunc() {
      echo "Hallo Welt!";
    }
  ?>
</div>

Fakt ist: Unserer Erfahrung nach ist 1&1 nicht die erste Wahl für den Betrieb von TYPO3-Systemen. Niedrig angesetzte Timeouts, zu wenig RAM und oft zu viele Webseiten auf einem Servercluster sind keine ideale Ausgangsbasis. Und spätestens wenn der TYPO3-Cache gesäubert wurde und alle Seiten neu aufgebaut werden müssen, kann man unangenehme Überraschungen erleben. Der Seitenaufbau kann dann beim ersten Aufruf der Seiten recht lange dauern und wer Pech hat, verärgert seine Besucher unfreiwillig mit der Nachricht, dass der Cache generiert wird und man die Seite reloaden solle, wenn nicht innerhalb der nächsten 30 Sekunden die Webseite angezeigt wird. Aber auch hier gibt es Unterschiede. So konnten wir feststellen, dass zwei identische Hostingpakete sehr unterschiedliche Performance zeigten. Da die Ausstattung gleich war, lag es vermutlich an der unterschiedlich hohen Auslastung des jeweiligen Servers – wer Pech hat und sich seinen Webspace mit vielen gut frequentierten Webseiten teilen muss, hat weniger Performance zur Verfügung.
Schwachbrüstige Hostingpakete sind jedoch keine Domäne von 1&1. Auch bei anderen „Billiganbietern“ (die nicht notwendigerweise alle günstig sind, sondern oft pauschal in diese Schublade geschoben werden) können leidgeprüfte Webmaster gleiche oder ähnliche Erfahrungen sammeln.
Es bleibt, sich einen neuen Hoster zu suchen. Manchmal ist dieses Vorhaben aber gar nicht so leicht umzusetzen. Es wird der Aufwand für das Umhosten gescheut, der Kunde ist nicht bereit, zu einem anderen Provider zu wechseln und ggf. wegen entsprechender Kündigungsfristen „doppelt zu zahlen“, es gibt hunderte von Mitarbeiter-Mailadressen, die neu eingerichtet werden müssten, sofern nicht das alte Hostingpaket für die E-Mail-Adressen beibehalten und für die Website ein A-Record zum neuen Hoster geschaltet wird, bei dem sich nach dem Umhosten die Website befindet, usw.

Alles Gründe, den Hoster nicht übereilt zu wechseln.
Unkrufen zum Trotz lässt sich TYPO3 oft gegen alle Widerstände zum Laufen bringen. Auch bei 1&1, selbst wenn der Support das Gegenteil behauptet und den Kunden lieber teure Managed-Server verkaufen möchte. Ein „1&1 Homepage Business“ Paket (derzeit rund 15 EUR/ Monat) muss es aber schon sein. Der Versuch – nach explizitem Kundenwunsch – TYPO3 auf dem nächst kleineren Paket („1&1 Homepage Perfect“) zum Laufen zu bekommen, ist bei uns gescheitert. Zu mager war die Performance des Hostingpakets. Bei TYPO3 spezialisierten Hostern bekommt man für weniger Geld (ab ca. 12 EUR, ggf. auch günstiger) eine wesentlich besser laufende TYPO3-Installation – sogar schon vorinstalliert.
Wer neu hostet und beabsichtigt, ein ressourcenhungriges CMS-System wie TYPO3 zu installieren, sollte lieber auf das „Abenteuer 1&1“ verzichten. Wer aus bestimmten Gründen bei 1&1, Strato und Co. bleiben will oder muss, zudem ausreichend Zeit und Geduld mitbringt, kann auch hier erfolgreich sein.

Soll eine relativ kleine TYPO3-Website mit wenigen Extensions betrieben werden, kann sie mit einigen Tricks wohl auch bei 1&1 laufen wenn das Hostinpaket ausreichend dimensioniert ist (siehe oben). Und ist beispielsweise die Extension tt_news zu groß und führt bei der Installation ins Timeout (500er Error), so klappt es in der Regel, wenn man das Manual aus der Extension löscht, bevor man sie installiert. Das Handbuch macht einen beträchtlichen Teil des Gesamtpakets aus. Auch ImageMagick lässt sich bei 1&1 serverseitig installieren und PHP5 lässt sich ebenfalls aktivieren, auch wenn per Voreinstellung derzeit noch die alte PHP4-Version aktiviert ist.
Das alles kann aber auch sehr viel Zeit kosten, wenn man erst einmal herausfinden muss, wie vorzugehen ist und viele Versuche benötigt, bis es endlich zufrieden stellend klappt. Um euch über einige der gängigen Hürden hinwegzuhelfen, haben wir unter dieser Rubrik Tipps und Tricks zusammengestellt.

Wer bei der Auswahl seines Providers das richtige Händchen (oder einfach Glück) hatte, bei dem ist ImageMagick bereits serverseitig installiert. Ein solcher Service ist vorbildlich, bei vielen Providern aber leider nicht Standard. Selbst bei großen Hostern wie 1&1 ist ImageMagick nicht vorinstalliert. Bleiben wir beim Beispiel von 1&1 und beschreiben die Installation von ImageMagick auf 1&1 Hostingpaketen:

1. Schritt: PHP Shell:

• Ein Hinweis vorweg: Es ist nicht möglich, ImageMagick lokal auf einem Windows-Rechner zu entpacken und im Anschluss per FTP auf den Server zu laden. Auf diesem Wege wird ImageMagick nicht lauffähig sein. Stattdessen wird SSH benötigt, um ImageMagick direkt auf dem Server zu entpacken. SSH wird bei 1&1 derzeit jedoch erst ab den Profipaketen angeboten.
• Um dieses Problem zu umgehen, empfiehlt sich der Einsatz eines Shell-Programms, z.B. „PHP Shell“ von Martin Geisler, zu finden unter: http://phpshell.sourceforge.net
• PHP Shell wird im Hauptverzeichnis des Servers installiert (entsprechenden Schutz, z.B. über .htaccess nicht vergessen, sonst können unberechtigte Personen Zugriff auf das System bekommen!).
  Anschließend wird das Programm aufgerufen, z.B.: www.meine-seite.de/phpshell-2.1/phpshell.php

2. Schritt: ImageMagick installieren

• Es bietet sich an, eine ältere ImageMagick Version zu installieren, da neuere Versionen oft wegen Performanceverlusten und Laufzeitproblemen nicht geeignet sind. Wir empfehlen die alte Version ImageMagick 4.2.9, die hier bezogen werden kann - (für Linux-Systeme - dies ist in aller Regel die Version, die auf den Webserver geladen werden muss).
• Wer für eine lokale TYPO3 Installation auf seinem Rechner eine Windows-Version von ImageMagick benötigt, wird hier fündig.
• Die Linux-Version von ImageMagick (imagemagick-4.2.9_i386-static-3.tar.gz) wird nun per FTP auf den Webserver hochgeladen. Das Programm ist bereits vorkompiliert und muss nur noch entpackt werden. Der zugehörige Befehl, der unter PHP Shell einzugeben ist, lautet:
  tar xfvz imagemagick-4.2.9_i386-static-3.tar.gz
• Damit werden alle Dateien in das Verzeichnis imagemagick-4.2.9 entpackt. Die Installation ist abgeschlossen und ImageMagick ist einsatzbereit. Da ImageMagick allerdings nicht direkt im System integriert ist, muss noch eine Pfadübergabe erfolgen. Der direkte Pfad zu ImageMagick kann ausgelesen werden indem
  1) auf der Shell in das Verzeichnis von ImageMagick gewechselt wird:
  cd imagemagick-4.2.9
  2) man sich den Pfad mit nachfolgendem Befehl anzeigen lässt:
  pwd
• Ausgegeben wird bei 1&1 ein Pfad wie:
  /homepages/12/d123456789/htdocs/phpshell-2.1/imagemagick-4.2.9
  Dieser Pfad muss in TYPO3 in der Konfiguration angegeben werden, funktioniert in oben stehender Form allerdings nicht und ist noch um /bin/ zu ergänzen. Vollständig muss er also lauten:
  /homepages/12/d123456789/htdocs/phpshell-2.1/imagemagick-4.2.9/bin/
  (der rot markierte Teil der Pfadangabe ist für jede Webseite individuell verschieden – nachfolgend wird oben stehender Beispielpfad verwendet, welcher natürlich durch den im vorigen Schritt ermittelten Verzeichnispfad zu ersetzen ist!).
• Einzutragen ist dieser Pfad im TYPO3 Install-Tool unter:
  “5: All Configuration“
  Dort ist zu setzen: [GFX][im] = 1
  Und der Pfad in folgender Form:
  [GFX][im_path] = /homepages/12/d1234567891/htdocs/rootverzeichnis/phpshell-2.1/imagemagick-4.2.9/bin/
  wobei rootverzeichnis der Name des Hauptordners ist in dem die Webseite eingerichtet wurde – sofern die Webseite im Stammordner liegt, entfällt diese Verzeichnisangabe.

  Zur Optimierung empfiehlt es sich weiterhin, folgende Parameter einzustellen:
  [GFX][gdlib_2] = 1 (sonst werden hochgeladene Bilder zu pixelig)
  [GFX][jpg_quality] = 90 (um eine höhere Qualität der angezeigten Bilder zu erreichen).

  Damit JPGs mit mehr als 256 Farben generiert werden, lassen sich die Einstellungen weiter optimieren: Jeweils ein Häkchen setzen bei
  [gdlib_png] und [png_truecolor].

• ImageMagick kann nun unter
  “1: Basic Configuration“ geprüft sowie unter „4: Image Processing“ getestet werden.

1. Im Extension-Manager unter „Install extensions“ zunächst „Retrieve/Update“ auswählen und dann die Extension via „Look up“ suchen und vom TYPO3 Extension Repository beziehen.
   Nachteil: Oft sind Extensions veraltet oder werden gar nicht erst gefunden.
2. Die Extension direkt unter http://typo3.org/extensions/repository/ suchen, als .T3X Datei auf den eigenen Rechner herunterladen und im Extension Manager unter „Import Extension“ auf den Server hochladen („Upload extension file directly (.T3X)“).
   Vorteil: Die Extension ist auf dem aktuellen Stand und kann lässt sich online problemlos auf typo3.org finden.

Beim Versuch große Extensions zu installieren, kann es jedoch zu Fehlern kommen. Der Server kann dabei ins Timeout laufen. Es wird ein 500er Fehler generiert und der Benutzer wird aufgefordert, „es später erneut zu probieren“. Die Installation wird allerdings dann auch zu einem späteren Zeitpunkt nicht funktionieren.

Dieses Problem ist (neben anderen Performanceproblemen) ein guter Grund, sich einen TYPO3 spezialisierten Hoster zu suchen. Für die 4.x-Versionen von TYPO3 sollte das memory_limit bei mindestens 40 MB (besser: 64 MB), die max_execution_time bei 120 Sekunden liegen. Werte, die von vielen Hostern z.T. deutlich unterschritten werden. Die Limits lassen sich in der php.ini verändern, allerdings lassen nur die wenigsten Hoster ihre Kunden an die php.ini. Bei einigen Providern können die Einstellungen via .htaccess mit folgendem Code verändert werden:

php_value memory_limit 64M
php_value_max_execution_time = 120

das funktioniert allerdings (u.a.) nicht bei 1&1 Paketen der „Business“-Version und niedriger.

Mit einigen Tricks lassen sich Extensions aber oft trotzdem installieren.

1. Der „Power Extension Manager“ benötigt laut Manual lediglich 25 MB Speicher und bietet einen „Page Browser“:
   ch_lightem.
2. Extension lassen via FTP auf den Server laden und mit folgendem PHP-Script entpacken:
   uncompress.php.txt.
3. Die Extension wird auf einem lokalen TYPO3-System installiert und von dort per FTP auf den Server verschoben (ggf. sind noch Einträge in der localconf.php serverseitig zu ergänzen)
4. Extension verkleinern: Einige Extensions lassen sich „verschlanken“. So kann beispielsweise die Installation von tt_news am 500er-Fehler scheitern. Die Lösung am Beispiel der derzeit (März 2009) aktuellen Version 2.5.2:
   tt_news_2.5.2.t3x hat 1.67 MB
   Davon nimmt den größten Teil das Manual ein. Entfernt man das Manual aus der .T3X-Datei, so hat die „light“-Version nur noch rund 300 KByte und lässt sich problemlos über den Extension-Manager installieren.

Fazit: Auch auf Hostingpaketen von 1&1 lässt sich TYPO3 betreiben und es lassen sich mit einigen Tricks die meisten Extensions installieren. Der dafür erforderliche Zeitaufwand kann allerdings hoch ausfallen und damit stellt sich die Frage, ob sich dieser Aufwand in jedem Fall lohnt. Erfahrungsgemäß kann es auch passieren, dass eine TYPO3 Installation zunächst nach der Umschiffung entsprechender Klippen funktioniert, aber mit jeder zusätzlichen Extension etwas mehr leidet bis es dann eine Extension zu viel ist und „nichts mehr geht“.

Aktuell (Stand März 2009) ist beim „1&1 Homepage Business“ Paket standardgemäß noch immer PHP in Version 4.4.9 installiert. TYPO3 4.2.x quittiert dies mit folgender Fehlermeldung:
“TYPO3 requires PHP 5.1.0 or higher.“

Die PHP Version lässt sich sehr einfach über die .htaccess-Datei umschalten. Dazu ist diese lediglich um folgenden Code zu erweitern:

AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

Dadurch wird bei 1&1 (aktuell) PHP 5.2.8 aktiviert.