Seite 13 von 88
Call to undefined function mr_query_n_next_record()
Verfasst: Di 5. Aug 2008, 13:18
von malsdgtac
Ich bekomme folgende Fehlermeldung
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.
Re: Call to undefined function mr_query_n_next_record()
Verfasst: Di 5. Aug 2008, 14:12
von xmurrix
smac hat geschrieben:Ich bekomme folgende Fehlermeldung
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
Verfasst: Di 5. Aug 2008, 15:08
von malsdgtac
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.
Verfasst: Do 7. Aug 2008, 22:14
von Louis
xmurrix hat geschrieben: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!
Verfasst: Fr 8. Aug 2008, 10:43
von xmurrix
Louis hat geschrieben:...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
Verfasst: Fr 8. Aug 2008, 11:04
von 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.
Verfasst: Fr 8. Aug 2008, 13:50
von xmurrix
rethus hat geschrieben:...
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
Verfasst: So 10. Aug 2008, 18:37
von Louis
xmurrix hat geschrieben: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.
Verfasst: Mi 13. Aug 2008, 09:14
von mojo
wewo hat geschrieben:
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);
Verfasst: Mi 13. Aug 2008, 10:06
von xmurrix
mojo hat geschrieben:...
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
Endlosschleife bei Sprachauswahl
Verfasst: Mi 13. Aug 2008, 16:48
von 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
Re: Endlosschleife bei Sprachauswahl
Verfasst: Mi 13. Aug 2008, 17:43
von xmurrix
MikeGeorg hat geschrieben:...
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
in
ä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
Re: Endlosschleife bei Sprachauswahl
Verfasst: Mi 13. Aug 2008, 18:22
von MikeGeorg
xmurrix hat geschrieben:MikeGeorg hat geschrieben:...
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
in
ä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
Verfasst: Do 14. Aug 2008, 06:53
von 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:
http://forum.contenido.org/viewtopic.php?t=22263
Habe zur Zeit Probleme mit einem Upgrate von 4.8.6 auf 4.8.7.
Verfasst: Do 14. Aug 2008, 09:53
von xmurrix
BagHira hat geschrieben:...
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