Im November 2011 erhielt eine Kundin von uns einen Werbeanruf von 1&1. Ihre Website wäre schlecht programmiert und nicht suchmaschinenoptimiert. 1&1 hatte dafür die passende Lösung zur Hand: Eine Website, die nach dem Baukastenprinzip von 1&1 erstellt wird und somit viel besser wäre als die derzeitige Internetpräsenz.

Die Kundin hat 1&1 darüber informiert, dass sie mit ihrem jetzigen Webportal sehr zufrieden sei und keinerlei Bedarf für die vorgeschlagene „Neugestaltung” ihrer Website sehe. Nicht zuletzt wirbt sie mit einem individuellen Webauftritt für ihr Unternehmen und mit einem Design, welches sie nicht mit hunderten oder gar tausenden anderen Webseitenbetreibern teilen muss.

Darüber hinaus wies sie darauf hin, dass sie mit den für sie wichtigen Keywords aufgrund der Suchmaschinenoptimierung durch uns bereits durchgängig auf Seite 1 der Suchergebnisse bei Google gelistet ist - und zwar zwischen dem 1. und 5. Rankingplatz.

Somit sieht sie auch keinerlei Handlungsbedarf, war wenig erfreut über den „Werbeanruf” und hat uns umgehend darüber informiert.

Dazu ist festzuhalten:

• Die Website ist technisch auf dem aktuellen Stand der Technik und mit moderner (X)HTML und CSS-Technik aufgesetzt.
• Sie ist weitgehend barrierefrei und der Code W3C-valide
• Die Suchmaschinenoptimierung (SEO) ist ausgezeichnet und wird von Google und anderen Suchmaschinen durch ein exzellentes Ranking honoriert.

Wir, als Internetagentur, sehen das beschriebene Vorgehen kritisch. Einerseits versucht 1&1 in regelmäßigen Abständen, uns dazu zu motivieren, als „Profi-Seller” dafür zu sorgen, dass wir Websites für unsere Kunden bei ihnen hosten. Andererseits wird versucht, uns solche Kunden wieder abzuwerben, indem unser professionelles Webdesign mit „Kritikpunkten” hinterfragt wird, welche nicht zutreffend sind. Eine solche Bewertung ist insofern bedenklich, als dass nicht jeder Kunde in der Lage ist, diese „Kritikpunkte” selbst zu prüfen.

Fazit:
Im geschilderten Fall hat 1&1 sich mit diesem Vorgehen keinen Gefallen getan. Einerseits wurde von Kundenseite nachgefragt, das Webportal zu einem anderen Hoster umzuziehen, andererseits sind wir aus verständlichen Gründen in keiner Weise motiviert, weitere Internetpräsenzen für unsere Kunden bei 1&1 zu hosten.

Es ist davon auszugehen, dass 1&1 mit diesen Werbeaktionen ein Risiko eingeht. Zwar besteht durchaus die Möglichkeit, dass sich der eine oder andere Webseiteninhaber für eine Internetpräsenz nach dem 1&1 Baukastenprinzip begeistern lässt. Jedoch sind Webagenturen ein wichtiges Rückgrat für die Hoster, da sie für ihre Kunden natürlich zuverlässige Internetprovider benötigen. Würden mittel- bis langfristig tausende von Webagenturen, Marketing- und Werbeagenturen auf andere Hoster ausweichen oder bestehende Websites zu anderen Hostern umziehen, so kann dies finanzielle Ausfälle in beträchtlicher Größenordnung nach sich ziehen.

Mit der einen Hand Provisionen für eine erfolgreiche Kundenwerbung anzubieten und mit der anderen Hand zu versuchen, den Webagenturen solche Kunden wieder abspenstig zu machen, ist ein Geschäftsmodell, gegen das man durchaus seine Vorbehalte haben kann.

Die Verbesserung des Leistungsspektrums eines Hostingpakets mit einem automatischen Upgrade auf die teurere Lösung, sofern nicht innerhalb von 4 Wochen widersprochen wird. Das Plus an Leistung rechtfertigt unseres Erachtens fraglos höhere Hostingkosten.

Jedoch:
Wer eine solche E-Mail im Rahmen der regelmäßigen Werbemails durch 1&1 übersieht und dem Upgrade seines Hostingpakets nichts explizit widerspricht, erhält Zusatzfeatures, die er womöglich gar nicht benötigt und für die er daher auch nicht bereit ist, Mehrkosten zu tragen.

Ein Auszug aus der Mail von 1&1

(Hervorhebungen in fetter oder roter Schrift im Text wurden ergänzend vorgenommen, an Stellen, die mit [...] markiert sind, wurden Details zu den neuen Features gekürzt):

Ihre Kundennummer: 123456789

Sehr geehrter Herr xxxxx,

als Kunde von 1&1 nutzen Sie mit Ihrem Tarif “1&1 Homepage Perfect”
bereits die Vorteile, die Ihnen ein modernes Homepage-Paket bietet.
Damit Ihr Paket aber auch immer den rasanten technischen
Entwicklungen gewachsen ist, überprüfen wir in regelmäßigen Abständen
die Leistungsfähigkeit unserer Produkte und optimieren nach den
Anforderungen unserer Kunden die Feature-Ausstattung.

Wir freuen uns deshalb Ihnen mitzuteilen, dass wir Ihnen folgendes
Angebot machen können. Sie können ab 01.05.2011 von folgenden
zusätzlichen Leistungsmerkmalen profitieren:

- 6 Domains inklusive (anstatt 2)

[...]

- 5000 MB Webspace (anstatt 2000 MB)

[...]

- CronJobs

[...]

- Shellzugang (per SSH)

[...]

- Noch mehr Leistung für Profis:

500 E-Mail-Postfächer (anstatt 200)
500 Subdomains (anstatt 100)
20 FTP-Zugänge (anstatt 2)
Scriptsprachen (Python, PHP, Perl)
10 MySQL-Datenbanken (anstatt eine)

Im Zuge dieser Paketaufwertung, die Sie ab dem 01.05.2011 nutzen
können, ändert sich der Preis Ihres Tarifes 1&1 Homepage Perfect
auf je 8,99 EUR/Monat. Die Preisanpassung würde mit der nächsten
regulären Abrechnung aktiv werden  - frühestens jedoch ab dem
01.05.2011. Wenn Sie sich für das Angebot entscheiden, müssen Sie
nichts weiter tun. Wir benötigen von Ihnen keine ausdrückliche
Annahme-Bestätigung.

Falls Sie aber auf die vielen Features wider Erwarten verzichten
möchten, teilen Sie uns bitte innerhalb einer Frist von 4 Wochen
unter Angabe Ihrer Kunden- und Vertragsnummer direkt an die kostenlose
Fax-Nr.: 0800 8505544 oder per E-Mail an: Vertrag_DE@1und1.de mit,
dass Sie unser Angebot ablehnen. Ansonsten tritt die Preisanpassung
mit der nächsten regulären Abrechnung in Kraft - frühestens jedoch
ab dem 01.05.2011 - und Sie werden auch weiterhin von zukünftigen
Verbesserungen profitieren.

Weiterhin viel Erfolg mit 1&1 Homepage Perfect wünscht Ihnen,

Ihr WebHosting-Team

1&1 Internet AG

Your login attempt did not succeed. Make sure to spell your username and password correctly, including upper/lowercase characters.

Nun waren Benutzername und Passwort korrekt und das Problem trat bei allen Benutzerzugängen dieser TYPO3-Installation auf.

Prüft man allerdings nur einen einzelnen Benutzeraccount, so stellt sich rasch die Vermutung ein, die Zugangsdaten wurden verwechselt oder die korrekten Daten sind vergessen worden. Der erste Versuch bei einer solchen Fehlermeldung führt dann üblicher Weise über das Installtool unter
» Database Analyser wo die Option » Create ‚admin’ user bemüht wird, um einen neuen Admin-Zugang anzulegen.

Ist das Problem tatsächlich durch falsche Zugangsdaten verursacht worden, so kann mit dem neu eingerichteten Admin wieder eine erfolgreiche Anmeldung zum TYPO3-Backend erfolgen.

Im hier vorgestellten Fall wurde das Anlegen eines neuen Admins jedoch durch folgende Fehlermeldung quittiert:

Error: INSERT command denied to user ‘xxx’@'yyy’ for table ‘be_users’

Die Überprüfung der Datenbank hat dann ergeben, dass die Tabelle „cache_pages” fast 200 MByte aufwies und die Datenbank überfüllt war. Dadurch waren die Schreibrechte deaktiviert worden. Bei der Anmeldung von TYPO3-Backend-Benutzern müssen jedoch einige Informationen in die be_users Tabelle geschrieben werden. Ist dies nicht möglich, so schlägt auch der Login fehl.

Um Platz zu schaffen, bietet sich an, über das Installtool via
» Database Analyser > Clear tables
die Inhalte ausgewählter Tabellen zu löschen. Im vorliegenden Fall speziell die Tabelle „cache_pages”. Auch die Inhalte der Tabellen „cache_pagesections”, „cache_hash”, sowie „cache_imagesize” können sehr schnell für eine volle Datenbank sorgen.

Was passiert beim Löschen?
Um die einzelnen Seiten beim Benutzeraufruf schneller zur Verfügung stellen zu können, cached TYPO3 sie beim ersten Aufruf und schreibt die Informationen zur fertig aufgebauten Seite in die Cache-Tabellen. Das verhindert, dass die Seiten bei jedem neuen Aufruf komplett neu aufgebaut werden müssen, reduziert die Serverlast und verkürzt die Ladezeiten. Da hier teilweise vollständige HTML-Ausgaben abgespeichert werden, können die Tabellen sehr schnell sehr groß werden. Das Löschen der Tabellen „cache_pages”, „cache_pagesections” und „cache_hash” entspricht der Option „Alle Caches löschen” im TYPO3 Backend. Nach dem Löschen der Cache-Tabellen sollte die Datenbank wieder „schlank” und - ggf. nach einer entsprechenden Wartezeit - die Schreibrechte neu erteilt sein. Dann funktioniert auch der Login wieder.

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.