TYPO3 Framework und CMS

Bei dem Einsatz der TYPO3 Extension "tt_news" wird oft nach dem Setzen des Seitentitels gefragt. Das setzen des Seitentitels mit der aktuell aufgerufenen News, lässt sich über einen TypoScript-Code lösen. Der TypoScript-Code greift auf die tt_news-Tabelle zurück und mittels "stripHTML", werden alle HTML-Tags entfernt. Vergleichbar ist die Funktion mit der PHP-Funktion "strip_tags()".

temp.newsTitel=COA
temp.newsTitel {
  wrap= |
  5=RECORDS
  5{
    # GET-Parameter der News holen
    source = {GPvar:tx_ttnews|tt_news}
    source.insertData = 1
    tables = tt_news
    conf.tt_news >
    conf.tt_news = TEXT
    conf.tt_news.field=title
    # Bereinigen des Titels mit stripHtml (alle HTML-Tags entfernen)
    conf.tt_news.stdWrap.stripHtml = 1
  }
}

Wer den Seitentitel selbst generiert, muss dann das TEMP-Objekt auf den eigens erstellten Seitentitel vererben. Zum manuellen Setzen des title-Tags, nehmen wir das PAGE-Objekt und setzten dort den Header via "headerData" ein. Der folgende TypoScript-Code ist sofern modular aufbereitet, sodass noch weitere TLO's (Top-Level-Objekte) via TypoScript gesetzt werden können.

config.noPageTitle = 2
page.headerData.100 {
wrap = |
 10 = COA
 10 {
  10 < temp.newsTitel
 }
20 = TEXT
20.value = &laquo; Seitentitel
}

TYPO3 Framework und CMS

Auf der Suche nach einer Lösung von Duplicate Content in TYPO3, stieß ich auf die Extension "ods_seo" (SEO Buddy). Die Extension hängt sich in den TypoScript-Code (page.headerData) und überprüft in der Datenbank, welches die eindeutige URL zu der aufgerufenen Seite ist und setzt diese als META-Tag (canonical) im Head-Bereich der Seite. Denn um die Duplicate Content Problematik zum Beispiel in TYPO3 zu lösen, gibt es seit längerem das “Canonical Meta-Tag”, dass die größten Suchmaschinen im Internet, Google, Yahoo! und Microsoft unterstützen.Im Head-Bereich der Internetseite wird nun unter den bekannten MetaTags wie "robots", "language", und weitere MetaTags auch der"rel=canoncial" Tag eingebunden.

Der Canonical MetaTag sieht wie folgt aus:

<link  rel="canonical" href="http://www.domain.de/pagename/" />

Im Framework TYPO3 hat man automatisch Duplicate Content, da eine Inhaltsseite  zum Beispiel über "http://www.domain.de/index.php?id=1" oder über "http://www.domain.de/?id=64", "http://www.domain.de/pagename" oder http://www.domain.de/pagename/ (via RealUrl umgeschrieben) erreichbar ist. Die Extension "ods_seo" versucht dies zu verhindern, indem in der Datenbank geschaut wird, welches die wirklich eindeutige aufrufbare Url für die angeforderte Seite ist.

Die Konfiguration der TYPO3-Extension ist denkbar einfach. Ebenfalls steht im TER auf typo3.org eine recht kurze aber ausführliche Anleitung zur Grundkonfiguration der Extension zur Vermeidung von Duplicate-Content zur Verfügung.
Wichtig zu wissen ist, dass ihr bei dem Einsatz dieser Extension einen modernen Server zur Verfügung hat, der auch größere Datenbankabfragen problemlos in kurzer Zeit verarbeiten kann. Die TYPO3 Extension schaut bei jedem Seitenaufruf in der Datenbank nach der eindeutigen (Unique-URL) Adresse. Sofern die Extension RealUrl installiert wurde, wird auf die Datenbanktabelle von RealUrl zurückgegriffen. Ist der Internetauftritt in diversen Sprachen und mit mehr als 500 Inhaltsseiten vorhanden, können die Datenbankabfragen sehr rechen- und zeitintensiv werden.

Bei dem Einsatz dieser Extension sollte ebenfalls beachtet werden, dass die eigens geschriebenen Extensions für das TYPO3-Frontend über das TYPO3-Framework generiert werden und nicht händisch durch eigene Funktionen erzeugt werden. Sind die Links durch eigene PHP-Funktionen generiert, so kann die Canonical-Extension nicht greifen, da diese Urls nicht in der RealUrl-Datenbanktabelle stehen oder von TYPO3 gecached wurden. Daher nutzt bitte in euren Frontend-Extensions immer die TYPO3-Kernfunktionen.

TYPO3-Kernfunktionen (tslib_pibase) zur Generierung von Links in Frontend-Extensions:

• pi_getPageLink ($id, $target='', $urlParameters=array())
• pi_linkToPage ($str, $id, $target='', $urlParameters=array())
• pi_linkTP ($str, $urlParameters=array(), $cache=0, $altPageId=0)
• pi_linkTP_keepPIvars ($str, $overrulePIvars=array(), $cache=0, $clearAnyway=0, $altPageId=0)
• pi_linkTP_keepPIvars_url ($overrulePIvars=array(), $cache=0, $clearAnyway=0, $altPageId=0)

Möglicherweise werdet ihr bei der Generierung der Canonical-Url einen GET-Parameter "cHash" erhalten. Dies scheint in der Extension "ods_seo" Probleme zu bereiten. Abhilfe schafft generell nur das Entfernen der Codezeilen in der "_pi1" der Extension, die den "cHash" berücksichtigen.

$pidList = implode(',', $given_PIDs); // Konvertiert Array zu einem Komma getrennten String. (z.B. 1,12,55)
$GLOBALS['TSFE']->clearPageCacheContent_pidList($pidList);

Der ehemalige Weg über die Funktion clear_cacheCmd() führt zu einem “Fatal error: Call to a member function writelog() on a non-object”.
Die Ursache ist die, dass die Funktion davon ausgeht das ein Backend-User eingeloggt ist, was zu 99,9% der Fälle nicht zutrifft.

Seit dem Erscheinen der TYPO3 Version 4.5.x, wurde auch im TYPO3-Bugtracker ein sehr hilfreicher Eintrag dazu veröffentlicht.
0016844: error when using t3lib_TCEmain->clear_cacheCmd in frontend (only for TYPO3 4.5 and higher)

Hat einer meiner Leser vielleicht noch einen Tipp, wie sich der Frontend-Cache mit einem Kommentar für das Protokoll im TYPO3-Backend leeren lässt? Seit der TYPO3-Version 4.5.x wird das Leeren des TYPO3-FE-Caches im Protokoll mit einem Kommentar versehen. Diese Methode wäre auch für den Frontend-Cache eine schöne Angelegenheit.

TYPO3 Framework und CMS

Seit dem neuen TYPO3-Release, Version 4.6. --rebase, wird im IntsallTool beziehungsweise bei der Installation des TYPO3-Systems eine Fehlermeldung (Exception) "openssl missing" hervorgerufen. Aufgrund der neuen Sicherheitsfeatures in TYPO3 4.6. (saltedpasswords) und weiteren sicherheitsrelevanten Punkten, wird seit TYPO3 Version 4.6.x das PHP-Modul "openssl" vorausgesetzt. Zahlreiche ältere PHP 5.3.x Versionen, zum Beispiel eine ältere XAMPP-Installation unter Windows, haben das PHP-Modul nicht aktiv.

TYPO3 Exception / Fehlermeldung:

Uncaught TYPO3 Exception
#1294587482: TYPO3 Installation Error: The following PHP module(s) is/are missing: openssl
You need to install and enable these modules first to be able to install TYPO3. (More information)
RuntimeException thrown in file
C:\xampp\htdocs\typo3_4.6\typo3\sysext\install\mod\class.tx_install.php in line 202.

Ohne das aktivierte PHP-Modul ist die Installation der neuen TYPO3 Version 4.6 nicht möglich!

Wie lösen wir das Problem mit dem fehlenden openssl-Modul?
- Du musst in der php.ini-Datei das openssl-Modul aktivieren
- Die php.ini-Datei befindet sich im XAMPP-Installationsverzeichnis "xampp\php\php.ini" oder "/etc/php5/php.ini".
- In der php.ini-Datei muss die Zeile "extension=php_openssl.dll" aktiviert werden. Das Semikolon ";" muss am Anfang der Zeile entfernt werden.
- Ist diese Zeile nicht vorhanden, suche in der php.ini nach "extension=" und füge ans Ende des Blocks die oben genannte Konfiguration ein
- Ist die php.ini-Datei aktualisiert, muss noch der Apache-Dienst aktualisiert werden. Bei Xampp kann der Dienst gestoppt und gestartet werden. Unter Linux reicht oft schon ein "sudo /etc/init.d/apache2 reload" aus. Falls nicht, anstelle des "reload"-Parameters "stop" und "start" verwenden.

Ob die Aktivierung des PHP-Moduls "openssl" funktioniert habt, könnt ihr mittels eines phpinfo()-Aufrufs testen oder die TYPO3 4.6 Installation erneut laden.

TYPO3 Framework und CMS

Bei der Verwendung der von TYPO3 angebotenen Bildverkleinerung und des GIFBUILDER(s) für grafische Navigationen, kommt es leider auf vor, dass die Bildqualität sehr mit Artefakten versehen ist. Oder sogar die Konvertierung von GIF zu PNG fehlschlägt und ein schwarzer Hintergrund im Bild entsteht. Der Grund der mangelnden Bildqualität liegt an der Grundkonfiguration von TYPO3 im InstallTool bzw. der localconf.php im Ordner "typo3conf".

Die Lösung des Problems der Bildqualität von PNG/Gif mit dem GIFBUILDER oder dem Richt-Text-Editor mit Zauberbildern sieht wie folgt aus.
Überprüfung der vorliegenden Versionen von ImageMagick, PHP-Gdlib und der sich im Einsatz befindlichen TYPO3-Version bzw. des TYPO3-Cores. Zur Lösung der oben genannten Probleme, sollte auf dem Server ImageMagick in der Version 6 (Abkürzung: im6), PHP-Gdlib 2.x und TYPO3 mindestens in der Version 4.3.x vorliegen. Sofern die Versionen von ImageMagick, PHP-Gdlib und TYPO3 verfügbar sind, kann die Konfiguration von TYPO3 angepasst werden. Im Verzeichnis "typo3conf" befindet sich die Datei "localconf.php" und muss mit den Werten "jpg_quality", "gdlib_png", "png_truecolor" und "gdlib_2" gesetzt werden:

$TYPO3_CONF_VARS['GFX']['jpg_quality'] = '85';
$TYPO3_CONF_VARS['GFX']['gdlib_png'] = '1';
$TYPO3_CONF_VARS['GFX']['png_truecolor'] = '1';
$TYPO3_CONF_VARS['GFX']['gdlib_2'] = '1';

Diese Werte lassen sich auch über das TYPO3-Backend und das InstallTool unter dem Punkt "All Configuration" setzen.

TYPO3 Framework und CMS

TYPO3 Backend: Inhaltselement verbergen

Um die Eigenschaft "Inhaltselement verbergen" bei der Erstellung eines Content-Elements als Standardwert zu setzen, muss in der "Page TSConfig" der TCAdefaults-Wert für die Tabelle "tt_content" überschrieben werden.

Die TCAdefaults-Konfiguration lautet:

# Neue Inhalte (Content-Elemente) automatisch verbergen:
TCAdefaults.tt_content.hidden = 1

TYPO3-Backend: Inhaltselement per TCADefaults (tt_content.hidden) verbergen

Wurde dieser Wert gesetzt, wird bei der Neuanlage eines Inhaltselement, das Element automatisch verborgen und muss im Nachhinein aktiviert werden.

TYPO3 Framework und CMS

In der neuen TYPO3 Version 4.6 --rebase wurden zahlreiche depracted Funktionen aus dem TYPO3-Core entfernt. Viele sich im Einsatz befindliche TYPO3-Extensions arbeiten im TYPO3 Backend für die Module (mod1, mod2, ...) mit der Kernklasse t3lib_div und dessen ehemaligen Funktion fixed_lgd_pre(). Wird ein TYPO3 Projekt zum Beispiel von der Version 4.5 auf die Version 4.6.x aktualisiert, tritt dieser Fehler auf. Die Fehlerkorrektur ist recht simpel, leider muss dafür der Extensionkern (Ext-Core) angepasst werden, damit die Extension im TYPO3-Backend wieder funktionstüchtig ist. Bis zur nächsten Aktualisierung durch den eigentlichen Extension-Entwickler ist also diese Art Eingriff von Nöten.

Die neue PHP-Funktion in der Kernklasse t3lib_div lautet fixed_lgd_cs(), sie ersetzt die ehemalige Funktion fixed_lgd_pre().
Die Funktion fixed_lgd_pre() wurde zum Beispiel für die Extension "kickstarter" und "sk_pagecomments" eingesetzt.

Einen Patch für die Extension "kickstarter" wurde bereits am 31.05.2011 veröffentlicht.
In der Extension "sk_pagecomments" muss im Verzeichnis "mod1" die index.php-Datei in der Zeile 139 angepasst werden.

Ehemalige Codezeile (typo3conf/ext/sk_pagecomments/mod1/index.php)

$headerSection = $this->doc->getHeader("pages",$this->pageinfo,$this->pageinfo["_thePath"])."
".$LANG->sL("LLL:EXT:lang/locallang_core.xml:labels.path").": ".t3lib_div::fixed_lgd_pre($this->pageinfo["_thePath"],50);

Neue Codezeile (typo3conf/ext/sk_pagecomments/mod1/index.php)

$headerSection = $this->doc->getHeader("pages",$this->pageinfo,$this->pageinfo["_thePath"])."
".$LANG->sL("LLL:EXT:lang/locallang_core.xml:labels.path").": ".t3lib_div::fixed_lgd_cs($this->pageinfo["_thePath"], -50);

Note:

t3lib_div::fixed_lgd_pre() - since TYPO3 4.1, will be removed in TYPO3 4.6 - Use t3lib_div::fixed_lgd_cs() instead (with negative input value for $chars) - require#5

In dem gleich gezeigten Beispiel (Tutorial), möchte ich euch zeigen, wie eine CSS- oder JavaScript-Datei von einer Extension geladen werden kann, aber auch per TypoScript ausgetauscht werden könnte. So könnte nach Belieben ein Integrator die CSS-Datei austauschen, ohne die Extension zu bearbeiten und die Updatemöglichkeiten zu verringern, da der Core angepasst wurde.

Datei aus Extension per TypoScript definieren

Der Backenduser soll die Möglichkeit erhalten, zu entscheiden, welche CSS-Datei von der Extension eingebunden werden soll. Die Config-Option cssFile innerhalb des Plugins bietet uns genau diese Möglichkeit, um per TypoScript eine neue CSS-Datei für die Extension zu definieren.

plugin.tx_extensionKey_pi1 {
        cssFile = fileadmin/templates/css/custom_extensionKey.css
}

In unserer Extension prüfen gegen, ob die TypoScript-Konfiguration für unsere Extension mit dem ExtensionKey "extensionKey" gesetzt wurde. Falls keine Individualisierung der CSS-Datei gesetzt wurde, werden wir unsere Extension-CSS-Datei laden lassen..

$cssExtFile = $this->conf['cssFile'] ? $this->conf['cssFile'] : 'path/extensionKey.css';

Datei in den HTML--Bereich schreiben

$GLOBALS['TSFE']->pSetup['includeCSS.'][$this->extKey] = $cssExtFile

Setzen lässt sich die CSS-Datei für unsere Extension über das pSetup nur, wenn die Cache-Methode für unser Plugin aktiviert wurde. - Ist der Cache deaktiviert, wird die Extension als USER_INT-Objekt geladen und kann das $GLOBALS-Array nicht manipulieren. Sofern ich die Erfahrung gemacht habe, ist es seit der TYPO3 Version 4.5.x möglich, auch die CSS-Dateien in den Head-Bereich zu setzen, wenn die Cache-Methode für eine Extension deaktiviert wurde.

$GLOBALS['TSFE']->additionalHeaderData[$this->extKey] = '
<link rel="stylesheet" href="'.$cssExtFile.'" type="text/css" />';

Korrekter Pfad zur Default-Datei
Zur Ermittlung des richtigen Dateipfades müssen wir definieren, wo die Extension-CSS-Datei liegen soll. Empfehlenswert ist es, die CSS-Datei mi in das Extensionverzeichnis zu liegen und da es eine Ressource ist, in einen neuen Ordner namens "res" abzulegen. Die Default-Struktur der Extension sieht z.B. wie folgt aus:
- doc
- mod1
- pi1
- res
Sofern wir den Ordner "res" angelegt und dort die CSS-Datei für unsere Extension abgelegt haben, können wir den Pfad zu unserer CSS-Datei definieren. Mit der mitgelieferten Funktion "siteRelPath" ermitteln wir den aktuellen Pfad zu unserer Extension.

t3lib_extMgm::siteRelPath(string $extKey);

Für die finale Implementierung unserer CSS-Datei oder auch JavaScript-Datei, wenden wir die Funktion zur Pfad-Generierung an und übergeben zusätzlich unsere CSS/JS-Datei.

$cssExtFile = $this->conf['cssFile'] ? $this->conf['cssFile'] : t3lib_extMgm::siteRelPath('extensionKey').'res/extensionKey.css
$GLOBALS['TSFE']->additionalHeaderData[$this->extKey] = '
<link rel="stylesheet" href="'.$cssExtFile.'" type="text/css" />';

TYPO3 Framework und CMS

Nachdem die neue TYPO3 Version 4.6. --rebase veröffentlicht wurde, konnte Patrick Lobacher nicht still halten und hat erneut eine umfangreiche und sehr detaillierte Präsentation zu allen Neuerungen in TYPO3 4.6 erstellt. Alle Neuerungen wurden bei Slideshare zur Verfügung gestellt und können auch als PDF-Datei heruntergeladen werden. Wer einen Unternehmensauftritt plant, lässt sich am Besten von einer Typo3 Agentur beraten, diese auch Anregungen hinsichtlich SEO und anderen Marketing Maßnahmen informiert.
Generelle Änderungen in TYPO3 4.6

- Ab sofort wird PHP 5.3 vorausgesetzt. Ältere PHPVersionen werden NICHT mehr unterstützt!
- Die PHP-Einstellung magic_quotes_qpc ist deprecated und soll daher auf „Off“ stehen. Das Reports-Modul weist darauf hin, falls „On“ verwendet wird.
- Die PHP-Einstellung safe_mode ist deprecated und soll daher auf „Off“ stehen. Das Reports-Modul weist darauf hin, falls „On“ verwendet wird.
- Neuer Formhelper mit Drag&Drop-Funktion im TYPO3-Backend mittels ExtJS

TYPO3 4.6 - Die Neuerungen (typovision*)

TYPO3 Framework und CMS

Welcher TYPO3-Integrator steht nicht vor dem Problem, dass für die Suchmaschinenoptimierung die meta-Keywords und auch die meta-Descriptions gesetzt werden sollen. Gesehen hat sicherlich jeder Redakteur und TYPO3-Integrator, dass in den Seiteneigenschaften die Möglichkeit besteht, die meta-Keywords und meta-Descriptions zu setzen. - Nur wie sind diese per TypoScript auszulesen?

Im TypoScript-Template lassen sich die Konstanten und der eigentliche Setup des TS definieren. Für die "Standard-Meta-Keywords" und "Descriptions", können in den Konstanten eigene Variablen definiert werden, welche später im TypoScript-Setup ausgelesen werden. Sofern für eine Seite keine Keywords und Descriptions gesetzt wurden, werden die Konstanten ausgelesen und in die meta-Tags geschrieben.

Das TLO (Top-Level-Object) Page in Verbindung mit der TSREF-Eigenschaft "meta" führen zum Ziel der Ausgabe der meta-Daten.
Im TypoScript-Setup muss folgender Code integriert werden:

page {
 meta.description = {$meta.description}
 meta.description.override.field = description
 meta.keywords = {$meta.keywords}
 meta.keywords.override.field = keywords
}

Die geschweiften Klammern und das Dollar-Zeichen lesen die definierte TypoScript-Konstante aus, sofern in der aktuellen Seite keine Keywords oder Descriptions gesetzt wurden.