Plugin Advanced Mod Rewrite für Contenido 4.8.x

[xmurrix]

...Würde es nicht Sinn machen, diesen Code-Snipsel fest in die Source aufzunehmen?...

Auf den ersten Blick scheint es von Vorteil zu sein, wenn die zusätzliche Bedingung in den Contenido-Core eingebaut wird.

Ich halte das aber nicht für eine gute Idee. Am Idealsten wäre eine einheitliche Parameterübergabe an die verschiedenen UrlBuilder, das ist aber momentan technisch nicht möglich. Überall dort, wo man dann solche URLs generiert, müsste man dann Bedingungen wie

Code: Alles auswählen

if ($aCfg['url_builder']['name'] == 'front_content') {
      $aParams = array('lang' => $iLang, 'idcat' => $oCategory->getIdCat());
} else if ($aCfg['url_builder']['name'] == 'anderer_url_builder') {
      $aParams = array(...andere parameter...);
} else if ($aCfg['url_builder']['name'] == ein_ganz_'anderer_url_builder') {
      $aParams = array(...andere parameter...);
}
...

erstellen. Das sind dann zuviele Anhängigkeiten und du kannst dir auch vorstellen, in was das ausarten kann, wenn es in Zukunft weitere UrlBuilder geben sollte.

Momentan kommt man nicht drum herum, sich für einen UrlBuilder zu entscheiden und die Modulausgaben entsprechend anzupassen.

Gruß
xmurrix

[Mariposa]

Nun denn, muss dir recht geben.

Bleibt somit nur, die Änderungen am Sourcecode selbst zu dokumentieren, um für Updates gerüstet zu sein.
Hierzu noch: In der Datei "Contenido_Sitemap_Util.class.php" im gleichen Verzeichnis muss die gleiche Bedingungserweiterung eingefügt werden, um in der Sitemap auch saubere URL´s zu bekommen.

Wo ich "schrauben" muss, um diese sauberen URL´s auch für die Meta-Navigation zu bekommen, habe ich noch nicht gefunden. Kannst du mir da noch helfen?

Gruß
Mariposa

[xmurrix]

...Wo ich "schrauben" muss, um diese sauberen URL´s auch für die Meta-Navigation zu bekommen, habe ich noch nicht gefunden. Kannst du mir da noch helfen?...

Soweit ich weiß, ist es momentan die Contenido_NavMain_Util.class.php und die Contenido_Sitemap_Util.class.php, in die URLs mit dem UrlBuilder generiert werden. Ansonsten müsstest du dir mal die Modulausgaben ansehen, ob irgendwo der UrlBuilder verwendet wird.

Die Module des Beispielmandanten sind auch als solches gedacht und können den eigenen Bedürfnissen angepasst werden. Bei einem Update wird da in der Regel nichts überschrieben. Wo du aufpassen musst, sind die Dateien im Mandatenverzeichnis, z. B. die Contenido_NavMain_Util.class.php, falls du daran etwas änderst.

Ich würde dir vorschlagen (meine persönliche Meinung), die Module so zu belassen, damit gewöhnliche URLs zu Frontendseiten wie 'front_content.php...' generiert werden. Ist das AMR-Plugin installiert und die Option zum Umschreiben der URLs bei der Ausgabe der Seite ist gesetzt, kümmert sich das Plugin darum. Die Contenido_NavMain_Util.class.php und die Contenido_Sitemap_Util.class.php müsstest du dann so anpassen, dass sie URLs wie 'front_content.php?idact=123' usw. liefern.

Gruß
xmurrix

[Avalanche]

Hallo zusammen,

erstmals möchte ich mich vielmals bei Murat für das Modul und den tollen Support bedanken.

An dieser Stelle muss ich leider auf ein altes Problem zurückkommen, welches zuletzt ein wenig untergegangen ist. Ich habe leider nach wie vor das Problem, dass die URLs nicht richtig generiert werden (http://www.domain.de/index.html statt z.B. http://www.domain.de/news/index.html).

In einem aktuellen Projekt habe ich zwei Mandanten angelegt. Unter Mandant 1 funktioniert das Mod Rewrite wunderbar, die URLs werden alle umgewandelt, wie es sein muss. Unter Mandant 2 tritt nun zuvor genannter Fehler erneut auf und somit ist keine Seite ansteuerbar.

Ich habe alle Einstellungen mehrfach geprüft. Schalte ich das Mod Rewrite aus, werden alle Adressen nach altbekanntem Prinzip "front_content.php?idcat=48" etc. ausgegeben. In allen Kategorien befindet sich zudem ein aktiver Startartikel, also hieran kann es auch nicht liegen.

Hat sonst noch jemand ähnliches Problem gehabt und ggf. eine Lösung hierfür gefunden?

Danke und Gruß
René

PS:
Beinahe vergessen: Contenido Version 4.8.11, Mod Rewrite Version 0.5.3

[xmurrix]

Hallo,

...An dieser Stelle muss ich leider auf ein altes Problem zurückkommen, welches zuletzt ein wenig untergegangen ist. Ich habe leider nach wie vor das Problem, dass die URLs nicht richtig generiert werden (http://www.domain.de/index.html statt z.B. http://www.domain.de/news/index.html).

In einem aktuellen Projekt habe ich zwei Mandanten angelegt. Unter Mandant 1 funktioniert das Mod Rewrite wunderbar, die URLs werden alle umgewandelt, wie es sein muss. Unter Mandant 2 tritt nun zuvor genannter Fehler erneut auf und somit ist keine Seite ansteuerbar...

Ich werden mir das mal ansehen, eventuell ist da noch ein Problem mit dem Plugin.

Wenn alle URLs einer Seite auf http://www.domain.de/index.html umschrieben werden, kann das auch ein Hinweis auf eine invalide URL im HTML-Output sein. In früheren Versionen des Plugins hat z. B. eine URL wie "front_content.php?idart=123?foo=bar" dazu geführt, dass die Aliase aller gesammelten URLs nicht ausgelesen werden konnten, und die URLs alle auf das Rootverzeichnis (oder auch index.html) umschrieben wurden. Das Problem hatte ich eigentlich behoben, vielleicht gibt es da noch eine andere Konstellation, die das gleiche Verhalten verursacht.

Kannst du bei deaktiviertem Plugin mal gegenprüfen, ob beim betroffenen Mandanten eine syntaktisch falsche URL ausgegeben wird? Oder mit den HTML-Quelltext per PM schicken.

Gruß
xmurrix

[Avalanche]

Hallo Murat,

also inzwischen funktionieren die URLs. Ich habe lediglich erneut die Funktion "Aliase zurücksetzen" genutzt und nun funktioniert die Seite mit beiden Mandanten wunderbar. Allerdings habe ich diese Option zuvor bereits ausprobiert, in erster Instanz allerdings ohne Resultat. Die URLs haben keine Besonderheiten, bei ausgeschaltetem Mod Rewrite wird lediglich die idcat ausgegeben, keine weiteren Parameter (z.B. front_content.php?idcat=48).

Für den Moment scheint auf jeden Fall alles wunderbar zu klappen.

Viele Grüße aus der Karnevalshochburg Köln ))
René

[Thorsten G.]

Tach community, hallo Murat,

contenido 4.8.11
mr 0.53

Mit eingeschaltetem Plugin lassen sich die geschützten Downloads über die dbsf.php nicht mehr herunterladen, der User wird auf die Startseite weitergeleitet.
Der generierte Link sieht so aus:

Code: Alles auswählen

http://www.domain.de/cms/dbsf.php?file=dbfs:/richtigesVerzeichnis/richtigeDatei.pdf

Bei abgeschaltetem ModRewrite lassen sich die Dateien über den selben Link herunterladen.

In der .htaccess habe ich die dbsf.php - scheinbar erfolglos - vom rewriten ausgeschlossen:

Code: Alles auswählen

# Exclude some files and directories from rewriting
# -------------------------------------------------
[..]
RewriteRule ^cms/dbsf.php.*$ - [L]
RewriteRule ^cms/test/.*$ - [L]
RewriteRule ^cms/front_content.php.*$ - [L]
[...]

Im Downloadmodul wird der Link auf diese Weise generiert:

Code: Alles auswählen

$str_file_url = "http://www.domain.de/cms/dbfs.php?file=" . $dllist_item->get("dirname") . $dllist_item->get("filename");

Ich habe keine Idee mehr, was ich noch ausprobieren könnte ... hat vielleicht jemand anderes einen Masterplan?

Mit bestem Dank
Thorsten

[xmurrix]

Hallo Thorsten,

...In der .htaccess habe ich die dbsf.php - scheinbar erfolglos - vom rewriten ausgeschlossen:

Code: Alles auswählen

# Exclude some files and directories from rewriting
# -------------------------------------------------
[..]
RewriteRule ^cms/dbsf.php.*$ - [L]
...
[...]

...

das sieht nach einem Vertipper aus, sollte es nicht

Code: Alles auswählen

RewriteRule ^cms/dbfs.php.*$ - [L]

anstatt

Code: Alles auswählen

RewriteRule ^cms/dbsf.php.*$ - [L]

sein?

Gruß
xmurrix

[Thorsten G.]

Ich dreh´ durch!

Danke, murrix.

(Gott, ist mir das peinlich)

[birke]

Ich habe das Plugin wie beschrieben installiert und aktiviert, doch sobald ich die .htaccess in den /cms Ordner kopiere, erhalte ich nur einen Internal Server Error. Was mache ich denn hier falsch?

Ersetze ich nun die .htaccess durch eine leere htaccess und deaktiviere das Plugin, erhalte ich einen parse error:

Parse error: syntax error, unexpected T_OBJECT_OPERATOR in /mnt/web3/12/97/537497/htdocs/cms/front_content.php on line 202

Contenido Version 4.8.11 auf einem Strato Server.

[baumpaul]

Hallo,

ich habe gerade ein neues Projekt auf einem Host Europe L Server zum laufen gebracht. Lieder funktioniert das ReWriting nicht korrekt.

Bei allen Links ist die Domain nur noch "www.domain.tdl/de/", der Ordnerpfad fehlt. Es wird nur die Sprache angezeigt. Ich habe es nun schon ein zweites mal ausprobiert und alle Dateien original neu hochgeladen. Der mr_test.php zeigt mir für alle Seiten auch nur die Sprache an.

Contenido: 4.8.11
ModRewrite: 0.5.3

[xmurrix]

Ich habe das Plugin wie beschrieben installiert und aktiviert, doch sobald ich die .htaccess in den /cms Ordner kopiere, erhalte ich nur einen Internal Server Error. Was mache ich denn hier falsch?

Hast du auch die Pfade in der .htaccess angepasst? Wenn die .htaccess in das Mandantenverzeichnis kommt, und das Mandantenverzeichnis das Documentroot ist, musst du die .htaccess anpassen.

Falls du aber die Contenidoinstallation mit dem AMR-Plugin verwenden willst, kannst du entgegen dem, was ich gestern im andren Thread dir vorgeschlagen habe, alles in das Documentroot ablegen, auch die .htaccess. Dann kümmern sich die Regeln in der .htaccess und die Plugineinstellungen darum, dass in der Adresszeile des Browsers das cms/ nicht angezeigt wird.

Als Vorlage kannst dir das Contenido2Go unter http://forum.contenido.org/viewtopic.php?f=62&t=23203 Bundle herunterladen, um zu sehen, wie das funktioniert.

Ersetze ich nun die .htaccess durch eine leere htaccess und deaktiviere das Plugin, erhalte ich einen parse error:

Parse error: syntax error, unexpected T_OBJECT_OPERATOR in /mnt/web3/12/97/537497/htdocs/cms/front_content.php on line 202

Das ist eine Fehlermeldung, die Vermutlich mit dem Inhalt der Variablen "$cfgClient[$client]['htmlpath']['frontend']" in Zeile 202 zu tun hat, was steht da drin? mach mal testhalber eine Zeile vorher ein

Code: Alles auswählen

die($cfgClient[$client]['htmlpath']['frontend']);

Gruß
xmurrix

[xmurrix]

Hallo baumpaul,

Bei allen Links ist die Domain nur noch "www.domain.tdl/de/", der Ordnerpfad fehlt. Es wird nur die Sprache angezeigt. Ich habe es nun schon ein zweites mal ausprobiert und alle Dateien original neu hochgeladen. Der mr_test.php zeigt mir für alle Seiten auch nur die Sprache an.

die Ursache dafür könnten leere oder falsche Aliase für Kategorien und Artikel sein. Früher wurden die Aliase anhand der im Plugin definierten Trennzeichen zusammengebaut. Dies ist mittlerweile nicht mehr der Fall, d. h. Leerzeichen werden durch "-" ersetzt und Trenner für Pfade durch "/".

Vielleicht hilft auch das Zurücksetzen der Aliase in der Plugfinkonfiguration.

Gruß
xmurrix

[baumpaul]

Ja ich weiß schon. Die Aliase habe ich bereits zurückgesetzt und auch die Kategorien habe ich zum Test umbenannt. Nichts hat geholfen.

[xmurrix]

Ja ich weiß schon. Die Aliase habe ich bereits zurückgesetzt und auch die Kategorien habe ich zum Test umbenannt. Nichts hat geholfen.

Hmm, was spuckt das aktivieren des AMR-Debuggers denn aus? Zeile 52 in contenido/plugins/mod_rewrite/includes/config.plugin.php.

Da müsste das generierte SQL-Statement unter "ModRewriteUrlStack->_chunkSetPrettyUrlParts() $sql" angezeigt werden. Das kannst du ja an die DB schicken, um zu sehen, ob da was zurückkommt.

Vielleicht gibt es Hinweise dazu in der errorlog, interessant wäre auch die Ausgabe der Seite ohne aktiviertem AMR-Plugin, gibt es da eventuell Links mit front_content,.php, die nicht ganz der Norm entsprechen, z. B. front_content.php?idcat123?foo=bar?

Gruß
xmurrix