Plugin Advanced Mod Rewrite für Contenido 4.8.x

[smac]

Ich bekomme folgende Fehlermeldung

Code: Alles auswählen

Call to undefined function mr_query_n_next_record()


Die Seite davon läuft schon länger und der Fehler tritt "plötzlich" auf - also ohne Änderungen am CMS oder ählichen - ich kapier das nicht.

[xmurrix]

Ich bekomme folgende Fehlermeldung

Code: Alles auswählen

Call to undefined function mr_query_n_next_record()


Die Seite davon läuft schon länger und der Fehler tritt "plötzlich" auf - also ohne Änderungen am CMS oder ählichen...

Die Funktion gibt es in der Datei "/contenido/plugins/mod_rewrite/includes/functions.mod_rewrite.php", die Datei wird in "/contenido/plugins/mod_rewrite/includes/config.plugin.php" gleich am Anfang eingebunden und um das Einbinden einer Pluginkonfiguration kümmert sich Contenido.

Schlage vor, dass du die 3 Punkte mal genauer überprüfst. Wird die Pluginkonfiguration eingebunden, wird dort die functions.mod_rewrite.php eingebunden, gibt es in der functions.mod_rewrite.php die Funktion "mr_query_n_next_record()"?

Sollte das Problem weiterhin bestehen, bräuchte ich mehr Infos. Wo genau tritt der Fehler auf (Datei, Zeile) und welche Versionen von Contenido und dem Plugin verwendest du?

Gruß
xmurrix

[smac]

hallo xmurrix,

danke für deine so schnelle Antwort.

Schon mal gesehen das etwas "plötzlich" auftritt - ne, sorry war natürlich mein Fehler.

Ich hatte die Klasse "articellanguage" eingebunden, wie hier beschrieben (http://forum.contenido.org/viewtopic.php?t=22042) und hatte dabei die functions.mod_rewrite.php eines älteren Plugins erwischt (2.0 oder so) - da gab es diese Funktion noch nicht.

Sorry für die Umstände, aber danke für deine Antwort - sonst hätte ich das nie gefunden.

[Louis]

Bitte alle um etwas gedult, werde bald eine korrigierte Version bereitstellen.

Kein Problem, gut Ding will Weile haben

Wenn du sowieso dabei bist, könntest du dann bitte die Rewrite Rule noch um die Erweiterung JPG ergänzen? jpg und jpeg sind schon drin, aber meine Kamera benennt Bilder immer in Grossbuchstaben - und wenn ich die Bilder dann in Contenido einbinde werden sie nicht mehr angezeigt (weil die Rewrite Rule die Erweiterung .JPG ignoriert)
Also einfach

Code: Alles auswählen

# One RewriteRule to rule them all
# --------------------------------
RewriteRule !\.(js|ico|gif|jpg|JPG|jpeg|png|css|pdf)$ index_controller.php [QSA,L]

Danke!

[xmurrix]

...Wenn du sowieso dabei bist, könntest du dann bitte die Rewrite Rule noch um die Erweiterung JPG ergänzen? jpg und jpeg sind schon drin, aber meine Kamera benennt Bilder immer in Grossbuchstaben - und wenn ich die Bilder dann in Contenido einbinde werden sie nicht mehr angezeigt (weil die Rewrite Rule die Erweiterung .JPG ignoriert)

Hallo Louis,

das ist eine gute Idee und sollte in die RewriteRule übernommen werden. Sind die Bilder denn nicht im upload-Ordner drin? Dieser Ordner wird nähmlich vom Umschreiben ausgeschlossen.

Möglich wäre auch die Option NC zum Ignorieren der Groß-/Kleinschreibung:

Code: Alles auswählen

RewriteRule !\.(js|ico|gif|jpg|jpeg|png|css|pdf)$ index_controller.php [NC,QSA,L]


Ist nicht getestet, sollte aber gehen.

Gruß
xmurrix

[rethus]

Hallo Xurmix,
ich hab mir jetzt nicht den ganzen Tread durchgelesen, aber hab hier mal einen top Vorschlag, der vielen Usern (mit Serverzugriff) eine riesen Hilfe sein wird:


Die meisten Systeme basieren ja auf Linux. Daher bietet es sich an, das Patchsystem für Linux zu nutzen. Es ist ganz easy, sowohl diff-Patches zu erstellen, als auch diese dann einzuspielen.
Der Clou dabei ist, das man ein Patch so einspielen kann, dass die überspielten dateien mit dem postfix: org (für orginal) im gleichen Verzeichnis gesichert werden.

Was hältst du von der Idee?
Ich arbeite schon einige Zeit damit, um eine Standard-Contenido-Installation auf mein selbst angepasstes System zu patchen.

[xmurrix]

...
Die meisten Systeme basieren ja auf Linux. Daher bietet es sich an, das Patchsystem für Linux zu nutzen. Es ist ganz easy, sowohl diff-Patches zu erstellen, als auch diese dann einzuspielen.
Der Clou dabei ist, das man ein Patch so einspielen kann, dass die überspielten dateien mit dem postfix: org (für orginal) im gleichen Verzeichnis gesichert werden...

Generell bin ich immer für eine Erleichterung, sei es bei der Entwicklung oder später für die User.

Als Windows-User kenne ich mich in der Linux-Welt nicht sehr gut aus - Dein Vorschlag, bei Änderungen ein diff-Patch einzuspielen, würde sehr wahrscheinlich auch nur unter Linux funktionieren, vielleicht auch unter OS X, aber unter Windows wird das ohne Weiteres nicht möglich sein oder? Höchstens, wenn man Cygwin hat...

Dann wird das sicherlich nur über Shell mit (SSH-Zugriff) machbar sein, überfordert das nicht die meisten User?

Eine einfache Lösung, die Systemunabhängig und auch für jeden Einfach zu Bedienen ist, wäre mir lieber. Das geht aber wahrscheinlich eher in die Richtung Plugin-/Modulinstaller, den man über das Backend bedienen kann.

Werde mich mal über diff-Patches schlau machen.

Gruß
xmurrix

[Louis]

Hallo Louis,

das ist eine gute Idee und sollte in die RewriteRule übernommen werden. Sind die Bilder denn nicht im upload-Ordner drin? Dieser Ordner wird nähmlich vom Umschreiben ausgeschlossen.

Möglich wäre auch die Option NC zum Ignorieren der Groß-/Kleinschreibung:

Code: Alles auswählen

RewriteRule !\.(js|ico|gif|jpg|jpeg|png|css|pdf)$ index_controller.php [NC,QSA,L]


Ist nicht getestet, sollte aber gehen.

Gruß
xmurrix

Die erste gute Nachricht: NC funktioniert und ist damit dann wohl die bessere Lösung.

Die zweite gute Nachricht: Ich habe meinen eigenen Fehler gefunden - ich hatte mich in der .htaccess mit den Pfadangaben verheddert
Aber zum Glück bin ich ja auch nur Anwender, deswegen muss ich ja nicht alles immer gleich sofort durchschauen......
Statt

Code: Alles auswählen

# Specify a base URL-path for the rules
# -------------------------------------
RewriteBase /cms/

# Exclude some files and directories from rewriting
# -------------------------------------------------
RewriteRule ^usage/.*$ - [L]
RewriteRule ^contenido/.*$ - [L]
RewriteRule ^setup/.*$ - [L]
RewriteRule ^upload/.*$ - [L]

hatte ich

Code: Alles auswählen

# Specify a base URL-path for the rules
# -------------------------------------
RewriteBase /cms/

# Exclude some files and directories from rewriting
# -------------------------------------------------
RewriteRule ^usage/.*$ - [L]
RewriteRule ^contenido/.*$ - [L]
RewriteRule ^setup/.*$ - [L]
RewriteRule ^cms/upload/.*$ - [L]


Falls also jemand jemals in eine ähnliche Situation kommen sollte hier nochmal der ausdrückliche Hinweis:
RewriteBase + der Pfad in RewriteRule = voller Pfad zur Datei
In meinem Fall hätte das Bild in meinedomain.de/cms/cms/upload liegen müssen, dann wäre auch nichts umgeschrieben worden. Tatsächlich steht es aber in meinedomain.de/cms/upload und fällt damit voll unter ModRewrite.

[mojo]

Was mir aber noch aufgefallen ist:
Die Weiterleitung scheint nicht mehr zu gehen.
Wenn ich als Weiterleitungsziel zb: front_content.php?idcat=xx setze, bleibt die Seite leer

habe den Quellcode zwar nur kurz überflogen, aber bei mir funktioniert es jetzt nachdem ich in der \cms\front_content.php Zeile 939 angepasst habe

Code: Alles auswählen

$redirect_url = CEC_Hook::execute('Contenido.Frontend.CreateURL', $url);

ändern auf

Code: Alles auswählen

$redirect_url = CEC_Hook::execute('Contenido.Frontend.CreateURL', $redirect_url);

[xmurrix]

...
habe den Quellcode zwar nur kurz überflogen, aber bei mir funktioniert es jetzt nachdem ich in der \cms\front_content.php Zeile 939 angepasst habe

Code: Alles auswählen

$redirect_url = CEC_Hook::execute('Contenido.Frontend.CreateURL', $url);

ändern auf

Code: Alles auswählen

$redirect_url = CEC_Hook::execute('Contenido.Frontend.CreateURL', $redirect_url);

...

Hallo mojo,

danke für den Hinweis, die Zeile in front_content.php 939 macht so natürlich keinen Sinn, es muss $redirect_url anstatt $url übergeben werden.

@wewo:
Sorry, das war keine Absicht von mir, diesen Bug habe ich schlichtweg komplett vergessen.

Grüße
xmurrix

[MikeGeorg]

merhaba murat,

erstmal herzlichen dank für das modul.
nach längerem ausprobieren auf einer neuinstallerten 4.8.7 version, hat es endlich geklappt.

nur bei dem wechsel zur englischen sprache wird eine endlosschleife erzeugt.

habe beide varianten in der spracheinstellung ausprobiert,leider ohne erfolg.
htaccess datei direkt im root
index.php mit location header cms/front_page.php

woran könnte das liegen?
hier die original test webseite.
http://www.travelto.la

gruß aus thailand
mike

[xmurrix]

...
nur bei dem wechsel zur englischen sprache wird eine endlosschleife erzeugt.

habe beide varianten in der spracheinstellung ausprobiert,leider ohne erfolg.
htaccess datei direkt im root
index.php mit location header cms/front_page.php

woran könnte das liegen?

Hallo mike,

der Fehler wird an der Definition der Weiterleitung liegen, d. h. das Plugin kann die Weiterleitung nicht umschreiben.

Auf die Schnelle sollte es reichen, wenn du in Artikeleigenschaften die Weiterleitung

Code: Alles auswählen

./front_content.php?idcat=1&changelang=2


in

Code: Alles auswählen

front_content.php?idcat=1&changelang=2


änderst.

Das Plugin erkennt die URL wegen dem vorangestellten "./" nicht. Das könnte ich in der nächsten Version abfangen, bis dahin interne URLs immer mit front_content.php... angeben.

Gruß
xmurrix

[MikeGeorg]

...
nur bei dem wechsel zur englischen sprache wird eine endlosschleife erzeugt.

habe beide varianten in der spracheinstellung ausprobiert,leider ohne erfolg.
htaccess datei direkt im root
index.php mit location header cms/front_page.php

woran könnte das liegen?

Hallo mike,

der Fehler wird an der Definition der Weiterleitung liegen, d. h. das Plugin kann die Weiterleitung nicht umschreiben.

Auf die Schnelle sollte es reichen, wenn du in Artikeleigenschaften die Weiterleitung

Code: Alles auswählen

./front_content.php?idcat=1&changelang=2


in

Code: Alles auswählen

front_content.php?idcat=1&changelang=2


änderst.

Das Plugin erkennt die URL wegen dem vorangestellten "./" nicht. Das könnte ich in der nächsten Version abfangen, bis dahin interne URLs immer mit front_content.php... angeben.

Gruß
xmurrix

hallo xmurix,

alles bestens jetzt nach der änderung.
herzlichen dank.

gruß mike

[BagHira]

Hallo xmurrix,

hab ne Frage an dich

Werden bei der deinstallation der Plugin-Version 0.3.3 (installiert auf 4.8.6) "alle" Änderungen an der DB bzw. den Files rückgängig gemacht?

Siehe: viewtopic.php?t=22263

Habe zur Zeit Probleme mit einem Upgrate von 4.8.6 auf 4.8.7.

[xmurrix]

...
Werden bei der deinstallation der Plugin-Version 0.3.3 (installiert auf 4.8.6) "alle" Änderungen an der DB bzw. den Files rückgängig gemacht?
...

Hallo,

das Plugin setzt die an der Datenbank durchgeführten Änderungen zurück, die Sourcen werden nicht zurückgesetzt - Das muss man manuell machen.

Dein Problem scheint aber einen anderen Grund zu haben, es wird wohl nicht am Plugin liegen, das Setup lässt sich folgendermaßen debuggen:

Öffne die Datei /setup/templates/setup/forms/installer.tpl und ändere die Zeile 23

Code: Alles auswählen

<iframe style="width: 500px; height: 100px; visibility:hidden;" src="{DBUPDATESCRIPT}"></iframe>


in

Code: Alles auswählen

<iframe style="width: 600px; height: 300px; " src="{DBUPDATESCRIPT}"></iframe>


Dann sollte der Grund sichbar werden, warum sich das Setupscript aufhängt.

Gruß
xmurrix