WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

Frontend-Edit Überlegungen

(1/11) > >>

chio:
Ja. Weil das Thema immer wieder auftaucht - vielleicht sollten wir mal unsere Ansätze und Standpunkte dazu austauschen.

Mein Senf:
Ein "richtiger" Frontend-Edit wäre, direkt im Frontend in die Rahmen zu schreiben. Dabei gibt es aber grundsätzliche Probleme:

Die Button-Leiste des Editor müsste schwebend sein, weil sie ja sonst nicht reinpasst. Dadurch kommt allerhand heikles Javascript zusammen und es würde wohl vieles nur sehr spartanisch funktionieren (zb Bildauswahl usw)

Dazu kommen andere Fallstricke: Hat man mehrere Abschnitte, kann man immer nur einen speichern. Im Frontend wäre das völlig verwaschen, da wird es wohl viel Gefluche geben.

Für viele Module geht das gar nicht; die Formulare sind zu umfangreich/komplex. Es kommt also in jedem Fall eine Mischung aus Frontend-Edit und klassischem Backend raus -> ergo: Alles was im Frontend bearbeitbar wäre, muss immer auch noch im Backend bearbeitbar sein. Das heißt: viel Mehrarbeit an den Modulen, die man besser in was anderes (Komfort, Sicherheit) investieren könnte.

Eine Möglichkeit sehe ich also nur bei ganz einfach gehaltenenen Seiten; etwa nur ein Abschnitt WYSIWYG.

Möglichkeit 2: Das Backend als Overlay ins Frontend holen.
Bei Topics 0.6 (noch nicht verfügbar) mache ich es über jQuery + FancyBox.
http://WebsiteBaker.at/topics/frontend-edit-bei-topics.html

Nachteil: ISt natürlich nicht "richtig": Zeilenbreiten sind anders, oft auch Stil usw. Ist eben letztlich Backend. Bei kleinen Monitoren kommen 3 Scrollbalken nebeneinander zusammen, das ist ziemlich lästig.
Und: man müsste sich rechtzeitig auf einen gemeinsamen Modus einigen, sonst kommt da Wildwuchs raus, jedes Modul kocht sein eigenes Süppchen. Bei der Entscheidungsfreudi gkeit unserer Anführer wird das noch Jahre dauern.
Die Änderungen im Modul selbst halten sich im Rahmen.

Vorteil: Geht mit praktisch allen Modulen, wenn diese angepasst werden. Sieht gleich schicker und professioneller aus.

Sicher ein guter Kandidat wäre auch Thorns WYSIWYG History.
http://www.websitebakers.com/pages/admin/core-replacements/wysiwyg-history.php

Weitere Anmerkungen:
Die einfachste Variante ist natürlich, auf jeder Seite einen [EDIT]-Schalter zu machen, der die zugehörige Backend-Seite öffnet. Das sieht nicht so schick aus, aber es nervt auch nicht mit Scrollbalken.

Die Leute haben auch kein Problem mit der klaren Trennung von Backend und Frontend. Es vermittelt ein Gefühl von Sicherheit, wenn das getrennt ist. VIele meiner Kunden können sich nicht so an den Gedanken gewöhnen, dass nur sie das jetzt können, sie  glauben (und das ist ihnen nicht beizubringen), dass während sie angemeldet sind, JEDER das so sieht.

Ich habe auch schon WB aufgesetzt, wo vorher CMS mit (echtem) Frontend-Edit liefen. Das hat den Leuten anfangs ein wenig gefehlt, letztlich haben sie die erweiterten Möglichkeiten aber dann doch lieber gehabt.

Ich habe auf verschiedenen Seiten so und so laufen. Ein "Heilsbringer" ist Frontend-Edit nicht; eben mehr oder weniger "nett". Natürlich würde ich es begrüßen, wenn WB zumindest die grundsätzlichen Voraussetzungen bieten würde, aber dazu müsste man sich mal auf etwas einigen. Und ganz so einfach ist die Sache ja auch nicht.

Waldschwein:
Hallo!

Naja Prinzipiell ist egal, wie der Editor aussieht - mit dem spartanischen WYSIWYG Modul kann man ja auch jeden x-beliebigen Editor einbinden.

Problem sehe ich darin, dass es schwer ist, grundsätzlich das Backend "echt" ins Frontend zu holen, alleine schon aus unterschiedlichen Hierarchien:
Moduldateien sind in "/wb/modules/modulexyz/blubb", Backenddateien in "/wb/admin/irgendwas/nochwas.php", Frontend kann mal in "/wb/hier.php" oder "/wb/ich/mag/ordner/weil/toll/hier.php" da sein.
Das macht es teilweise (je nach Editor) praktisch unmöglich, mal einfach so ohne Probleme etwas echt ins Frontend zu holen.
Spartanisch? Nicht's leichter als das - der CKEditor (sogar der FCKeditor) kann mit 4 Buttons anstatt 45 auch aufgerufen werden, ohne an der ursprünglichen Installation irgendwas zu ändern.
Für noch spartanischeres eignet sich z.B. nicEdit, gibt's ja auch ein Modul hier.

Der "Edit" Button ist ja nichts neues, der ist sogar fest seit WB 2.8.0 (?) als Dropletbeispiel im Core drinnen.

Wichtig wäre also wenn man wirkliches Frontend-Edit machen will:
- Unbedingtes Vermeiden von Hardcoden und Bereitstellen von Aufrufen von allen gebrauchten Dateien (selbst die des eigenen Modules) ohne jegliche (!) Hierarchien. Ein "../../include.php" reicht aus, ein Modul nur für's Backend zu machen.
- Benutzern auch das Betreten des Backends generell zu unterbinden.
- Keine "Eigensüppchen" wie das mehr schlechte als rechte "/account". Kein Mensch braucht den Ordner wirklich, dafür gibt's doch /admin oder gleich /framework.

Warum eigentlich Frontend-Edit?
Naja, jemand will einen Blog gestalten mit WB. Hier ist es nicht üblich, das Backend groß zu betreten. Nur als ein Beispiel.
Ob man letztendlich reines Backend, ein Mischmasch aus allem (bloß nicht, dann hat man wieder zwei halbgare Lösungen von denen keine zu Ende gedacht ist und nichts mehr funktioniert!) oder echtes Frontend-Edit machen kann ist eigentlich nur Geschmackssache. Mit Sicherheit usw. hat das eigentlich alles nichts zu tun, weil es eher schön aussieht als jetzt bei einem modularen System wie WB eines ist groß zu Problemen führt. Wenn es zu Problemen führt, sind sie sowieso schon da, und werden nur zu Tage gefördert.
Nur ein Mischmasch wie es das in allen Belangen nur nicht im Marketing halbgare Joomla! z.B. aufweist erschwert es dem Benutzer doch nur noch, irgendwie den Überblick zu behalten. Dann reicht ein "Edit this page" Droplet auch, da muss man sich nicht verbiegen.
Das einzige System (das eigentlich auch nur auf jQuery Overlays aufbaut) ist das kommende Drupal7, wo das Backend wirklich "echt" wegfällt, man aber trotzdem irgendwie denkt, man wäre im Backend.
Allerdings ist das System so unterschiedlich von WB (naja, man liest einige Blogs im Netz von Leuten, die "mehr" wollen als WB und dann auf Drupal wechseln, wem's gefällt), dass es keinen Sinn macht, und wir wollen WB bleiben und nicht ein "Woah ist das Toll" Silverstripe oder ModX, wo alle schwärmen aber keiner benutzt.

Gruß Michael

DarkViper:

--- Quote from: chio ---Bei der Entscheidungsfreudi gkeit unserer Anführer wird das noch Jahre dauern.

--- End quote ---
Über dieses Thema wurde bei uns schon lange ausführlich nachgedacht und diskutiert.

Daraufhin wurde es relativ weit zurückgestellt. Derzeit hat der Auf- und Ausbau der Sicherheit absolute Priorität. Fast täglich trudeln bei uns Meldungen von den verschiedensten Organisationen ein, die OS-Software auf Sicherheitslücken prüfen (Secunia etc..). Über 95% der Meldungen betreffen Sicherheitslücken, die teilweise schon seit Anbeginn, also 6 und mehr Jahre bestehen. Zusätzlich kommt das Problem, dass vieles vom alten Code teilweise sehr unsauber gecoded ist und bald jede Lücke, die wir schließen, dadurch wieder neue Lücken aufreißt.

Die letzten Monate hat sich deshalb sehr vieles am Core geändert und es wird noch einiges mehr werden. Der ganze Core sowie das Backend ist zur Zeit praktisch kontinuierlich im Fluss. Bis wir irgendwann das System ausreichend 'dicht' haben.

Zu diesem Zeitpunkt jetzt auch noch Kreuzverbindungen zwischen Front- und Backend (was anderes ist FrontEndEdit nicht) einzubauen ist schlicht Wahnsinn, da praktisch niemand(auch ich nicht) weiß, wie sich die ganzen Bedingungen durch weitere Fixes ändern. Der minimale Komfortgewinn, den eh nur wenige wirklich nutzen, wiegt die damit verbundenen Gefahren auf keinen Fall auf.

Im SVN Verzeichnis /modules/droplets/examples liegt seit einiger Zeit ein neues Droplet [iEditThisPage], das voll in die Rechtestruktur von WB eingebunden ist, XHTML-Code erzeugt und alle Bearbeitungsmöglich keiten einer Seite aufrufen kann. Nur eben nicht im Frontend, sondern in einem neuen Fenster im Backend.

Grundsätzliche Änderungen am System von WB, abgesehen von Standardisierungen der Modulschnittstellen etc., die zwingend notwendig sind um weitere Löcher zu stopfen, wird es in der WB 2-Serie mit Sicherheit nicht mehr geben.

BlackBird:
Die Problematik liegt bei WB eher unter der Haube und ist nicht prinzipiell bedingt. Ich hab mal sowas programmiert (nicht für WB), eigentlich ist das recht einfach, und JavaScript braucht's auch keins. (Es sei denn, man nutzt Ajax.) Allerdings war das CMS in dem Fall auch komplett anders ausgelegt.

Eine relativ einfache Lösung wäre es, dem angemeldeten Admin im Frontend für jeden Block die entsprechenden Buttons zur Verfügung zu stellen. Entsprechend heißt:

* Seitenkontext - Abschnitte verwalten, Seiteneinstellungen verwalten
* Modulkontext - Inhalte verwalten (modify.php)

Ist eigentlich kein Riesenaufwand. Per CSS die Blöcke voneinander abgrenzen (Rahmen drum, fertig) und Kontextbuttons drankleben. Die Links gehen dann ins Backend, das in neuem Fenster/Tab aufgeht. Kein echtes Frontend-Edit, aber immer noch komfortabel.

escpro:
...heisst noch ältere WB Versionen (bspl. 2.6.7, 2.7) sind unsicher ??


--- Quote from: DarkViper on July 27, 2010, 12:14:32 PM ---Fast täglich trudeln bei uns Meldungen von den verschiedensten Organisationen ein, die OS-Software auf Sicherheitslücken prüfen (Secunia etc..). Über 95% der Meldungen betreffen Sicherheitslücken, die teilweise schon seit Anbeginn, also 6 und mehr Jahre bestehen.

--- End quote ---

Navigation

[0] Message Index

[#] Next page