Plugin Advanced Mod Rewrite für Contenido 4.8.x

[Horst Wiese]

hallo baghira,

hier im forum hatte ich dazu nix mehr gefunden,
aber murat konnte mir weiterhelfen,
ist ja doch keine hexerei.

dank euch allen,
horst

[Oldperl]

Hallo Horst,

aber murat konnte mir weiterhelfen,

Und wie? Läßt du uns auch dran teilhaben?

Gruß aus Franken

Ortwin

[Horst Wiese]

Gerne:

• Download der alten mod_rewrite-Version (leider hier im forum nicht mehr da, daher die hilfe von murat)

• dateienvergleich im contenido-ordner zwischen der 4.6.15-Version mit und ohne mod-rewrite

• ersetzen der entsprechenden dateien im contenido-ordner (mr-dateien raus, original-dateien wieder rein)

• und schon ist das 4.6.15'er mod_rewrite entfernt

• upgrade und einrichtung des 4.8.12'er mod_rewrite wie gehabt

ciao,
horst

[BagHira]

Ersetzte die Dateien aus Steses Packet mit den Orginal Contenido-Dateien.

Sach ich doch

[thepoet]

Irgendwie artet sich das hier zu einem Monsterthread aus, in dem kunterbunt die verschiedensten Problemchen zum Thema AMR diskutiert werden. Dabei gehen IMHO einige Probleme unter und werden Lösungen immer schwerer zu finden, deshalb würde ich mir wünschen, wenn für neue Probleme auch neue Threads aufgemacht werden.

[stzadmin]

Hallo Contenido-User,

Zuerst mal Respekt, ich habe eben die 61 Seiten hier gelesen, der Herr "xmurrix" gibt sich hier wirklich schon über Jahre die größte Mühe!

Ich hoffe, mein kleines, bescheidenes Problem kann von Euch gemeinsam ebenso schnell behoben werden wie die vielen anderen
Es ist auch nur ein relativ simples Problem, allerdings weiss ich nicht recht wo ich das anpacken soll (und konnte hier auch keine Lösung finden).

Eckdaten: Contenido 4.8.11 + AMR 0.5.3
Das System läuft schon länger produktiv und der *Fehler* ist bisher nicht aufgefallen. Ich habe eine lokale Kopie gezogen und auf AMR 0.5.4 upgegraded um das Problem genauer zu beleuchten. Die .htaccess ist eine Kopie der Restriktiven, Contenido ist normal installiert...
wwwroot
cms
contenido
usw

Folgende Sache:
Es sollen die Fehlerseiten von Contenido zum Einsatz kommen - jederzeit!

Beispiel:
http://testdomain/deutsch/produkte/produkt.html --> korrekt - die Seite wird angezeigt
http://testdomain/deutsch/produkte/produkt234.html --> falsch - die Fehlerseite wird angezeigt
http://testdomain/blabla --> falsch weil nicht vorhanden --> die Fehlerseite SOLLTE angezeigt werden --> aber leider wird die Startseite wird angezeigt

Wie kann ich das problemfrei lösen?
Ansonsten funktioniert die Seite und vor allem das Plugin einwandfrei - nur diese kleine Korrektur fehlt noch...

[Oldperl]

Hallo,

da gabs in der 4.8.11 einen Bug wegen idcat und idart der Fehlerseite. Ich weiß nicht genau ob der in der 4.8.12 schon behoben ist, aber da gibts einen Post dazu im Bugforum, wenn du da mal schaun würdest.

Gruß aus Franken

Ortwin

[xmurrix]

...
Beispiel:
http://testdomain/deutsch/produkte/produkt.html --> korrekt - die Seite wird angezeigt
http://testdomain/deutsch/produkte/produkt234.html --> falsch - die Fehlerseite wird angezeigt
http://testdomain/blabla --> falsch weil nicht vorhanden --> die Fehlerseite SOLLTE angezeigt werden --> aber leider wird die Startseite wird angezeigt

Wie kann ich das problemfrei lösen?...

Hallo stzadmin,

kann man als Fehlerquelle ausschließen, dass die Testurl "/blabla" nicht der Kategorie der Startseite ähnelt. In den Pluginoptionen lässt sich einstellen, in wie weit ähnliche URLs dennoch zum Ziel finden sollen.

Du kannst auch den Debugger des Plugins aktivieren, um zu erkennen, wie die ankommende URL aufgelöst wird.
In contenido/plugins/mod_rewrite/includes/config.plugin.php ab ca. Zeile 69, sind die Optionen des Debuggers. Dort den Wert für 'enable' auf true setzen.

In der Ausgabe des Debuggers sind dann die Einträge interessant, die mit "ModRewriteController->..." beginnen. Ds kommen gleich am Anfang vor.
Einträge, die mit "mr $..." beginnen, ca 11. bis 15., enthalten letztendlich die ermittelten Werte für Artikelid, Kategorieid, usw...

Gruß
xmurrix

[stzadmin]

Hallo xmurrix,

Den Prozentsatz habe ich jetzt auf 100 gestellt und benutze nun beispielsweise
http://testdomain/xmurrix
Ähnlich klingende Kategorien sollten somit ausgeschlossen sein.

Den Debugmodus hab ich aktiviert - ich poste hier einfach mal die entsprechenden Ausgaben mit im Backend aktivierter Fehlerseite:

Code: Alles auswählen

 front_content_controller.php mod rewrite config

Array (
    [use] => 1
    [rootdir] => /
    [checkrootdir] => 1
    [startfromroot] => 0
    [prevent_duplicated_content] => 0
    [use_language] => 1
    [use_language_name] => 1
    [use_client] => 0
    [use_client_name] => 0
    [use_lowercase_uri] => 1
    [category_seperator] => /
    [category_word_seperator] => -
    [article_seperator] => /
    [article_word_seperator] => -
    [file_extension] => .html
    [category_resolve_min_percentage] => 100
    [add_startart_name_to_url] => 1
    [default_startart_name] => index
    [rewrite_urls_at_congeneratecode] => 0
    [rewrite_urls_at_front_content_output] => 1
    [routing] => Array (
        )

    [redirect_invalid_article_to_errorsite] => 1
)

♦ ModRewriteController::_extractRequestUri() $this->_aParts

Array (
    [0] => xmurrix
)

♦ ModRewriteController->_setIdart $idart

ModRewriteController->_setIdart $idart = is_null

♦ ModRewriteController::execute() _setIdart

Array (
)

♦ mr $mr_preprocessedPageError
source: /contenido/plugins/mod_rewrite/includes/front_content_controller.php

mr $mr_preprocessedPageError = is_null

♦ mr $idart
source: /contenido/plugins/mod_rewrite/includes/front_content_controller.php

mr $idart = is_null

♦ mr $idcat
source: /contenido/plugins/mod_rewrite/includes/front_content_controller.php

mr $idcat = is_null

♦ mr $lang
source: /contenido/plugins/mod_rewrite/includes/front_content_controller.php

mr $lang = 4

♦ mr $client
source: /contenido/plugins/mod_rewrite/includes/front_content_controller.php

mr $client = 1

♦ mr_runFrontendController() total time

mr_runFrontendController() total time = 0.0019

♦ Contenido_UrlBuilder_MR::buildUrl() $params

Array (
    [client] => 1
    [idcat] => 29
    [idart] => 32
    [lang] => 4
    [error] => 1
)

♦ ModRewriteUrlStack->_chunkSetPrettyUrlParts() $sql

ModRewriteUrlStack->_chunkSetPrettyUrlParts() $sql = SELECT
        al.idartlang, al.idart, al.idlang as lang, al.urlname, cl.idcatlang, cl.idcat,
        cl.urlpath, ca.idcatart
FROM
        con_art_lang AS al, con_cat_lang AS cl, con_cat_art AS ca
WHERE
        al.idart = ca.idart AND
        ca.idcat = cl.idcat AND
        al.idlang = cl.idlang AND
        ( (al.idart = 32 AND al.idlang = 4) )

♦ ModRewriteUrlStack->_chunkSetPrettyUrlParts() $aNewStack

Array (
    [idart_32_lang_4] => Array (
            [urlpath] => Freeflow/Error
            [urlname] => Errorpage
        )

)

♦ Contenido_UrlBuilder_MR::buildUrl() in -> out

Array (
    [in] => Array (
            [client] => 1
            [idcat] => 29
            [idart] => 32
            [lang] => 4
            [error] => 1
        )

    [out] => http://testdomain/deutsch/error/errorpage.html?error=1
)

Mandant, Kategorie, Artikel und Sprache stimmt mit dem oben genannten Array überein - merkwürdig ist, dass weiter oben werte mit is_null geliefert werden - aber das gehört sicher so...
Könnt Ihr damit etwas anfangen?

Edit:
Ich kann noch hinzufügen, dass zB generierte URLs wie folgt ausehen
http://testdomain/deutsch/produkte/index.html

http://testdomain/deutsch/ ist also gültig - wie auch http://testdomain/english/ (englischer content wird angezeigt)
http://testdomain/xmurrix/ jedoch landet wieder auf der Startseite - statt die Fehlerseite zu zeigen.
Vllt könnte das ja auch mittels zusätzlicher Rewrites gelöst werden...

[stzadmin]

Zweifelsfrei ist der Fehler weg sobald das Voranstellen der Sprache im backend deaktiviert wird.

Kann das jmd bestätigen??

Edit:
Jegliches Voranstellen (Mandant oder Sprache) verursacht das genannte Verhalten...

[xmurrix]

...Zweifelsfrei ist der Fehler weg sobald das Voranstellen der Sprache im backend deaktiviert wird.

Kann das jmd bestätigen??...

Ja, kann das Bestätigen. Sobald der URL die Sprache oder der Mandant vorangestellt wird, funktioniert die Fehlererkennung in "contenido/plugins/mod_rewrite/classes/class.modrewritecontroller.php" nicht richtig.

Kann dir einen Hack anbieten, der das Problem lösen sollte.
Öffne die "contenido/plugins/mod_rewrite/classes/class.modrewritecontroller.php" und erweitere das Ende der Funktion execute() von

Code: Alles auswählen

        ...
        $this->_setIdart();

        parent::$_oDebug->addDebug($this->_aParts, 'ModRewriteController::execute() _setIdart');

        $this->_postValidation();
    }

in

Code: Alles auswählen

        ...
        $this->_setIdart();

        parent::$_oDebug->addDebug($this->_aParts, 'ModRewriteController::execute() _setIdart');

        // last check
        $idart = $this->getIdArt();
        $idcat = $this->getIdCat();
        if ($this->_sIncommingUrl && $this->_sIncommingUrl !== '/' && $idart == 0 && $idcat == 0) {
            // we have a incomming url but no idcat and/or idart
            $this->_bError = true;
        }
        
        $this->_postValidation();
    }

Wie gesagt, das ist ein Hack, os sich das dann negativ auf andere Einstellungen auswirkt, kann ich Momentan nicht sagen.

Ich werde mir das noch näher ansehen, danke für die Hinweise.

Gruß
xmurrix

[stzadmin]

Hallo xmurrix,

Danke dass du dich dem Problem angenommen hast. Ich hab schon an mir gezweifelt und zwischenzeitlich testweise auch den ganzen Auftritt auf die aktuellsten Versionen gebracht, jedoch ohne Erfolg in dieser Sache.

Dein Hack hab ich eben eingebaut - nun wird tatsächlich
http://testdomain/xmurrix auf die Fehlerseite umgeleitet.
Allerdings scheint das immer die Errorseite von Sprache 1 zu sein (in meinem Fall 'english') - kann man dagegen etwas tun?

Falls dir dazu noch etwas einfallen sollte - ich würde mich freuen.

Etwas anderes:
ich habe in der functions.api.string.php das kleine ü mit eingebaut - wegen dem Punkt "über-uns" in der Navi ganz sinnvoll. Die URL wird nun auch mit ueber-uns generiert.
Nach Leeren von con_code, cms/cache und aliases zurücksetzen kann ich nun den Startartikel nicht mehr aufrufen bzw lande @ error wo zuvor unter "ber-uns/index.html" noch eine Seite existierte. Muss ich noch etwas beachten? Habe den Startartikel mal auf Verdacht offline und online genommen und auch eine andere Startseite deklariert. Leider klappt das alles nicht... muss ich das ue bzw ü wieder aus der Datei rausnehmen bzw sind da Probleme bekannt?

Ich bedanke mich schon mal für deine Mühe - kompetent und schnell wie mans selten erlebt!!

[Oldperl]

Etwas anderes:
ich habe in der functions.api.string.php das kleine ü mit eingebaut - wegen dem Punkt "über-uns" in der Navi ganz sinnvoll. Die URL wird nun auch mit ueber-uns generiert.
Nach Leeren von con_code, cms/cache und aliases zurücksetzen kann ich nun den Startartikel nicht mehr aufrufen bzw lande @ error wo zuvor unter "ber-uns/index.html" noch eine Seite existierte. Muss ich noch etwas beachten?

Unter Content->Kategorien die Aliase prüfen, gegebenenfalls neu schreiben.
Im Backend beim AMR-Plugin die Aliase neu erzeugen lassen.

Gruß aus Franken

Ortwin

[xmurrix]

...Allerdings scheint das immer die Errorseite von Sprache 1 zu sein (in meinem Fall 'english') - kann man dagegen etwas tun?...

Das habe ich befürchtet, das Problem lässt sich nicht einfach mit ein paar Zeilen gehacktes beheben - wrird eine etwas aufwändigere Sache, daher bitte ich um Geduld...

...ich habe in der functions.api.string.php das kleine ü mit eingebaut - wegen dem Punkt "über-uns" in der Navi ganz sinnvoll. Die URL wird nun auch mit ueber-uns generiert.
...
Habe den Startartikel mal auf Verdacht offline und online genommen und auch eine andere Startseite deklariert. Leider klappt das alles nicht... muss ich das ue bzw ü wieder aus der Datei rausnehmen bzw sind da Probleme bekannt?

Läuft die Seite vielleicht unter UTF-8?
Falls ja, könnte die Funktion capiStrCleanURLCharacters() die Ursache sein. Die findest du unter contenido/includes/functions.api.string.php.
[nachtrag]
Das preg_replace() darin könnte nicht UTF-8 sicher sein, vielleicht hilft der u Modifizierer '/^[a-z0-9]*$/iu'.

Oder dein Editor hat das Encoding der Seite functions.api.string.php in UTF-8 umgewandelt, das sollte bei ANSI bleiben.
[/nachtrag]

Gruß
xmurrix

[stzadmin]

Hallo xmurrix,

ich habs nicht extrem eilig - ich freu mich aber, dass ich etwas Neues gefunden habe und du dich der Sache annimmst.
Evtl ist das ja ein Release 0.5.5 Wert *ggg* - aber nun Spass beiseite....

Die Seite läuft meines Wissens nicht unter UTF-8 - könnte man das eigentlich im Backend einstellen? Hab noch keine Option dafür gefunden. Da die Seite aber schon über längeren Zeitraum (4.6.x) mit Inhalt gefüllt wird - werde ich "einen Teufel tun" bzgl Encoding Hand anzulegen.

Der SSH Zugang zum System ist UTF8 - daher hab ich die Datei lokal mittels gedit bearbeitet. Eben habe ich die von mir modifizierte Datei nochmals mit Scite gegen geprüft - das Encoding steht hier jedenfalls nicht auf UTF8. Ich hab nun den Modifier u noch eingebaut und die Seite mit dem Encoding "Code Page Property" gespeichert. Ich gehe davon aus, dass dies ANSI ist - die Umlaute sind zu lesen und nicht zerstört.
Ich werd erst später dazu kommen diesen Umstand zu prüfen.

Ansonsten hab ich natürlich die Aliase zurückgesetzt und in Content --> Kategorien ist korrekt ueber-uns eingetragen. Was ich auch noch testen konnte - dank mr_test.php stehen ja die generierten Links zur Verfügung - die Unterseiten der Kategorie sind von dort aus korrekt aufrufbar. Das Problem bezieht sich komischerweise nur auf die Startseite - ohne aktivierem AMR funktioniert komischerweise auch alles wie gewünscht. Bald weiß ich mehr... hoff ich =)

Jedenfalls dickes Danke für die Hilfestellungen!