CMSimple_XH–Forum

Einma aufs Erste ein Riesenbock von mir. Ich teste nicht in index.php, sondern in admin.php! Kein Wunder bringt der wget ein 404. Er ist ja nicht eingeloggt. . Soviel mal zu dem. Beim befüllten Puffer teste ich weiter.

Zum befüllten Ausgabepuffer ebenfalls Entwarnung und neue Erkenntnisse bei mir.
Aus unerfindlichen Gründen war ich der Ansicht, dass ich zwingend den plugin parameter mitgeben muss, wenn ich eine Schnittstelle mittels weiterer $_GET Variable in admin.php ansprechen will. Aber das ist ja nicht so. Der plugin Parameter gibt lediglich und vor allem das Admin Menü aus (und das via var $o in den Ausgabepuffer, wahrscheinlich). In admin.php abgefangene $_GET Variablen werden global erkannt. Also hier die Variablennamen weise wählen. Punkt und aus.

EDIT;
Es fragt sich nach wie vor, ob bei API Abfragen ein vorheriges der Robustheit dient.

manu wrote: ↑

Sat Dec 15, 2018 9:25 am

Aus unerfindlichen Gründen war ich der Ansicht, dass ich zwingend den plugin parameter mitgeben muss, wenn ich eine Schnittstelle mittels weiterer $_GET Variable in admin.php ansprechen will. Aber das ist ja nicht so. Der plugin Parameter gibt lediglich und vor allem das Admin Menü aus (und das via var $o in den Ausgabepuffer, wahrscheinlich).

Genau. ($o wird schließlich von <?php echo content()?> ausgegeben.)

manu wrote: ↑

Sat Dec 15, 2018 9:25 am

In admin.php abgefangene $_GET Variablen werden global erkannt. Also hier die Variablennamen weise wählen. Punkt und aus.

Letzteres ja, ersteres ist aber nicht mehr so seit XH 1.7. Vorher wurden alle Query-String-Parameter ohne Gleichheitszeichen und Wert als globale Variable mit dem Wert string(4)"true" registriert. Allerdings ist es auch jetzt noch so, dass ein Query-String-Parameter mit dem Namen eines Plugins die Pluginadministration auslöst (wenn das Plugin XH_wantsPluginAdministration() aufruft); das war in deinem Fall mutmaßlich das Problem.

manu wrote: ↑

Sat Dec 15, 2018 9:25 am

Es fragt sich nach wie vor, ob bei API Abfragen ein vorheriges

Code: Select all

while (ob_get_level()) ob_end_clean();

der Robustheit dient.

Sollte man auf jeden Fall machen, wenn eine Funktion, die auch im Template aufgerufen werden kann, eine eigene Ausgabe erzeugt. In anderen Fällen ist es mit der Robustheit halt immer so eine Sache. Einerseits verhindert die Schleife fehlerhafte Ausgaben; andererseits verschleiert sie auch eben diesen Fehler an anderer Stelle. Ging mir gelegentlich bei JS-Scripten schon so, dass ich mich über ein try mit leerer catch-Klausel geärgert habe, weil ich beim Entwickeln lieber eine Fehlermeldung gehabt hätte, statt mich zu wundern, warum gar nichts passiert.