Ich weiß gar nicht, ob Sie's schon wussten ...
Gerade habe ich für die Beantwortung einer Useranfrage in einer Testinstallation mal schnell eine Seite mit Namen "advancedform" angelegt und dort den Pluginaufruf {{{PLUGIN:advancedform('Contact');}}} platziert.
Lustig:
Mit normalen Mitteln kommt man im Adminmodus nicht mehr an die Seite (den Seiteninhalt) heran. Egal, ob Vorschau oder Bearbeiten-Modus: Immer wird nur die Plugin-Administration angezeigt. (ausgeloggt ist alles OK)
Ich denke, es wird eher sehr selten vorkommen, dass jemand einen Seitennamen wählt, der exakt dem des Plugins entspricht.
Falls doch - so wie eben bei mir - dann gibts Ärger und Tränen
Wäre das irgendwie vom Core her vermeidbar?
Seitenname = Pluginname
Re: Seitenname = Pluginname
Das gabs doch schon mal. Ist systembedingt und wohl nicht (so einfach) änderbar.
Re: Seitenname = Pluginname
Dachte ich's mir doch. 2009!
Ich denke auch, dass das nicht so leicht zu ändern ist.
Selbst, wenn der Pagemanager beim Seitenanlegen meckerte - installiert man später ein Plugin mit passendem Namen, dann knallts wieder.
Und auch eine "Bad-Words"-Liste nützt nichts, weil man nicht alles voraussehen kann.
Vielleicht könnte Hartmut in der Doku so etwas ähnliches wie: "Bekannte Probleme" aufnehmen, damit User, die wirklich mal in eine solche Situation kommen, dort nachschauen können - und nicht verzweifeln.
Re: Seitenname = Pluginname
Genau. Grundproblem ist, dass der erste Query-Parameter, falls ohne =Wert angegeben, immer als Seitenname interpretiert wird, aber auch diverse „interne“ Variablen gesetzt werden, wenn ein entsprechender Query-Parameter ohne =Wert irgendwo in der URL vorhanden ist. Das könnte man theoretisch leicht lösen, aber das führte zu einem insgesamt recht heftigen BC break (so manche Bookmarks würden nicht mehr funktionieren, und bei den meisten Plugins müsste nachgebessert werden). Eine vielleicht verkraftbare Besserung wäre es, wenn wir allen speziellen Seitennamen ein xh voranstellen.
Man könnte sich das neue XH_wantsPluginAdministration(), das ja leider auch viel Leid verursacht macht, zu nutze machen. Ersetze doch mal diese Zeile durch:frase wrote: ↑Thu May 31, 2018 5:48 amGerade habe ich für die Beantwortung einer Useranfrage in einer Testinstallation mal schnell eine Seite mit Namen "advancedform" angelegt und dort den Pluginaufruf {{{PLUGIN:advancedform('Contact');}}} platziert.
Lustig:
Mit normalen Mitteln kommt man im Adminmodus nicht mehr an die Seite (den Seiteninhalt) heran. Egal, ob Vorschau oder Bearbeiten-Modus: Immer wird nur die Plugin-Administration angezeigt. (ausgeloggt ist alles OK)
Code: Select all
return (bool) preg_match('/(?:&)' . preg_quote($pluginName, '/') . '(?=&|$)/', sv('QUERY_STRING'));
Christoph M. Becker – Plugins for CMSimple_XH
Re: Seitenname = Pluginname
Und genau darum - und eben aus Zeitgründen - habe ich jetzt nicht weiter getestet.
Es ist ja eigentlich nur ein theoretisches Problem und mit einer Seitennamensänderung leicht behoben.
Ihr XH-Programmierer könntet das aber im Auge behalten. Einen großen BC-break möchte ich allerdings nicht provozieren. Wir sind ja noch nicht mal mit dem Wechsel zu 1.7 und allen Plugins fertig.
Re: Seitenname = Pluginname
Ich hab's mal mit Fa_XH ausprobiert (also Seitename fa), und soweit funktioniert es.
Na ja, so theoretisch ist es eben nicht. Außer manu ist zumindest auch kurtm darüber gestolpert. Schlimmer: damit hängt auch das $s Problem zusammen, das wir wirklich in den Griff bekommen sollten.
Wir sollten! Zumindest wäre es sehr sinnvoll möglichst bald eine Möglichkeit anzubieten, die von Plugins genutzt werden kann, damit an diesen nicht später nachgebessert werden müsste.
Christoph M. Becker – Plugins for CMSimple_XH