Editieren im Frontend - der Status

WBCE ist ein klassisches Backend/Frontend CMS: Editieren im Backend, Ansehen im Frontend. Lange Zeit ging das auch gar nicht anders: Inkompatible Browser und mangelnde Javascript-Unterstützung machten es nötig, soweit möglich alles auf dem Server auszuführen - da weiß man wenigstens, was man hat.

Der Nachteil der strikten Trennung von Backend und Frontend: man sieht nicht direkt, was man tut. Man muss immer wieder im Frontend nachschauen.

Gerade auch bei mobilen Geräten ist das Frontend oft weit besser zugänglich als das Backend. Natürlich wird man keine langen Artikel am Handy schreiben und einstellen, aber kleine Tätigkeiten wie Fotos hochladen (die ja schon am Handy sind!) oder neue Kommentare verwalten würden tadellos funktionieren.

Grundsätzlich gibt es dafür in WBCE keinen „generellen“ Ansatz, jedes Modul muss für sich Frontend Editing unterstützen und verwalten.

Sicherheitsaspekte

Wenn man nicht alle Sicherheitsmaßnahmen außer Acht lässt, ist Frontend- Editing genauso sicher wie die Bearbeitung im Backend. Es gelten da wie dort die gleichen Nutzerrechte. Sogar das Gegenteil kann der Fall sein: Durch die dichte Verwobenheit von Javascript und PHP kann man nicht mehr so einfach per Bot zugreifen.

Frontend-Edit als iFrame

Man nehme ein Stückchen Backend und bringt es in ein kleines Overlay im Frontend. Das hat den großen Vorteil, dass man stabile Verhältnisse hat: Der iFrame hat sein eigenes JS, CSS und und wird nicht gestört von dem, was im Frontend so herumschwirrt.

Die Nachteile: Tatsächlich erfolgt die Änderung ja wieder im Backend - auf dem Server. Man muss also die Seite neu laden, um die Änderungen zu sehen. Das kann man zwar automatisch veranlassen, dadurch überrumpelt man den User aber ein wenig. Nachladen per AJAX ist nicht so ganz einfach, weil Scripte neu initalisiert werden müssen.
Und nicht zuletzt: iFrames müssen eine bestimmte Größe haben. Das Nachjustieren ist mühsam und fehleranfällig.

iFrames sind übrigens nichts Böses und sie sind weiter verbreitet als man glaubt.

Inline-Edit

Ändern direkt auf der Seite - ohne Overlay. Man schreibt einfach in die Seite hinein. Das ist heute prinzipiell möglich, hat aber seine Tücken.
Zum einen wird wird JS und CSS von Templates und anderen Modulen vermischt - das kann heftige Störungen bis zum Totalausfall verursachen. Man kann das dann auch nicht mehr korrigieren - wie denn, wenn nichts mehr geht. Für solche Fälle muss es also weiterhin ein Backend geben - was mehr Coding-Aufwand bedeutet.

Viele Aufgaben lassen sich auch nicht so einfach direkt im Frontend erledigen, etwa das Anlegen neuer Abschnitte oder die Einstellungen von Modulen.

Die Grenzen

Das Backend wird man also so oder so nicht los, und es stellt sich dann natürlich die Frage: Was bringt es, wenn ich sowieso immer wieder ins Backend muss und dort mehr Möglichkeiten als im Frontend habe - also gleich alles erledigen kann.

Auch für Modulentwickler ist der Aufwand deutlich höher - das kann man auch in die Verbesserung von Modulen insgesamt investieren.
Und nicht zuletzt bei der Erstellung von Templates würden deutlich strengere Regeln gelten, und trotzdem kann es zu Fehlfunktionen kommen.

Blöcke im Frontend anlegen und herumschieben - das wird so bald nicht sein, da müssen alle Komponenten optimal aufeinander abgestimmt sein: Core, Module, Templates.
Das geht bei einem zentral gesteuerten System wie WIX, aber nicht bei einem CMS, wo alles aus verschiedenen Quellen kommt.

Unterm Strich

Ich sehe Frontend-Editing dort als Vorteil, wo kleine Tätigkeiten gemacht werden, vor allem auch am Handy: Schnell mal ein Bild in die Gallery hochladen oder ändern, ein Kommentar freischalten oder beantworten, schnelle Ankündigungen und News.

Vielleicht mal einen Tipfehler ausbessern - wobei man da am Handy schon verdammt aufpassen muss, dass man nicht mehr Fehler reinmacht oder sich gar einen Block zerstört.

Zurück