lang hat es gedauert, bis die Advanced Mod Rewrite Erweiterung von stese in die neue Contenido Version integriert wurde. Mein erster Anlauf, die Advanced Mod Rewrite in die 4.6.23 als Plugin zu integrieren, musste ich aus zeitlichen Gründen beiseite legen.
Vorab solltet ihr wissen, dass während der Umstellung auf Plugin einiges geändert wurde und auch einiges neu hinzugekommen ist. Die wichtigsten Funktionen sind zwar getestet und dank der Community einige Kinderkrankheiten beseitigt, aber trotzdem kann ich nicht für eine einwandfreie Funktionalität des Plugins garantieren.
Mittlerweile haben einige Communitymitglieder das Plugin im Einsatz und es scheint keine nennenswerten Probleme zu geben, dennoch solltet ihr die Funktionalität des Plugins vor einem eventuellen Liveeinsatz für eure Einsatzzwecke validieren.
Ich freue mich auf die Mithilfe der Community bei der Fertigstellung des Plugins. Neben intensiver Tests und eventueller Bugfixes ist die Internationalisierung des Plugins ein wichtiges Thema, damit auch die Communitymitglieder anderer Nationalitäten etwas davon haben.
BESCHREIBUNG
Das Plugin Advanced Mod Rewrite basiert auf die geniale Erweiterung Advanced Mod Rewrite für Contenido, welches als Bundle von stese bis zur Contenido Version 4.6.15 entwickelt und betreut wurde.
Wichtiger Aspekt bei der Umsetzung war die Implementierung als Plugin mit so wenig wie möglichen Eingriffen in den Contenido Core (trotzdem ging es nicht ohne einige Anpassungen an bestimmten Sourcen).
Daher enthält das Archiv einige überarbeitete Contenido Sourcen, die eventuell nicht auf dem neuesten Stand sein können.
CHANGELOG
2010-02-23 Advanced Mod Rewrite Plugin 0.5.5 for Contenido 4.8.10-4.8.12
- bugfix: Fixed some potential security vulnerabilities
- bugfix: Replaced german umlauts which may result in broken characters depending on configured encoding
- bugfix: Category synchronization sets now urlpath of synchronized categories
- bugfix: Renaming of categories updates also urlpaths of subcategories
- bugfix: Removed old plugin related entries from database tables
- bugfix: Takeover query parameter of routed URLs into superglobal $_GET
2009-05-10 Advanced Mod Rewrite Plugin 0.5.4 for Contenido 4.8.10-4.8.12
- bugfix: Wrong URL generation to articles having same alias in different languages
- bugfix: Added missing preclean of previous percieved URLs to URL stack handler
- bugfix: Deactivated plugin related header output in mr_header()
- bugfix: Some comments in htaccess_simple.txt caused an server error
- change: Removed plugins CEC 'Contenido.Frontend.CreateURL' from Contenido chain configuration to plugins configuration
- new: Added handling of ports in URLs and also URL query items being an array (e. g. foo[bar]=1) to UrlBuilder
2009-02-08 Advanced Mod Rewrite Plugin 0.5.3 for Contenido 4.8.10-4.8.11
- bugfix: Occurance of invalid frontend URLs result in invalid rewritten URLs to root
- bugfix: Defined separator modified client path, which is not desired
2009-01-18 Advanced Mod Rewrite Plugin 0.5.2 (for Contenido 4.8.10)
- change: Adapted to Contenido 4.8.10
- change: Additional .htaccess with easy to handle rewrite rules
- bugfix: Calling the method getmicrotime() ends in PHP error during Contenido installation (thanks to josh, see viewtopic.php?p=126526#126526)
- bugfix: Corrected missing language switch detection (thanks to lunsen_de, see viewtopic.php?p=126873#126873)
2008-12-24: Advanced Mod Rewrite Plugin 0.5.1 (for Contenido 4.8.9)
- change: Adapted to Contenido 4.8.9
- change: Includes the fixes for redirection issues (see viewtopic.php?t=22976)
2008-12-21: Advanced Mod Rewrite Plugin 0.5.0 (for Contenido 4.8.8 )
- bugfix: Fixed invalid creation of URLs (thanks to Polardrache, see viewtopic.php?p=125714#125714)
- bugfix: Added case sensitive handling of paths to plugins path resolver
- change: Some cleanup
Ältere changelog-Einträge sind hier nicht mehr aufgelistet, damit der Thread nicht unnötig aufgebläht wird. Diese Infos gibt es weiterhin auf der Pluginhomepage.
BEKANNTE BUGS
Version 0.5.0 - 0.5.5:
Urls sollten unbedingt eine Endung wie z. B. '.html' bekommen, da ansonsten die Erkennungsroutine den Artikel aus der ankommenden URL nicht ermitteln kann.
Wenn der Clean-URL die Sprache oder der Mandant vorangestellt wird, funktioniert die Fehlererkennung unter Unständen nicht richtig, d. h. es gibt keine Weiterleitung zur Fehlerseite, sofern dies im Plugin eingestellt wurde.
Der Newsletterversand kann bei aktiviertem AMR-Plugin leere HTML-Newsletter versenden. Weitere Infos inkl eines Lösungsvorschlags gibt es unter viewtopic.php?f=66&t=30419.
Version 0.5.0 - 0.5.4:
Dank eines Community Users wurde eine mögliche Sicherslücke im AMR gefunden (an dieser Stelle geht mein Dank an den Reporter) über den es möglich ist, eine die Contenido Installation anzugreifen, die das AMR Plugin verwendet.
Download unter:
plugin_advanced_mod_rewrite_security_fix_0.5.0-0.5.4.zip
Der Fix ist für die AMR Versionen 0.5.0 - 0.5.4.
HINWEIS für alle, die den Fix am Anfang heruntergeladen haben:
Bitte nochmal herunterladen, da in der vorherigen Version das Erkennen der Sprache nicht funktioniert.
Version 0.5.0rc - 0.5.3:
Wenn es in einer Kategorie in mehreren Sprachen Artikel mit identischem Alias gibt, dann wird unter Umständen die idart falsch aufgelöst. Das Problem lässt sich folgendermaßen beheben:
In der Datei contenido/plugins/mod_rewrite/classes/class.modrewritecontroller.php, Zeile 473
- Code: Alles auswählen
$idart = ModRewrite::getArtIdByWebsafeName($this->_sArtName, $idcat);
ändern in
- Code: Alles auswählen
$idart = ModRewrite::getArtIdByWebsafeName($this->_sArtName, $idcat, parent::$_oGlobals->get('lang'));
Bei einer bestimmten Konstellation kann es vorkommen, dass zuvor "gemerkte" URLs beim nächsten Abruf nicht vorhanden sind. Das kann dazu führen, dass alle URLs auf das Rootverzeichnis '/' oder auf index.html umschrieben werden. Der Bug lässt sich folgendermaßen beseitigen:
Die Datei "contenido/plugins/mod_rewrite/classes/class.modrewriteurlstack.php" öffnen ab Zeile 171 am Anfang der Funktion getPrettyUrlParts() die Zeile
- Code: Alles auswählen
$url = ModRewrite::urlPreClean($url);
einfügen - Beispiel:
- Code: Alles auswählen
public function getPrettyUrlParts($url) {
$url = ModRewrite::urlPreClean($url);
if (!isset($this->_aUrls[$url])) {
...
Version 0.5.2 - 0.5.3:
In diesen Versionen ist das Debuggen der pluginseitigen Weiterleitung zur Fehlerseite nicht abgeschaltet. Daher erscheint die Redirect-URL zur Fehlerseite als ein Link auf die manuell geklickt werden muss.
Dies kann folgendermaßen behoben werden:
Die Datei "contenido/plugins/mod_rewrite/includes/functions.mod_rewrite.php" öffnen und in der Funktion mr_header() die Zeile 778 von
- Code: Alles auswählen
# header($header);return;
in
- Code: Alles auswählen
header($header);return;
ändern.
Version 0.5.0rc - 0.5.2:
1. URLs mit front_content.php?idcat=123 werden vom Plugin falsch verarbeitet, was dazu führt, dass der Request auf der Startseite endet, egal welche Kategorieid angegeben wurde. Das lässt sich beheben, in dem in der contenido/plugins/mod_rewrite/classes/class.modrewritecontroller.php am Anfang der Funktion execute() folgendes eingefügt wird:
- Code: Alles auswählen
public function execute() {
if (parent::isEnabled() == false) {
return;
}
if (strpos($this->_sIncommingUrl, 'front_content.php') !== false) {
return;
}
...
2. Außerdem gibt es ein Problem mit falsch umschriebenen URLs, das z. B. bei Artikellisten auftaucht.
Beschrieben ist das Problem unter:
viewtopic.php?p=127179#127179
Lösung inkl. Download einer gefixten Version der betroffenen Datei gibt es unter:
viewtopic.php?p=127239#127239
3. Es kann vorkommen, dass alle oder ein großer Teil der URLs auf das Rootverzeichnis '/' umschrieben werden. Hatte im Forum den Fall, dass eine von einem Modul/Plugin ausgegebene syntaktisch falsche URL die Ursache dafür war.
- Code: Alles auswählen
front_content.php?idart=123?foo=3
Diese invalide URL hat einen Fehlverhalten im AMR-Plugin produziert, das letztendlich dazu geführt hat, dass manche oder alle URLs auf der Seite falsch umschrieben wurden. Ich werde meinerseits das AMR-Plugin entsprechend anpassen, so dass diese Art von Fehlverhalten durch invalide URLs ausgeschlossen werden können.
Betroffenen Usern kann ich vorschlagen, sich die URLs anzusehen und gegebenenfalls die Ausgabe ungültiger URLs zu korrigieren.
Version 0.5.0rc:
Im Package der 0.5.0rc ist eine nicht aktuelle Version der Klasse CEC_Hook, daher tritt häufig folgende Fehlermeldung auf:
- Code: Alles auswählen
Fatal error: Call to undefined method CEC_Hook::setconditions() in /home/httpd/vhosts/mysite/httpdocs/cms/front_content.php on line 550
Zum Beheben des Problems könnt ihr die aktuelle Version der class.cec_hook.php herunterladen und in das Verzeichnis /contenido/classes/ kopieren.
Version 0.4.5:
1. In der Version 0.4.5 hat wieder mal der Fehlerteufel eingeschlichen. Ich wollte das Plugin im Backend ruhig stellen, damit im inlineediting Modus oder in der Vorschau keine URLs umschrieben werden. Leider habe ich das ganze Plugin damit lahm gelegt, d. h. das Plugin reagiert auch nicht mehr auf Änderungen in Kategorien/Artikel.
Eine korrigierte Version der Pluginkonfiguration kann unter folgender Adresse heruntergeladen werden:
http://www.purc.de/temp/plugin_advanced ... in.php.zip
Die Datei "/contenido/plugins/mod_rewrite/includes/config.plugin.php" ist einfach gegen die im Zip auszutauschen.
2. Ein weiterer Bug (bis Version 0.4.5) ist die falsche Erkennung der Seite bei mehrschprachigen Auftritten. Dies kommt dann vor, wenn die Kategorieid un der Alias des Artikels bei den Sprachen identisch ist.
Näheres dazu gibt es unter viewtopic.php?t=22511.
FEATURES
- Erstellung Suchmaschinenoptimierter URLs, Contenido interne URLs wie /front_content.php?idcat=12&idart=34 werden z. B. als /kategoriename/artikelname.html umschrieben
- Unterstützung mehrerer Sprachen
- Unterstützung mehrerer Mandanten im gleichen Verzeichnis
- Umschreiben der URLs entweder bei der Ausgabe des HTML Codes oder beim Generieren des Codes der Seiten
- Routing von URLs (Umleiten eingehender URLs auf andere Ziel-URLs)
VORAUSSETZUNGEN
- Alle Voraussetzungen von Contenido 4.8.x gelten auch für das Plugin
- PHP ab Version 5.1 (Das Plugin war bis Version 0.3.3 PHP 4.4.x kompatibel)
- Apache HTTP Server 2 mit Mod Rewrite
INSTALLATION
- Backup der Contenido Installation also der Sourcen und der Datenbank (Damit es ein Weg zurück gibt)
- Kopieren aller Dateien in die entsprechenden Verzeichnisse.
- Schreibrechte für PHP in das Verzeichnis /contenido/plugins/mod_rewrite/includes/ setzen. Das Plugin speichert die Advanced Mod Rewrite Konfiguration der Mandanten in das Verzeichnis.
(Der einfachste Weg ist das Setzen der Rechte auf 777, empfohlen ist eine restriktivere Vergabe) - In die Adresszeile des Browsers http://localhost/contenido/plugins/mod_ ... nstall.php eingeben, dann sollte das Anmeldefenster des Backends erscheinen.
("http://localhost/" ist eventuell gegen anderen virtual Host oder Domainnamen ersetzen) - Im Backend anmelden
- Advanced Mod Rewrite Plugin installieren
HINWEIS: Der Plugininstaller erstellt eine Kopie der Tabelle "{prefix}_plugins_{YYYYMMDD}", falls die Tabelle die Voraussetzungen des Plugins nicht erfüllt. Wenn vorher Plugins installiert wurden, müssen die Einträge von der Kopie der Tabelle manuell in die neue Tabelle übernommen werden. - Advanced Mod Rewrite konfigurieren (Im Backend unter Menü "Content" -> "Advanced Mod Rewrite")
Weitere Hinweise zur Installation/zu Upgrades:
Falls eine Contenidoinstallation aktualisiert wird, sollte die für die neue Version angepasste Pluginversion heruntergeladen und über die vorhandene Pluginversion darüber installiert werden. Die Vorgehensweise ist fast identisch mit der oben beschriebenen Installation, nur das dabei ein Update stattfindet.
Eine ausführliche Beschreibung dazu gibt es unter viewtopic.php?p=119362#119362
UPDATE AUF VERSION >= 0.5.0
Die Behandlung der Benutzerdefiniert Seperatoren wurde in der Version 0.5.0 (rc) grundlegend geändert. Daher sollte bei einem Update des Plugins von Version <= 0.4.5 auf Version >= 0.5.0 die Konfiguration gegebenenfalls angepasst werden - es kann sein, dass die vorher gesetzten Seperatoren bei einem Update nicht korrekt erkannt und übernommen werden.
ANPASSEN DER MODULE DES BEISPIELMANDANTEN
Die Contenido Module des Beispielmandanten verwenden seit der Contenido-Version 4.8.11, die neue UrlBuilder-Funktionalität.
In den Modulcodes werden URLs generiert, die nicht Kompatibel mit dem AMR-Plugin sind - Daher sind an den Modulen noch kleinere Anpassungen nötig, die im Beitrag viewtopic.php?f=66&t=23501 ausführlich beschrieben sind.
WICHTIGES ZUM INHALT
Allgemein
.htaccess:
Die Konfiguration des Apache, in der das mod_rewrite-Modul aktiviert und mit diversen Anweisungen konfiguriert wird. Die Einstellungen bewirken, dass ankommende Anfragen wie z. B. /kategorie/artikel.html an die front_content.php im Mandantenverzeichnis weitergeleitet werden.
Seit der Version 0.5.2 gibt es 2 Vorlagen der Datei, die htaccess_restrictive.txt und die htaccess_simple.txt.
htaccess_restrictive.txt:
Enthält Regeln mit restriktiveren Einstellungen.
Alle Anfragen, die auf die Dateienendung js, ico, gif, jpg, jpeg, png, css, pdf gehen, werden vom Umschreiben ausgeschlossen. Alle anderen Anfragen, werden an front_content.php umschrieben. Ausgeschlossen davon sind 'contenido/', 'setup/', 'cms/upload', 'cms/front_content.php', usw.
Jede neue Ressource, die vom Umschreiben ausgeschlossen werden soll, muss explizit definiert werden.
htaccess_simple.txt:
Enthält eine einfachere Sammlung an Regeln. Alle Anfragen, die auf gültige Symlinks, Verzeichnisse oder Dateien gehen, werden vom Umschreiben ausgeschlossen. Restliche Anfragen werden an front_content.php umschrieben.
Der Inhalt der .htaccess ist enthält die Regeln aus htaccess_restrictive.txt. Auf Wunsch kann es auch mit dem Inhalt der htaccess_simple.txt ersetzt werden.
contenido/plugins/mod_rewrite/*:
Die Sourcen des Plugins.
contenido/classes/mp/*:
Zusätzliche Klassen für Konfiguration, Debugging, Zugriff auf $GLOBALS, die vom Plugin verwendet werden aber nicht explizit für das Plugin implementiert wurden.
/contenido/classes/UrlBuilder/Contenido_UrlBuilder_MR.class.php:
UrlBuilder Klasse des Plugins (seit Version 0.4.0), zum Generieren der URLs anhand der Pluginkonfiguration. Verwendet die in den Contenido Core implementierte UrlBuilder-Funktionalität und erweitert diesen um die pluginspezifischen Features.
Version >= 0.5.0
Handhabung von Seperatoren:
Die Aliase für Kategorie-/ und Artikelnamen werden im Gegensatz zu früheren Versionen nicht mit den in der Pluginkonfiguration definierten Trennzeichen gespeichert, sondern mit den in Contenido per default gesetzten Trennzeichen "-". Die Entscheidung zur dieser Vorgehensweise wurde gefällt, um der Contenidoinstallation nicht die Pluginkonfiguration "aufzuzwingen", sondern die pluginspezifischen Einstellungen "on the fly" während der Ausgabe zu setzen.
Die Flexibilität, die das Plugin über das Setzen der benutzerdefinierten Seperatoren bietet, bedarf einer einheitlichen, maschinell verarbeitbaren Struktur der Aliase, daher sind Aliase, die aus mehreren Wörtern oder mit Leerzeichen zusammengesetzten Zeichen bestehen, mit einem Bindestrich "-" anzugeben.
Bei der Ausgabe der URLs, werden dann die Bindestriche gegen die in der Pluginkonfiguration gesetzten Seperatoren ersetzt - Beispiel:
- Code: Alles auswählen
Artikelname: Contenido Highlights
Artikelalias: Contenido-Highlights
Artikelwort-Separator: _
Ausgabe in der URL: Contenido_Highlights
Kategoriename: Was ist Contenido
Kategoriealias: Was-ist-Contenido
Kategoriewort-Separator: ~
Ausgabe in der URL: Was~ist~Contenido
Der Nachteil dabei ist natürlich, dass man bei der Vergabe der Aliase nicht mehr flexibel ist, und sich an die Vorgaben des Plugins richten muss.
FAQ
Der Plugininstaller lässt sich nicht aufrufen, wie kann ich dennoch das Plugin installieren?
Normalerweise wird der Plugininstaller mit folgender URL aufgerufen:
http://localhost/contenido/plugins/mod_ ... nstall.php
("http://localhost/" ist eventuell gegen anderen virtual Host oder Domainnamen ersetzen).
Es erscheint das Anmeldeformular zum Backend, über den man sich am System anmelden kann. Nach erfolgreicher Anmeldung wird man normalerweise zum Plugininstaller weitergeleitet.
Manchmal kann es vorkommen, dass die Weiterleitung nach der Anmeldung nicht klappt und man nicht den Plugininstaller aufrufen kann.
Um dennoch den Installer aufzurufen, reicht es aus, der URL die aktuell gültige Contenido Session ID anzuhängen, z. B. /contenido/plugins/mod_rewrite/install.php?contenido={my_session_id}.
Wie teste ich, ob mod_rewrite am Server richtig konfiguriert ist?
Obwohl mod_rewrite am Server installiert ist, kommt es manchmal vor, dass es nicht funktioniert.
Das kann einfach getestet werden, erstelle eine .htaccess im Rootverzeichnis und schreibe folgendes rein:
- Code: Alles auswählen
RewriteEngine on
RewriteRule ^ http://www.contenido.org [R,L]
Nach Eingabe der URL in die Adresszeile des Browsers, sollte auf http://www.contenido.org weitergeleitet werden.
Wenn nicht, dann kann eines der folgenden Punkte der Grund dafür sein:
Das mod_rewrite Modul ist nicht geladen, das ist in der httpd.conf zu setzen
- Code: Alles auswählen
LoadModule rewrite_module modules/mod_rewrite.so
Die Direktive "AllowOverride" ist nicht korrekt gesetzt. Damit die Angaben in der .htaccess auch benützt werden können, muss für das betreffende Verzeichnis die Direktive "AllowOverride" in der httpd.conf angegeben werden:
- Code: Alles auswählen
# Beispielkonfiguration
<Directory "/var/www/mywebproject">
AllowOverride FileInfo
</Directory>
Wie richte ich Advanced Mod Rewrite für eine Contenidoinstallation in einem Unterverzeichnis ein?
Als Beispiel gehen wir davon aus, dass Contenido im Verzeichnis /mypage/ unterhalb vom Webroot installiert wurde und das Mandantenverzeichnis per default /mypage/cms/ ist.
In der Pluginkonfiguration (Backend) den Pfad zur .htaccess Datei (aus Sicht des Web-Browsers) folgendermaßen anpassen:
- Code: Alles auswählen
/mypage/
Die /mypage/.htaccess öffnen und die RewriteBase folgendermaßen anpassen:
- Code: Alles auswählen
RewriteBase /mypage/cms/
Welche Einstellungen sind nötig, wenn das Mandantenverzeichnis das wwwroot ist?
Normalerweise liegt das Mandantenverzeichnis innerhalb des wwwroot und ist über http://domain.de/cms/front_content.php erreichbar.
Manchmal ist es erwünscht, dass der Ordner /cms/ in der URL nicht sichtbar sein soll, also das Frontend über http://domain.de/front_content.php erreichbar.
In diesem Fall sind zwei Anpassungen nötig, damit Mod Rewrite korrekt funktioniert:
1. Die .htaccess Datei in das Verzeichnis /cms/ kopieren, da die Datei im wwwroot sein muss.
2. In der .htaccess die RewriteBase Option anpassen
von
- Code: Alles auswählen
RewriteBase /cms
auf
- Code: Alles auswählen
RewriteBase /
Wie kann ich das Verarbeiten bestimmter Seiten vom Plugin unterbinden?
Wenn das Plugin so konfiguriert wurde, dass die URLs bei der Ausgabe des HTML Codes der Seite angepasst werden, kann dieses Verhalten bei manchen Seiten unerwünscht sein. Das kann bei einer Ausgabe der Fall sein, dessen Inhalt kein HTML ist (z. B. Dateidownload), dann macht es keinen Sinn, die Ausgabe anzupassen.
Ab Contenido 4.8.8 gibt es eine neue Einstellung, mit der man unterbinden kann, dass die Ausgabe im Frontend nicht in den Ausgabepuffer geschrieben wird. Ist dies für eine Seite definiert worden, wird auch die Funktion vom Plugin, die die URLs anpasst, nicht ausgeführt.
Einstellen lässt sich das über Mandanteneinstellungen wie folgt:
- Code: Alles auswählen
Typ Name Wert
frontend.no_outputbuffer idart 12,14,40
Inhalte der Artikel mit der id 12, 14 und 40 werden dann von der Ausgabepufferung ausgeschlossen.
Warum werden URLs trotz richtiger Vorraussetzungen nicht umschrieben?
Ist die .htaccess und die Konfiguration des Plugins als Fehlerquelle auszuschließen und das Plugin soll die URLs bei der Ausgabe der Seite umschreiben (Standardeinstellung), könnte ein vorzeitig geleerter Ausgabepuffer der Grund sein.
In der front_content.php wird der HTML-Code in den Ausgabepuffer geschrieben, damit der Code vor der endgültigen Ausgabe bearbeitet werden kann. Das Plugin fügt der Chain "Contenido.Frontend.HTMLCodeOutput" eine eigene Funktion, die den Code aus dem Ausgabepuffer erhält, um die darin vorhandenen URLs zu umschreiben.
Wird aber der Ausgabepuffer vorher geleert, z. B. durch Verwendung von ob_flush() in einem Modul, wird der Code direkt an den Client rausgeschickt. Das hat den Effekt, dass in der front_content.php kein Code mehr aus dem Ausgabepuffer zur Verfügung steht, der nicht weiterverarbeitet werden kann, auch das Plugin kann dann keine URLs umschreiben.
Alle URLs zu Kategorien werden mit / oder /index.html umschrieben
Ist Contenido mit der Konfiguration $cfg["is_start_compatible"] = true; (siehe contenidoincludes/config.php) eingestellt, um die Startartikeldefinition in Kategorien kompatibel zu älteren Contenido-Versionen halten, kann das Plugin die URLs zu Kategorien nicht generieren, weil es diese Konfiguration nicht unterstützt.
Die einfachste Lösung ist, die Konfiguration $cfg["is_start_compatible"] auf false zu setzen und im Backend in den vorhandenen Kategorien erneut die Startartikel zu setzen.
Weitere Hinweise/Tipps aus dem Forum
Von Supporter gibt es eine sehr gute Zusammenfassung zur Konfiguration des Plugins für den Einsatz in Einzelmandant-/Mehrmandant-Systemen.
viewtopic.php?p=122488#122488
DOWNLOAD
Das Plugin könnt ihr von der Seite Contenido Plugin Advanced Mod Rewrite herunterladen.
Grüße
xmurrix
