WBCE und AJAX

Durch das teilweise Nachladen von Inhalten wird eine Website modern und geschmeidig. Leider läuft das bei WBCE nicht ganz so rund, wie man es gerne hätte.

WBCE ist recht klassisch gestrickt: Ein Klick auf einen Menüpunkt ruft eine komplette Seite vom Server ab, mit Template, Inhalt, CSS, JS usw - komplett alles. Auch wenn sich kaum etwas ändert.

Das ist oft nicht nötig und mitunter sogar hinderlich, deswegen geht man auf modernen Websites mehr und mehr dazu über, nur die Teile, die sich ändern, per Javascript nachzuladen. Diese Technik wird salopp unter dem Namen „AJAX“ zusammengefasst.

Wie AJAX-freundlich ist WBCE?

Konkret könnte man also Module so machen, dass nur das geladen wird, was vom Modul angefordert wird. Blättert man zb im Kalender zum nächsten Monat, wird nur der Kalender aktualisiert, nicht die ganze Seite. Oder man setzt ein Formular ab - dann ändert nur das Formular seinen Inhalt ("Danke" oder "Fehler"), wie es zb bei MiniForm ist.

WBCE macht es einem aber nicht leicht: Im Frontend- also der öffentlichen Website - läuft praktisch alles über die index.php im Stammverzeichnis der Domain. Dort wird bei jedem Seitenaufruf das „Werkel“ neu gestartet, die Berechtigungen überprüft, das Template mitsamt angefordertem Inhalt zusammengebaut und letztlich laufen noch die Output-Filter über alles drüber.
Wenn man dieses „Gesamtpaket“ nicht will, muss man das völlig umgehen und es selbst in einem Script zusammenstellen. 

Dabei gibt es einen Haken: die index.php ändert sich immer wieder mal. Oft sind das nur Details, aber man müsste trotzdem ein Modul für verschiedene WBCE-Versionen anpassen und kann nicht sicher sein, dass es auch in der nächsten WBCE-Version funktioniert. Von einer Kompatibilität mit WebsiteBaker will ich da gar nicht reden.

Viel unnötiger Code für Kleinigkeiten

Insgesamt ist es so, dass man selbst für kleine Aufgaben - etwa einen Zähler in der Datenbank hochzählen - ziemlich viel Code starten muss. Natürlich könnte man auch hier eigene Wege gehen und nur die Teile von WBCE starten, die man wirklich benötigt, aber dann muss man wieder fürchten, dass man für jede Version Ausnahmen machen muss.

Fehlende Richtlinien und Unterstützung

Die Core-Entwickler haben mit AJAX wenig am Hut, sie sind auf PHP und den klassischen Zugang fixiert. Und selbst wenn der Core AJAX-freundlicher wäre: Module sollten auch auf älteren Websites funktionieren, und wenn ich als Modulentwickler schon einen Workaround machen muss, dann kann ich den auch gleich als einzige Variante nehmen. 

Dennoch: Vielleicht könnten die Core-Entwickler die index.php ausmisten und die Funktionen, die auch für AJAX nötig wären, gesondert bereitstellen. Oder einen WBCE-Schnellstart mit dem Allernötigsten ermöglichen, um ein Datenbank-Feld auszulesen und zu beschreiben.
Und - das wäre das Tollste überhaupt  ;) Das Ganze auch zu dokumentieren. Denn oft fällt einem erst beim Verfassen der Dokumentation auf, wie brauchbar oder nicht etwas ist.
 

Zurück

Kommentare:

Halllo,

einen rudimentären POC für hole Inhalt einer Sektion als HTML und gib diese auf dem Bildschirm aus, habe ich im WBCE-Forum gepostet. Vielleicht kann man das als Grundlage für eigene Erweiterungen (Ajax etc.) verwendet. Wenn nicht, einfach ignorieren.

Link: https:/­/­forum.wbce.org/­viewtopic.php?pid=37940#p37940

Gruß zx80

zx80
Antworten

Es gibt ein paar Module, die AJAX verwenden, hier zB. Teasers, GlobalComments, ResponsiveFG. Und es könnten auch durchaus mehr sein.
Es gibt ja auch im Forum gerade eine aktive Frage wegen genau sowas.

Vielleicht könnte mal ein Core-Kundiger ein Script "getSectionContent.php?section_id=25" machen, das den nackten Inhalt der view.php des Moduls von section 25 zurückgibt. Mit Rechte-Überprüfung und Outputfiltern und allem dran. Frontend.js /­css kann man wohl weglassen - oder optional mit einem weiteren Parameter einfügen lassen.

Was mir _auch_ immer wieder Probleme macht, ist die Überprüfung der Berechtigung in einer view.php. Darf der aktuelle User Änderungen machen? Das sollte halbwegs Resourcen-schonend laufen, weil man ja mitunter viele Instanzen eines Modules auf einer Seite hat, wie zb bei Wunderblock.
Ich mache das, indem ich direkt auf $_SESSION zugreife, mit etwas Bauchweh.
Eine allzu strenge Prüfung ist idR aber nicht nötig, weil für eine Änderung ja auch noch die modify.php bzw save.php nötig ist, und da kann man genau überprüfen ohne Performance-Verlust.

Chio
Antworten

Die index.php ändert sich nicht "immer wieder mal", sondern eher selten, siehe https:/­/­github.com/­WBCE/­WBCE_CMS/­commits/­main/­wbce/­index.php
Sowie zu "Module sollten auch auf älteren Websites funktionieren":
Man kann nicht gleichzeitig erwarten, dass WBCE State-of-the-art-Technologien unterstützt, und andererseits verlangen, dass sich niemals Änderungen am Core ergeben und notwendige Anpassungen unterschwellig als Willkürhandlungen darstellen.

Abgesehen davon sollte ein CMS, auch WBCE, immer so aktuell wie möglich gehalten werden. Die Updates, die wir veröffentlichen, sind üblicherweise Funktions- und Sicherheitsupdates. Es ist also sowieso nicht ratsam, bis in alle Ewigkeit Seiten mit WBCE < 1.5.x zu betreiben.

@Abyys: Wir von wbce.org freuen uns über jeden, der sich konstruktiv und mit realistischen Vorstellungen in die Weiterentwicklung von WBCE einbringen möchte, und gegebenenfalls aber auch mal ein "Tut uns Leid, ist nicht realisierbar" akzeptiert. Ich lade Dich daher herzlich ein, Dich im Forum auf wbce.org zu registrieren und Deine - ernst gemeint - wertvollen Anregungen dort im Unterforum "Entwicklung WBCE Core & Backend" (https:/­/­forum.wbce.org/­viewforum.php?id=3) einzubringen.

florian
Antworten

@Georg: Sehr gute Zusammenfassung. Welche Module nutzen denn noch AJAX Funktionalitäten? Ich hatte vor Jahren mal Postits im Einsatz. Andere Module sind mir bisher noch nicht ins Auge gesprungen. In Postits wird das wie von Dir und mir beschrieben gelöst. Sprich config.php und notwendige WBCE Klassen bzw. Funktionen einbinden wo nötig und dann mit PHP/­JS bereitstellen bzw. verwursten. Fast so, als wie in einer view.php etc.

Postits könnte mit den aktuellen WBCE Core Funktionen wie Includes noch eleganter geschrieben werden, da der notwendige JS Code leichter eingebunden werden kann.

@Chio: Wo genau klemmt es denn nun bei Dir, bzw. welche Funktionen werden von Dir genau vermisst? Ich für meinen Teil kann gut mit den Core Features und PHP/­JS leben.

Grüße Abyys

Abyys
Antworten

Wir müssen hier mal zwei Dinge voneinander trennen. AJAX und SPA.

Eine SPA oder Single Page Application tut das, was zu Beginn des Beitrags beschrieben wird: Der Rahmen wird einmal geladen, danach nur noch die Teile, die sich ändern. (Siehe auch https:/­/­de.wikipedia.org/­wiki/­Single-Page-Webanwendung) Da SPAs viel Logik auf der Clientseite benötigen, werden sie klassischerweise hauptsächlich in JavaScript geschrieben. Bekannte Frameworks hierfür sind etwa AngularJS, React oder Vue.js.

WBCE ist in der Tat keine SPA und hatte auch nie den Anspruch, eine zu sein. Ein kompletter Umbau würde bedeuten, etwa 70 - 80% des Codes in JavaScript neu zu schreiben. Das betrifft dann selbstverständlich auch die Module. Die komplette Logik spielt sich nicht mehr auf dem Server ab, sondern auf dem Client, also im Browser. Auf dem Server befinden sich dann nur noch Backend-Komponenten wie z.B. der Zugriff auf die Datenbank. Der klassische WBCE-Benutzer - und auch Modulautor - wird das nicht wollen. Dafür gäbe es andere Systeme.

Interaktivitität via AJAX ist demgegenüber auch in WBCE problemlos möglich. Der einzige wirkliche Knackpunkt ist, dass ein via AJAX aufgerufenes Script quasi losgelöst vom Gesamtkontext des CMS ausgeführt wird. Anders gesagt, es weiß zunächst einmal nichts über die Berechtigungen des Benutzers, der es aufgerufen hat. Es muss die config.php selbst laden und dann ggfs. auch die notwendigen Berechtigungen selbst prüfen. Das ist mit Hilfe übergebener Parameter wie Seiten- und Section-ID durchaus möglich. Inwieweit das notwendig ist, muss der Modulautor im Einzelfall entscheiden.

Aus meiner Sicht liefert der Core bereits hinreichend Möglichkeiten für AJAX. Einige Module machen auch schon mehr oder weniger intensiven Gebrauch davon. Der mögliche Overhead durch das Laden der config.php, wie wiederum die initialize.php lädt, ist relativ gering, da die Informationen, die hierbei geladen werden - wie z.B. die Sprache, die Datenbank-Verbindung und diverse Konstanten - durchaus notwendig sind. Ein Aufruf der index.php ist indes nicht notwendig.

Sicherlich könnte man an der Schnittstelle noch etwas verbessern, ob das aber innerhalb des Core sein muss, steht auf einem anderen Blatt. Genauso gut könnte man - und damit meine ich Entwickler, die nicht schon mit dem Core zu 100% ausgelastet sind - die Arbeit in eine Lib (bzw. ein Lib-Modul) stecken. Damit ist man dann auch relativ unabhängig von eventuellen "breaking changes" bzw. kann sehr schnell darauf reagieren.

Fazit: Ja, WBCE ist keine SPA und hat auch nicht den Anspruch. Wer so ein "modernes" System haben möchte, muss sich anderweitig umsehen. AJAX bzw. das dynamische Nachladen von Inhalten innerhalb einer Seite ist hingegen mit WBCE auch jetzt schon sehr gut machbar. "Luft nach oben" gibt es natürlich immer, aber der Artikel erweckt den Eindruck, dass es nur sehr schwer bis gar nicht geht. Und das ist so einfach nicht korrekt.

Georg
Antworten

Das CMS ist doch schon gestartet, wenn die Seite im Frontend angezeigt wird. Die Interaktivität erfolgt durch Nutzerinteraktion auf der Seite, die dann eben die Seite nicht komplett neu aufbaut, sondern dynamische Inhalte aus PHP/­JS via Ajax als JSON/­XHTML bezieht und einen Teil der Seite dynamisch erneuert.

Schildere doch mal, was Du eigentlich vor hast, bzw. wo genau es klemmt und was Du bisher bereits versucht hast (Code z.B. auf Github etc.). Auch unklar ist, welche CMS Funktionen Du wofür benötigst, oder was Du eigentlich damit erreichen willst.

Gruss Abyys

Abyys
Antworten

Bei AJAX im Frontend muss ja nicht zwingend die Seite über die index.php bei jedem Klick auf ein Element der Seite neu geladen werden. Wenn JS aktiv, wird ein Handler registriert, der dann JSON/­XHTML zurückgibt, mit dem ein Teil der HTML Inhalte (DIV) aktualisiert wird. Das geht mit JS und PHP Bordmitteln und den Server seitigen Funktionen von WBCE/­Websitebaker eigentlich ganz gut. Klar wäre es schöner, wenn man wie bei Wordpress Hooks einfach registrieren könnte, aber mit den Include Funktionen und Vanilla JS/­PHP klappt das auch ganz vernünftig.

Abyys
Antworten

Der JS-Teil ist ja nicht das Problem. Viel mehr stört mich, dass ich im Prinzip das ganze CMS starten muss, nur um ein paar Daten zu bekommen.
Dazu die Sache mit den Output-Filtern, die ich aus der index.php kopieren muss.

Chio
Antworten