WBCE CMS Forum

bastie

Mitglied

Inline-Editing oder so?

Hi zusammen,

ich hab ja mal Coast-CMS vorgestellt, Was mir da gefallen hat, man klickt in den Brereich, den man ändern will, tippt den Text, speichert und gut ist.

Ich finde, dass die Backends bei den meisten CMS teilweise unübersichtlich sind. Man muss sich schon vorstellen können, welcher Block welcher ist und im Layout wohin gehört.

So eine Art Änderungen direkt im Layout vornehmen zu können, das wäre was.

Ansätze gibt es da ja:

• Coast-CMS

• ImpressPages

• Typesetter (früher GP-Easy)

Kann man davon lernen  oder das Eine oder Andere übenerhmen? Einfach mal so als Denkansatz. Und ist eine MYSQL-Datenbank wirklich notwendig (OK, bei WB und WBCE schon, weil Datenbak basiert), aber grundsätzlich?

Anders geht es ja auch.

Das sind jetzt mal nur so ein paar Gedanken, die mir die letzten Tagen so durch den Kopf geschossen sind.

Ich möchte eigentlich, weil ich ein fauler Mensch bin, auf meiner Seite nur dahin klicken, wo ich einen Text ändern kann, ne News, older ein Bild ändern möchte, naja, usw.

Easy halt, easy für jeden.

Ist das jetzt nur meine Phantasie?

Bastie

---

Wer Rechtschreibfehler findet, darf sie gerne herunterladen, kopieren, weiterverwenden und weiterverbreiten. Ich beanspruche in keiner Weise ein Urheberrecht. Meine Rechtschreibfehler stehen unter der MIT-Lizenz.

florian

Administrator

Re: Inline-Editing oder so?

Ich habe das Thema mal auf den Wunschzettel geschoben. So abwegig ist das ja nicht; einige Module (RFG, Teasers) werden ja bereits mehr oder weniger ausschließlich im Frontend bearbeitet.
Ich halte aber weder eine komplette Abkehr vom Backend/Frontend-Konzept noch den Verzicht auf das Speichern der Inhalte in einer Datenbank für sinnvoll und sehe auch keine Perspektive, dass dies in einer der nächsten Hauptversionen umgesetzt werden könnte.

---

Wir Benötigen: Cents, Euros... jetzt spenden!

evaki

Gast

Re: Inline-Editing oder so?

Wenn das BE in/als WYSIWYG daherkommt, könnte man auf die Moduleschnitzerei verzichten.
MfG. Evaki

florian

Administrator

Re: Inline-Editing oder so?

Die Anpassung des Erscheinungsbildes im CKE an das Frontend ist sicherlich eine Hilfe. Allerdings lässt sich dort beispielsweise die Wirkung von Textumbrüchen nicht immer realistisch abbilden.
Nimm zum Beispiel ein Design mit einer breiten Haupt- und einer schmalen Randspalte, in der zudem die Schriftgröße auf 85% und eine andere Hintergrundfarbe gesetzt sind. Diese Angaben kommen aus dem Template und werden dort über eine Klasse dem jeweiligen <div> zugeordnet. Der CKE bzw. das WYSIWYG-Modul sehen aber immer gleich aus, d.h. es ist afaik nicht möglich, im Backend unterschiedliche Designs im Editor je nach Zuordnung eines Abschnitts zu einem bestimmten Block darzustellen.*
Für solche Konstellationen oder auch mit Blick auf RWD ergäbe ein kleines WYSIWYG-Frontend-Edit-Modul also schon Sinn.

(* was eigentlich schade ist.)

---

Wir Benötigen: Cents, Euros... jetzt spenden!

jonny

Mitglied

Re: Inline-Editing oder so?

Ich bin wirklich auch dafür zu haben das man so etwas machen kann, was natürlich auch dazu gehören sollte, ist das alle Templates ein Login erhalten.

Sehr warscheinlich würde dies noch viel Arbeit mit sich ziehen, aber dies sollte mit Team work realisierbar sein oder?
Der vorteil wenn alle Frontendlogins besitzen, kann auch ein Unerfahrener User sich danach einloggen ohne sich durchs Backendgewusel zu schlagen, vielleicht gehts nur mir so aber manchmal ist das Neanderthalerdenken von manchen Benutzern leider hinderlich bei manchen Projekten.

---

Wer noch etwas Dummheit will soll sich hinten anstellen..

grindbatzn

Gast

Re: Inline-Editing oder so?

Ich hab mir dazu ja schon öfter mal Gedanken gemacht:
http://wbce.at/de/topics/editieren-im-frontend.php

Kurz gesagt - der Haken:
Wenn irgendwas passiert - zb ein Javascript-Fehler - dann funktioniert Frontend-Edit nicht mehr. Dann brauchst du erst recht wieder ein Backend, um den Fehler zu reparieren. Die Mehrarbeit will sich nicht jeder Modulentwickler antun.

Bei WBCE hat jedes Modul sein eigenes Javascript mit; mitunter sehr umfangreich. Was passiert, wenn sich 2 Module nicht vertragen und alles steht? Wie entfernst du die Module wieder?

Bei kleinen CMS ohne modularen Aufbau geht das noch eher, aber ein System mit dem Umfang von WBCE? Nein, das geht nicht mehr durchgehend.

Nicht mehr durchgehend bedeutet aber auch: Inkonsistenz. Das eine im Frontend, das andere im Backend. Das kommt nicht gut.

bastie

Mitglied

Re: Inline-Editing oder so?

Ich halte aber weder eine komplette Abkehr vom Backend/Frontend-Konzept noch den Verzicht auf das Speichern der Inhalte in einer Datenbank für sinnvoll und sehe auch keine Perspektive, dass dies in einer der nächsten Hauptversionen umgesetzt werden könnte.

Auf ein Backend und die Datenbank muß nicht unbedingt verzichtet werden, Impress Pages benutzt z. B. beides. Und Module, dort Plugins genannt, gibt`s auch jede Menge.

---

Wer Rechtschreibfehler findet, darf sie gerne herunterladen, kopieren, weiterverwenden und weiterverbreiten. Ich beanspruche in keiner Weise ein Urheberrecht. Meine Rechtschreibfehler stehen unter der MIT-Lizenz.

webbird

Administrator

Re: Inline-Editing oder so?

Das Thema ist nicht neu, was bedeutet, dass sich in der Vergangenheit schon viele Leute viele Gedanken gemacht haben. Wobei wir hier zwei Themen haben: Frontend Editing und Datenbank. Ich gehe mal auf beides ein.

Zuerst mal das Thema Datenbank. Ich selbst benutze auf meiner HP ein Wiki, das ohne Datenbank auskommt, was sehr angenehm ist, wenn man mal auf einen anderen Server umzieht oder fix eine Sicherung machen möchte. Allerdings muß man dafür auch auf vieles verzichten, oder im CMS nachprogrammieren.

Datenbanken unterstützen z.B. das Indizieren, was Suchzugriffe beschleunigt. Mit Suchzugriff ist hier nicht sowas wie eine Volltextsuche gemeint, sondern auch so ganz einfache Dinge wie "ich brauche alle Sektionen der Seite X". Alles was im SQL mit "SELECT" anfängt ist ein Suchzugriff.

Datenbanken unterstützen auch sogenannte Foreign Keys, zu Deutsch Fremdschlüssel. Damit werden Beziehungen zwischen Tabellen hergestellt. Es läßt sich z.B. definieren, dass eine Seite, die noch zugeordnete Sektionen hat, nicht gelöscht werden kann. Oder, wenn man es umgekehrt haben möchte, dass beim Löschen einer Seite automatisch auch alle Sektionen gelöscht werden, die zu der Seite gehören. Bei einem datenbanklosen CMS muss man das programmieren, bei Nutzung einer Datenbank kann man es der DB überlassen.

Mit neueren mySQL Versionen kann man zudem mit Triggern arbeiten. Trigger werden "ausgelöst", wenn bestimmte Ereignisse eintreffen, und können dann mehr oder weniger komplexe Logiken ausführen. Beispiel: Es wäre möglich, beim Ändern von Seiteninhalten über einen Trigger vollautomatisch eine Kopie der alten Daten zu erstellen und somit eine Historie der Änderungen zu erhalten. WB(CE) nutzt das nicht, es gibt auch ein paar Dinge, über die man vorher nachdenken sollte (z.B. wäre das Setzen eines Kommas in einem umfangreichen Text eine Änderung, aber benötigt man dafür einen Eintrag in der Historie?), prinzipiell aber eine Option, über die man mal nachdenken sollte. (Haben wir bei BC schon vor einer Weile getan und werden das vermutlich künftig auch nutzen.)

Das sind nur ein paar Beispiele, warum die Nutzung einer "echten" Datenbank (man kann auch reine Textdateien als "plain text database" bezeichnen) durchaus viele Vorteile hat. Natürlich geht es auch ohne, man muss dann aber viel mehr programmieren, und verliert viel an Flexibilität und Leistung.

Zum Thema Frontend Editing. Da nur das jeweilige Modul "weiß", was zu tun ist, muss jedes Modul für Frontend Editing geeignet sein bzw. im Fall von WB(CE) entsprechend umgeschrieben und erweitert werden. Im Fall von WYSIWYG ist das am einfachsten, da viele Editoren das direkt unterstützen. Mit HTML5 kommt ja auch das Attribut "contenteditable" für genau diesen Zweck ins Spiel.

Problematischer ist das bei Modulen, die einem bestimmten Zweck dienen, wie Topics, Bookings, Bakery und Co. Wie will ich da ein Frontend Editing umsetzen? Jedes Modul bzw. jeder Autor muss für sich überlegen: Wie soll das aussehen? Was macht überhaupt Sinn? Was ist für den Benutzer einfacher zu verstehen? Bei vielen Modulen - Bakery ist ein gutes Beispiel - ist es IMHO wesentlich einfacher, ein Formular auszufüllen, in dem ich z.B. gleich auch sehe, was Pflichtfelder sind etc. In dem Fall hieße Frontend Editing _entweder_ das Öffnen eines Formulars in einem Overlay (jQuery UI Dialog o.ä.) _oder_ durch Anklicken eines Icons im Frontend auf die entsprechende Backend-Seite zu verlinken.

Und da sind wir beim Kernproblem: Wie soll ich das konsistent für alle Module hinkriegen? Mache ich dem Modulautor Vorschriften, fühlt er sich möglicherweise in seinen Freiheiten eingeschränkt und streikt. Mache ich keine, macht es jeder, wie er es für richtig hält, Stichwort "Wildwuchs".

Meiner persönlichen Meinung nach macht Frontend Editing fast nur bei WYSIWYG-Modulen Sinn. Was ich allerdings gut fände, wäre eine Markierung im Frontend, damit ich sehe, was zu welchem Block gehört. Als ich vor Jahren (könnten schon 10 sein... oh Mann...) mal ein Perl-CMS programmiert habe, habe ich im Frontend die einzelnen Blöcke mit roten Rahmen versehen und beschriftet. Dazu ein paar Icons wie "Editieren", "Löschen", "Ausblenden", und schon hat man zumindest ansatzweise ein Frontend Editing. Auch wenn zumindest der Editieren-Link dann wieder ins BE führt.

Beitrag geändert von webbird (10.04.2017 11:23:03)

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal