keine Anzeige - weißer Screen

[manni]

...hmmm. Dann werd ich die beiden nochmal vergleichen. Wärst Du bereit, eine neue Version des Loaders aufzuspielen, damit wir der Ursache auf den Grund gehen können?
Übrigens: die entscheidenden Plugins meta_tags und page_params erfordern den neuen Loader zwingend!
mvwd.

Hallo mvwd,

es stimmt, die Plugins meta_tags und page_params habe ich auch noch nicht aufgespielt. das hatte ich eigentlich heute vor, aber wird in diesem Fall wohl nicht entscheidend sein.

Eine neue Version spiele ich natürlich gerne auf, soll es eine besondere sein?

[mvwd]

Eine neue Version spiele ich natürlich gerne auf, soll es eine besondere sein?

...genau genommen drei oder vier . Ich hoffe Du schlägst micht nicht .

Wäre nett wenn Du nacheinander folgende Versionen der index.php des Loaders ausprobieren könntest:

• oc_pPC_index.zip
• wo_pPC_index.zip
• wo_pD_ index.zip (hier bitte beachten, daß keinerlei Plugins mehr im plugin-Ordner liegen!)
• debug_Loader_index.zip (hier wird Zeile für Zeile ausgegeben, wie weit der Loader abgearbeitet wurde)

Das sind ZIP-Pakete, die jeweils eine modifiziert index.php des Loaders enthalten, teilweise abzüglich der neuen Funktionen die vermutlich den Fehler verursachen. Am besten Du testest mit folgender Konfiguration: Order 'plugin' -> enthält ausschliesslich index.php + Ordner pluginloader (mit den dazugehörigen Unterordnern und Dateien).

Die Links zum Download der ZIP-Pakete schicke ich Dir per PM.
Vielen Dank im voraus.
mvwd.

[Gert]

Hallo Manni, du könntest Markus (mvwd) die Arbeit unwahrscheinlich erleichtern, wenn Du ihm für das Verzeichnis cmsxh einen ftp-Zugang einrichten würdest. Den kannst Du ja danach wieder löschen.

Wenn das bei Deinem Provider nicht geht, kannst Du ja auch das ftp-Passwort mal ändern für Markus, und danach wieder Dein altes einrichten. Dieses hin und her mit einem hohen Potential für Missverständnisse wird früher oder später nerven.

[mvwd]

...sodele.
Ich konnte das Problem erkennen, habe es auch gelöst. Die eigentliche Ursache aber blieb mir bisher noch verschlossen.
Aber jetzt wird's mir zu spät. Vielleicht krieg ich im ausgeschlafenen Zustand mehr heraus.

Ursache ist der böse 'open_basedir' vermutlich in Verbindung mit einer anderen php-Direktive.
Die einfachen require_once 'page_data_router.php'; des page_data:index.php bewirken folgendes:

Code: Select all

Warning: %v%v() [function.%v]: open_basedir restriction in effect. File(/page_data_router.php) is not within the allowed path(s): (/srv/www/vhosts/tbs-herne.de/httpdocs:/tmp) in /srv/www/vhosts/tbs-herne.de/httpdocs/cmsxh/plugins/pluginloader/page_data/index.php on line 7

Warning: %v%v() [function.%v]: failed to open stream: Operation not permitted in /srv/www/vhosts/tbs-herne.de/httpdocs/cmsxh/plugins/pluginloader/page_data/index.php on line 7

Fatal error: %v%v() [function.require]: Failed opening required 'page_data_router.php' (include_path=':./:.:') in /srv/www/vhosts/tbs-herne.de/httpdocs/cmsxh/plugins/pluginloader/page_data/index.php on line 7

...da zwingt einen PHP dazu, die includes komplett relativ anzugeben vom root bis zur Datei: require_once('./plugins/pluginloader/page_data/page_data_router.php');. was wiederum bei Mehrsprachigkeit Probleme macht. Daraus würde resultieren: require_once($pluginloader_cfg['folder_down'].'./plugins/pluginloader/page_data/page_data_router.php');...toll, wa?
Wobei ich mir noch nicht sicher bin, ob wir das Problem skriptseitig zu lösen haben oder dies eine (falsche/zu restriktive) Server-Einstellung ist, die der Hoster zu verantworten hat. In dieser Form jedenfalls habe ich das noch nicht gesehen.

UND: Damit dürfte sogut wie kein anderes Plugin laufen (sofern es include()/require() verwendet)....
UND NOCH BESSER: Das Problem wäre auch beim alten Loader aufgetreten, sobald ein Plugin (s.o.) ins Spiel kommt.

Wie gesagt. Momentan ist Feierabend. Ich schau morgen früh nochmal drauf. Evt. finden die Kollegen ja noch was zum Thema!?

@manni: Momentan habe ich eine Version, die zumindest in den Grundzügen funktioniert hochgeladen (CMSimple_XH + Pluginloader V.2.1.07 + Meta-Tags + Page-Parameters). Ausschlaggebend ist die Datei ./plugins/pluginloader/page_data/index.php . Wenn Du diese verwendest, funktioniert der Loader.
mvwd.

[Gert]

...da zwingt einen PHP dazu, die includes komplett relativ anzugeben vom root bis zur Datei: require_once('./plugins/pluginloader/page_data/page_data_router.php');. was wiederum bei Mehrsprachigkeit Probleme macht. Daraus würde resultieren: require_once($pluginloader_cfg['folder_down'].'./plugins/pluginloader/page_data/page_data_router.php');...toll, wa?

Hallo Markus, ich habe schon manchmal darüber nachgedacht, eine Variable $cf['install']['folder'] oder so einzuführen, von der aus man sicher referenzieren kann, auch bei Mehrsprachigkeit. Denn auch bei Rückwärtsreferenzierung mit ../ gibt es manchmal Probleme, siehe filemanager FCK:

http://www.cmsimpleforum.com/viewtopic. ... 1228#p6891

<EDIT> Der FCKeditor verwendet ja eine Variable $CMSimple_root_folder, die gibt es aber nur im edit mode, wenn der FCKeditor geladen ist. </EDIT>

Bei Verwendung einer Variablen wie $cf['install']['folder'] = "/meincmsimpleinstallfolder/"; oder $cf['install']['folder'] = "http://www.meinedomain.de/meincmsimpleinstallfolder/"; wird aus der relativen Referenz eine absolute Referenz, sowas mag ich sowieso lieber.

Dann muss der Anwender eben als erstes per Administration diese Variable definieren, mit "/meincmsimpleinstallfolder/" oder "http://www.meinedomain.de/meincmsimpleinstallfolder/". Bei anderen CMS muss man das auch machen. Vielleicht kann diese Variable ja auch von CMSimple_XH oder vom Pluginloader erzeugt werden. Jedenfalls beobachte ich immer wieder Referenzierungsprobleme, die damit zu tun haben, dass bei den sekundären Sprachen die index.php in einem Verzeichnis einer anderen Strukturebene ausgeführt wird.

Das Problem sind halt immer wieder die vielen unterschiedlichen Serverkonfigurationen, man staunt ja immer wieder, und der Trend scheint eher zu restriktiveren Einstellungen zu gehen ...

[mvwd]

Um ehrlich zu sein: Ich mag keine absolute Adressierung.
Wobei ich jetzt die Probleme mit FCK nicht beurteilen kann. Das ist nicht mein Spezialgebiet .
Vorteil von relativer Adressierung ligt auf der Hand: Ich kann hin und herkopieren, ohne jemals an der config was drehen zu müssen.

Ich habe momentan folgende defines erfolgreich getestet :

Code: Select all

define('CMSIMPLE_BASE', (strtolower($cf['language']['default'])==$sl?'./':'../'));
define('CMSIMPLE_PLUGIN_BASE', CMSIMPLE_BASE.$cf['plugins']['folder'].'/');

Damit kann dann jedes Plugin arbeiten. Die beiden lasse ich im Pluginloader erzeugen. Somit könne diese von allen Plugins und auch von page_data benutzt werden. Damit dürfte das Problem erschlagen sein (wobei weitere Tests noch ausstehen).
Trotzdem gehören solche defines in den core, also cms.php. vielleicht irgendwann mal!?

Gruß,
Markus.

[Holger]

Um ehrlich zu sein: Ich mag keine absolute Adressierung.

Ich auch nicht .

Das oben zitierte Problem mit dem FCK bezog sich auf ein "../../" in der URL, was mod_security nicht unbedingt mag.
Das war das Resultat von, sagen wir mal, "Bequemlichkeit" aus alten Zeiten und ist ja eigentlich schon gelöst bzw. werden im nächsten Release alle nötigen Änderungen enthalten sein.
Die gleiche Art der Referenzierung wird bzw. wurde noch an einigen weiteren Stellen innerhalb der Editorkonfiguration verwendet.

LG
Holger

[Gert]

Jo, also wie das gelöst wird, ist eigentlich egal, Variable, Konstante ...

Es braucht ganz einfach ein festes Verzeichnis, von dem aus man zuverlässig referenzieren kann, und zwar vorwärts (ohne ../). Sinnvollerweise sollte das das Installationsverzeichnis sein (CMSimpleRoot). Ursprünglich war das ja wohl mal $sn, bevor die Mehrsprachigkeit eingeführt wurde. Mit der Einführung der sekundären Sprachen taugt $sn dazu nicht mehr.

Trotzdem gehören solche defines in den core, also cms.php. vielleicht irgendwann mal!?

Da hast Du recht, aber solange die Plugins auch unter CMSimple 3.2 funktionieren sollen, geht das halt nicht. Da aber meta_tags und page_params sowieso den neuen PL brauchen, ist der PL schon die richtige Stelle.

Ich habe mal einfach eine Variable $CMSimpleRoot ausprobiert:

Code: Select all

$CMSimpleRoot = str_replace('/'.$sl.'/', "/", $sn);

einfach in die index.php des PL eingefügt.

Das scheint auch zu funktionieren: http://www.cmsimple-xh.de/xhtest/, die Variablen werden über dem Content angezeigt. Einfach die verschiedenen Sprachen anklicken und $sn und $CMSimpleRoot beobachten.

Nach meiner Meinung entsteht hier auch eine "absolute Referenzierung", weil aus dem Domain-Root heraus referenziert wird (/ ...). Trotzdem muss niemand in der config herumschreiben bei einem Umzug. Von der Variablen $CMSimpleRoot aus kann man dann sicher referenzieren, auch aus einer sekundären Sprache heraus.

[mvwd]

...tut mir leid, Gerd. Aber das funktioniert nicht. Zumindest bei mir nicht.
Und ich würde das nicht über eine Variable, sondern immer über eine Konstante regeln. Denn genau das ist sie ja: konstant. Und ein referenzieren über Schlüsselwort 'global' aus Funktionen heraus ist dann auch nicht nötig.

mvwd.

[Gert]

Unglaublich, aber bei mir funktioniert das hier, mehrsprachig und sowohl bei einer Installation im DomainRoot als auch in einem Unterverzeichnis:

Code: Select all

require_once($_SERVER['DOCUMENT_ROOT'].$CMSimpleRoot.'plugins/pluginloader/page_data/page_data_router.php');
require_once('plugins/pluginloader/page_data/page_data_model.php');
require_once('page_data_views.php');

Drei verschiedene Arten der Referenzierung, die erste mit meiner neuen Variablen. Ohne das $_SERVER['DOCUMENT_ROOT'] funktioniert es bei mir auch nicht. Die unterste, originale Schreibweise scheint ja auf Mannis Server nicht zu funktionieren, obwohl es eigentlich sollte ... womit wir wieder beim Thread wären.

Und ich würde das nicht über eine Variable, sondern immer über eine Konstante regeln.

Natürlich kann das auch eine Konstante sein, ist wohl sogar besser,

Gute Nacht, Gert

Nachtrag: Eine absolute Referenzierung (http:// ...) funktioniert an dieser Stelle (require_once()) nicht, deshalb geht wohl auch meine Variable nicht oder nur in Verbindung mit $_SERVER['DOCUMENT_ROOT'].