Fa_XH

[cmb]

Ich tue was ich kann!

Super, aber mach Dir keinen Streß. So wichtig dürfte Font Awesome für den Content nicht sein, und das Plugin kann ja immer noch nachgereicht werden.

[frase]

Tschuldijung, ich muss nochmal nerven.
Es geht weiterhin um das Fhs_adminmenu.

Ich denke, in den allermeisten Fällen kann man damit leben, dass man das Fa_XH Plugin eben erfordert, und keinen Fallback mit einem zusätzlich ausgelieferten Font Awesome realisiert.

Zur Not kann ein Plugin ja noch prüfen, ob das FA_XH - Plugin verfügbar ist und eine entsprechende Meldung ausgeben, wenn es fehlt. Je nach Art des Plugins könnte es so auch komplett die Arbeit verweigern.

Mittlerweile denke ich auch so.
Fhs_adminmenu sollte das Fa_xh-Plugin voraussetzen, damit FA nicht doppelt ausgeliefert/eingebunden werden muss.
Bleibt die Frage, wie stelle ich fest, ob Fa_xh installiert ist?
Christophs Vorschlag war ja schon ganz gut, hilft aber in der Praxis noch nicht weiter. Ich möchte den Usern nicht zumuten, dass sie auch noch functions.php ändern müssen, um das Plugin zu verwenden.
Statt nach einer vielleicht nicht vorhandenen Datei zu fragen (was dann eine Fehlermeldung verursacht), könnte man nicht fragen, ob irgendeine Variable aus dem FA_xh-Plugin bekannt ist?
Wenn ich mir laienhaft vorstelle, dass die Plugins in alphabetischer Reihenfolge aufgerufen werden, müsste das doch möglich sein - oder?
fa... kommt doch vor fhs...

Oder nochmal ganz einfach gefragt:
Wenn ein Plugin von einem anderen abhängt: Wie kann man programmiertechnisch darauf prüfen?
Ein Hinweis in der Hilfedatei wäre mir zu wenig.

[cmb]

Christophs Vorschlag war ja schon ganz gut, hilft aber in der Praxis noch nicht weiter. Ich möchte den Usern nicht zumuten, dass sie auch noch functions.php ändern müssen, um das Plugin zu verwenden.

Nicht die User müssen function.php (XH_autoload) ändern, sondern wir müssen das tun, denn das jetzige Verhalten ist ein Bug.

Statt nach einer vielleicht nicht vorhandenen Datei zu fragen (was dann eine Fehlermeldung verursacht), könnte man nicht fragen, ob irgendeine Variable aus dem FA_xh-Plugin bekannt ist?
Wenn ich mir laienhaft vorstelle, dass die Plugins in alphabetischer Reihenfolge aufgerufen werden, müsste das doch möglich sein - oder?
fa... kommt doch vor fhs...

Zunächst mal setzt Fa_XH keine globale Variable (okay, für einen ganz kurzen Moment $temp, aber das wird gleich wieder freigegeben), so dass da nichts geprüft werden kann. Aber der eigentliche Punkt ist eben die Ladereihenfolge der Plugins. Fa kommt zwar vor fhs…, so dass in diesem Fall auf die function fa_require() geprüft werden kann (wie in Templates), aber eigentlich halte ich die Ladereihenfolge der Plugins für ein Implementierungsdetail (die Reihenfolge war vor 1.6? überhaupt nicht definiert, und wurde hauptsächlich "korrigiert" um bei eventuellen Supportanfragen bestimmte Pluginkonstellationen besser nachprüfen zu können), auf das man sich nicht verlassen sollte – im schlimmsten Fall führte das dazu, dass Plugins künstliche Namen bekommen, nur damit sie möglichst früh, oder möglichst spät geladen werden.

Oder nochmal ganz einfach gefragt:
Wenn ein Plugin von einem anderen abhängt: Wie kann man programmiertechnisch darauf prüfen?
Ein Hinweis in der Hilfedatei wäre mir zu wenig.

Letztlich sind die Möglichkeiten mannigfach. Bei jQuery4CMSimple wird es normalerweise so gemacht, dass die Existenz einer bestimmten Datei (jquery.inc.php) geprüft wird (und dann diese Datei vom Client auch gleich eingebunden werden muss). Man könnte aber auch einfach auf die Existenz des Pluginordners (plugins/fa/) prüfen. Letzteres ist aber nicht gerade robust, da es ja ein ganz anderes Plugin namens fa geben könnte, oder eine zukünftige Version von Fa_XH anders funktioniert, oder plugins/fa/ bei der Deinstallation des Plugins übrig geblieben ist, oder oder oder. So wie es bei jQuery4CMSimple gemacht wird, ist es schon deutlich besser, aber da stört mich vor allem, dass man die Datei auch noch einbinden muss; das ist bei Prüfung auf eine Klasse dank des Autoloaders nicht mehr nötig. Das etwas aufwendige Konstrukt, um Font Awesome dann wirklich einzubinden, ist halt ein Zugeständnis an die unter PHP 5.3 fehlende Möglichkeit des direkten Memberaccess bei der Instantiierung, welche leider erst ab PHP 5.4.0 verfügbar ist. Das halte ich aber für ein kleineres Problem; wer will, kann ja auch jetzt schon mindestens PHP 5.4.0 erfordern (was sowieso nicht verkehrt ist), und die Kurzform (siehe Fa_XH Handbuch) verwenden. Nur Standard-Erweiterungen (Templates, Plugins) sollten wie der Core auch unter PHP 5.3.0 lauffähig sein, es sei denn wir ringen uns durch, dass für XH 1.7.0 allgemein mindestens PHP 5.4.0 vorhanden sein muss.

[frase]

Hi Christoph,
ich bin mal wieder beeindruckt, wie gut du die Zusammenhänge erklären kannst. Sogar ich verstehe einiges davon.
Danke dafür.

Was ich nun konkret machen soll, ist mir aber immer noch schleierhaft.
Ich werde jetzt deinen Text noch zehnmal lesen und hoffe, dass ich hinterher nicht mehr nerven muss.

[frase]

Zunächst mal setzt Fa_XH keine globale Variable ...

Mal ganz allgemein - unabhängig von FA und Adminmenü -, wäre es nicht überhaupt von Vorteil, wenn Plugins ihr Vorhandensein dem System bekannt gäben? So, dass bei eventuellen Abhängigkeiten darauf geprüft werden könnte?

[cmb]

Was ich nun konkret machen soll, ist mir aber immer noch schleierhaft.

Ich würde sagen, mach es so wie im Fa_XH Handbuch angegeben bzw. wie bisher besprochen. Den Autoloader fixe ich gerade.

Mal ganz allgemein - unabhängig von FA und Adminmenü -, wäre es nicht überhaupt von Vorteil, wenn Plugins ihr Vorhandensein dem System bekannt gäben? So, dass bei eventuellen Abhängigkeiten darauf geprüft werden könnte?

Ja, definitiv. Allerdings wird das vom Core/Pluginloader bisher durch das bloße Vorhandensein des Plugin-Ordners (also z.B. plugins/fa/) und einiger bestimmter Dateien darin gehandhabt, und das funktioniert im Prinzip ja auch ganz gut[1], solange nicht besondere Funktionalität des Plugin erforderlich ist. Besondere Funktionalität wird bisher in der Regel durch Prüfung auf Existenz einer speziellen Include-Datei, deren Einbindung und bei Bedarf Prüfen auf die Existenz einer bestimmten Funktion, die in der Include-Datei definiert wird, festgestellt. Ein schönes Beispiel ist init_editor(). Dieser Aufwand ist erforderlich, weil alles noch unter PHP 4 laufen sollte, als die neue Editor-Integration unter CMSimple_XH 1.5 entwickelt wurde. Würde man das auf Klassen mit Autoloading umstellen, dann könnte die Funktion etwa so aussehen:

Code: Select all

function init_editor(array $elementClasses = array(),  $initFile = false)
{
    global $cf;

    $className = ucfirst($cf['editor']['external']) . '\\Editor';
    if (!method_exists($className, 'init')) {
        return false;
    }
    $init = "$className::init";
    $init($elementClasses, $initFile);
    return true;
}

Deutlich kürzer, vor allem weil eben nicht explizit der Dateipfad konstruiert, und die Datei eingebunden werden muss (das übernimmt der Autoloader hinter den Kulissen). Ein weiterer Vorteil ist, dass ein Unit-Test für diese Variante wesentlich einfacher ist, da man das Dateisystem komplett ignorieren kann.

[1] Wirklich glücklich bin ich damit aber nicht, da es doch viele file_exists() oder ähnliches erfordert, auch wenn vielleicht so manche Funktionalität für einen bestimmten Request gar nicht erforderlich ist. Klassen mit Autoloading bieten da schon mal eine Verbesserung, und auch das Laden der Konfigurations- und Sprachdateien nur bei Bedarf geht in diese Richtung. Viel mehr kann der Core aber aus Gründen der Abwärtskompatibilität nicht machen. Langfristig würde ich mir da aber schon eine Verbesserung wünschen, vielleicht in der Art wie sich Plugins bei Pfw_XH registrieren.

[frase]

See also:
https://cmsimpleforum.com/viewtopic.php ... 213#p59213

[cmb]

Just added this to a testsite and it seems to work OK for me after one initial problem.
Perhaps you should say in the help file "Dont cut and paste ... define('TINYMCE4_VARIANT, '');"
Killed the site when I did this. When I typed it in it was ok.

Actually, I'd prefer if this could be changed via the configuration; otherwise any detailed documentation might quickly become obsolete.

[manu]

Just added this to a testsite and it seems to work OK for me after one initial problem.
Perhaps you should say in the help file "Dont cut and paste ... define('TINYMCE4_VARIANT, '');"
Killed the site when I did this. When I typed it in it was ok.

Actually, I'd prefer if this could be changed via the configuration; otherwise any detailed documentation might quickly become obsolete.

I cannot see what the actual problem is. Please explain.

[cmb]

I cannot see what the actual problem is. Please explain.

The Font-Awesome plugin for TinyMCE 4 unfortunately doesn't work with the CDN variant[1], so I have to explain to users how to change this to the local variant, which currently reads:

Configure TinyMCE 4 to use the locally installed version, so edit plugins/tinymce/classes/required_classes.php and define('TINYMCE4_VARIANT, '');.

Apparently, this is misleading. I could document that the user has to uncomment `define('TINYMCE4_VARIANT', '');` and to comment `define('TINYMCE4_VARIANT', 'CDN');`. That is probably also confusing (at least for people who don't know PHP). So I'd have to document that line 18+19 have to be changed to:

Code: Select all

define('TINYMCE4_VARIANT', '');  //TinyMCE4 fully installed
//define('TINYMCE4_VARIANT', 'CDN');  //TinyMCE4 externally loaded   

However, this becomes obsolete as soon as the line numbers change (maybe only the header comment get's adjusted). It's basically the same issue as with the very early add-ons, which documented that after line 123 in cms.php some code had to be inserted…

Instead of writing a rather lengthy explanation on what to do (and to update that from time to time, perhaps with info about different versions), I'd rather give a short but precise info, or maybe even call a published API.

[1] If this could be fixed, that would be even better. I mean, use the CDN variant, but also have the possibility to add locally installed plugins.