Frontend-Edit Überlegungen

[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]

Bei der Entscheidungsfreudi gkeit unserer Anführer wird das noch Jahre dauern.

Ü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 ??

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.

[BlackBird]

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.

Übrigens wäre es auch eine sehr schöne (Kompromiß-)Lösung, den entsprechenden Teil in einer Dialogbox zu öffnen. (jQuery UI Dialog) Mit "entsprechend" meine ich etwa die Ausgabe der modify.php des Moduls ohne den Backend-Rahmen. Ließe sich relativ leicht mit ein bißchen Ajax realisieren. Das ist zwar immer noch kein echtes Frontend-Edit, aber daß es das im derzeitigen Core nicht geben kann, wurde ja bereits gesagt.

[Waldschwein]

Damit nicht schon wieder der Thread zerpflückt wird mit Angelegenheiten, die nichts mit dem Thema zu tun haben, wurde es geteilt. Für Sicherheit usw. geht's hierlang: https://forum.WebsiteBaker.org/index.php/topic,18860.msg125774.html#msg125774

Hier ist Frontend-Edit.

Gruß Michael

[Stefek]

Hallo,

da ich auch auf Useability stehe,
hier mal meine Überlegungen zu Edit in Place, Frontend Edit und Edit Link zum Backend


Das wären so die verschiedenen Oberbegriffe.
Im Moment gibt es nur dieses Ding mit den Links ins Backend, aber die verweisen auch nicht auf Abschnitte der Seite sondern auf die "Gesamtseite" = ein Link für Edit für alle Sections und alle Blöcke (wenn mehr Blöcke im Template verwendet werden).

Das ist wenig verständlich für den "Normaluser", weil er nicht unbeding immer eine klare, für ihn sinvolle, Linie, zwischen den verschiedenen Abschnitten ziehen kann.

All diese Punkte hier wurden schon besprochen, ich will versuchen, den Kindern jeweils einen Namen zu geben und weitere Überlegungen anstellen.
Wie gesagt, ich habe sehr viel Interesse, dass es so etwas für WB gibt.


EDIT IN PLACE
Das sieht auf den ersten Blick am interessantesten aus. Man klickt den EDIT Knopf und kann genau an der Stelle editieren, wo der Block/Section steht.

Probleme die damit einhergehen:

• Ein richtiges "Edit in Place" hängt auch von den dazugehörigen CSS Files ab. Verschiedene Blöcke (nicht Sections) können unterschiedliche Hintergründe und andere unterschiedliche Style angaben haben, sodass es schwierig werden könnte, ein voll integriertes "Edit in Place" zu gewährleisten".
• Außerdem sind einige Blöcke zu schmal, um da auch gleich die Schaltflächen des Editors drin zu haben.
• Dann gibt es das Problem, dass Änderungen sofort "scharf" sind, aber das ist ohnehin so bei WB, es sei denn, man verwendet Thorns History Patch.

Sieht recht kompliziert aus, das alles "schön" hin zu bekommen.
Für nicht-WYSIWYG Module müßte dann ohnehin eine andere Lösung her.

FRONTEND EDIT
Das ist eine interessante Sache. Eben das, was Bianca beschrieben hat:

Übrigens wäre es auch eine sehr schöne (Kompromiß-)Lösung, den entsprechenden Teil in einer Dialogbox zu öffnen. (jQuery UI Dialog) Mit "entsprechend" meine ich etwa die Ausgabe der modify.php des Moduls ohne den Backend-Rahmen. Ließe sich relativ leicht mit ein bißchen Ajax realisieren.

Aber auch hier gibt es Probleme, weil die Module nicht alle einheitlich sind.
Wenn ich da an die "Modify" des Guestbooks denke, oder des "Form" Moduls - viele Einträge können sich echt langziehen.
Aber es wäre durchaus vertretbar.
Aber es gibt auch Module wie eben Guestbook, wo man das "Frontend-Edit" in der view.php integrieren könnte.
Szenario: ich logge mich ein, um das Guestbook zu bearbeiten und sehe im FE die neuen Beiträge (da eingeloggt) in einem abweichenden Stil (einem, der unmißverständlich zeigt, dass die noch nicht freigeschaltet sind).
Ich kann gleich im FE entscheiden, ob ich es freischalte/lösche, die Buttons sind da. Auch ob ich eines korrigiere oder einen Kommentar dafür schreibe.
Bei diesem Modul wäre es viel praktischer und mit etwas AJAX und Verständnis für Sicherheit könnte man das durchaus machen.

Dann gibt es noch die dritte Kategorie:
LINK ZUM BACKEND
Das allein würde schon viel mehr Komfort bringen und vielen "Editoren" die Arbeit erleichtern.

Für gewöhnlich gibt es bei jeder Section, die in WB angelegt wird, einen Anchor-Tag, etwa
<a class="section_anchor" id="wb_193" name="wb_193">
Man könnte diese Anchors so präparieren, dass man im Eingeloggten Zustand, wenn man an dem jeweiligen Abschnitt (Section) Editoren-Rechte hat, einen EDIT-BUTTON zu Gesicht bekommt.
Vielleicht könnte man es so arrangieren, dass auch der ganze Bereich "umrahmt" wird, wenn man eigeloggt ist - nicht markant, aber wahrnehmbar.
Das würde den Editoren immer einen guten Überblick über deren  "editierbaren Bereiche" vermitteln.
Normalerweise sind die Backends so vorgesehen (auch wenn sich zwischenzeitlich ein Bug eingeschlichen hatte), dass jeder Abschnitt im Backend ebenfalls einen Anker hat, sodass solch ein Link direkt zu dem Abschnitt im Backend "springen" würde.


Als general Lösung, dürfte die dritte am einfachsten und sogar vom CoreTeam vertretbar sein.

Mir persönlich gefällt aber auch die "mittlere Lösung", die auch Bianca angesprochen hat.
Aber es würde nie ein einheitliches Ding werden, weil nicht jedes Modul das unterstützen würde - also nicht ohne anpassungen.

Edit-in-Place würde für die wenigsten Module überhaupt Sinn machen.
Ich mag die Idee, aber zu utopisch.
(Vielleicht gut für WYSIWYG, aber nur, wenn man adäquate CSS fies für den Editor bereitstellt).


Am meisten gefällt mir die 3te Idee - zum derzeitigen Zeitpunkt.
Mit viel Mühe und Arbeit könnte man eine gute Handvoll Module so überarbeiten, dass sie auch mit der "mittleren Edit in Place" Lösung gut arbeiten. Das aber müßte eine Schulter an Schulter anstrengung sein, und da wir uns hier alle gegenseitig kennen und wissen, wie scharf hier die eigenen "Genialitäten" vertreten werden, wird es nicht kommen.

Aber durchaus kann es sein, dass der eine oder andere das ein oder andere Modul auf diese Weise umsetzt und dann gibt es zumindest einige Module, die das "haben".



Das waren einfach nur ein paar Ideen, die ich mal mitteilen wollte.
Und während ich das schrieb, ist mir auch aufgefallen, wieviele unterschiedliche Ideen man dazu haben kann.

Ich freue mich zu sehen, wer mit der ersten guten Umsetzung kommt.

Stefek

[chio]

Danke Stefek, man merkt, dass du dich ebenfalls schon viel mit dem Thema befasst hast.

Wie gesagt habe ich bei Topics 0.6 bereits einen Anlauf gemacht; eher mal zum Testen, wie sich das anfühlt. Über "Theorie" kann man viel reden, und nicht jede gute Idee hält in der Praxis.

"Edit in Place" - ja: Ich habe schon mit CMS zu tun gehabt, in denen das funktioniert. Ist allerdings _sehr_ schwierig anzupassen; das schnell mal gemachte Template gibt es dann nicht mehr. Alles muss genau aufeinander abgestimmt werden.
Sind auch meistens teure Teile (Grundpreis + Anpassung + Wartung)

Frontend-Edit (mit Overlay)
Das macht eigentlich nur dort Sinn, wo schnell mal was geändert werden soll - oder wo Leute was machen sollen, die gar nicht ins Backend sollen.
"Optionen" haben da gar nichts verloren drin. Alles was zu Grundeinstellungen gehört, sollte im Backend bleiben. Damit sind ohnehin schon viele Module _keine_ Kandidaten mehr; eventuell gerade mal Gästebucheinträge löschen/Freischalten kann ich mir vorstellen.
Bei WYSIWYG, News, Topics usw - da funktioniert das gut, da könnte man einfach ein kleines Schalterchen dranhängen, sobald man angemeldet ist.

Was aber sein MUSS: Das Werkel zum Laden des iFrames, Schatten, Kram muss vom Core zur Verfügung gestellt werden. Es kann nicht sein, dass der eine FancyBox verwendet, der andere Colorbox und der Dritte sonstwas.
Es braucht einheitliche Klassen.

Und - was ebenfalls nicht schlecht wäre: Eine einheitliche Art, wie die Unterscheidung Frontend/Backend gemacht werden soll. Bei Topics schleife ich einen Parameter "fredit=1" durch. Wahrscheinlich besser wäre es aber, einen Wert in der $_SESSION zu speichern.

Ich könnte mir auch gut eine Mischform vorstellen: Das eine Modul öffnet im Frontend mit Overlay, das andere geht einfach ins Backend. Warum nicht?

[Waldschwein]

Hallo!

Ich versuche mal auf der Basis des neuen Droplets "iEditThisPage" etwas zusammenbasteln - das funktioniert soweit schon recht gut ohne Anpassung, halt nur eben (noch) nicht per Abschnitt. Wenn es mit einem Droplet funktioniert, kann man ja sicherlich auch ein "echtes" Modul machen, wenn es sein soll.
Bestimmt muss es die eine oder andere Änderung im Core geben, aber gut, es ist nicht aller Tage abend.
Dass das Backend dann per jQuery reinfliegt kann evtl. sogar ohne Coreanpassungen funktionieren, mal gucken.
Probleme gibt's bestimmt viele, aber gut, man muss ja auch ein Ziel nach der WB 2.8.2 haben.  

Für Edit in Place - nunja, ich denke, da müsste sehr viel angepasst werden an manchen Modulen. Irgendwie muss man halt einen Kompromiss aushandeln - aber warum muss man zwingend das Backend vollständig außen vor lassen, man kann sich ja Teile davon ins Frontend holen (zumindest, dass es so aussieht).
Sowas wie bei Joomla sollte man auf jeden Fall hinbiegen können, es muss ja vorerst mal nicht (mit WB 2.x eh kaum noch) die Deluxeversion sein.

Edit: Soll natürlich keinen abhalten, selber etwas zu machen, am Ende gewinnt eh das, was gefällt. Und wenn es unterschiedliche Lösungen gibt - umso besser, kann man am Ende sich das Beste aus allem Holen und irgendwie vereinen.

Gruß Michael

[DarkViper]

Dieses Thema ist, von unserer Seite, für die 2er Serie zu den Akten gelegt. Der Aufwand ist einfach viel zu hoch, um derartige Funktionalität wirklich sauber, transparent und sicher einzubinden. Auch ist die Zukunft der 2er Serie nicht auf die Unendlichkeit ausgelegt. In absehbarer Zeit (nein, nicht heute oder morgen..  aber evt. in 1-2 Jahren) wird die Weiterentwicklung eingestellt werden, da sie einfach den Anforderungen der Zeit nicht mehr genügt.

Auch der Trabbi ist Geschichte, die wir nicht wieder aufleben lassen werden. Also nichts mehr mit 275 Schichten Heftpflaster und Superplaste übereinander... und notfalls noch ein paar Tesastreifen...
frei nach dem Motto: Egal wie... Hauptsache es läuft.
Derartiges ist schlichtweg Bockmist und Murks. (um mal Klartext zu reden)
[ein angestellter Programmierer dürfte hier nach solchen Vorschlägen den Schreibtisch hochglanzpolieren.. . für seinen Nachfolger]

In der Folgeserie wird es anders aussehen, da kann von vornherein ein Snappin-System aufgebaut werden, das es erlaubt, beliebige und vor allem auch geeignete Backendmasken ohne komplizierten Aufwand und vor allem ohne vorher ein IT-Studium zu absolvieren, flexibel im Frontend 'einzuhängen'.

WB ist und wird bleiben: Ein Content-Management-System, das auch für unbedarfte Webmaster sehr einfach und intuitiv zu installieren, zu warten und nutzen ist. Das ist unser Ziel und wird es auch in Zukunft verstärkt sein.

WB ist mit Sicherheit keine Spielwiese, keine Plattform, die nur dazu existiert, damit sich Moduleentwickler und Coder (ich sag jetzt ganz bewusst nicht 'Programmierer') austoben und selbst verwirklichen, ihr Ego stärken und dabei das eigentliche Ziel aus den Augen verlieren.

Ein Ziel sollte nicht sein: mehr.. mehr.. mehr.. egal was es kostet...
sondern:  wie erreichen wir, dass Bestehendes noch einfacher, noch intuitiver und vor allem noch sicherer gemacht werden kann?

[BlackBird]

... damit sich Moduleentwickler und Coder (ich sag jetzt ganz bewusst nicht 'Programmierer') ...

Erinnert mich an den Film "Dragonheart":

„Ihr weigert Euch mich Drachen zu nennen und nennt mich stattdessen Drachen in einer anderen Sprache?“

http://dict.tu-chemnitz.de/dings.cgi?lang=de&noframes=1&query=coder

[Waldschwein]

Um einfach einen Denkanstoß zu geben, ein kleiner Blick über den Tellerrand, wie es auch ohne "echtes" Frontend-Edit gehen kann (nein, wir wollen es nicht so, sonst bräuchten wir kein WB, nur eben zusammengefasst das, was wohl auch Stefek als kleinsten Kompromiss bezeichnet hat, bitte nicht hauen wegen Qualität usw.):

http://www.youtube.com/watch?v=a4AW4qC31xk

Gruß Michael

[chio]

Was ich sehe geht es ohnehin nur mehr um Frontend-Edit im Overlay. "Edit in Place" ist zu schwierig, Link zum Backend ist ohnehin banal.

Das, was ins Overlay reinkommt, muss ohnehin vom Modul her kommen - hat an sich mit dem Core nichts zu tun.
Das Modul erzeugt einfach einen Link mit Klasse "frontend-edit" (zb) und target="_blank". Fertig.

Der Haken: Es muss einen Standard geben, wie das gehandelt wird. Es kann nicht sein, dass jedes Modul seinen eigenen Kram mitnimmt und dann hat man 3 verschiedene Plugins im Header, die kein Mensch braucht.

Und es sollte eine WB-eigene Lösung sein, die man unter Kontrolle hat. Man sollte ihr zb Parameter für die gewünschte Breite übergeben können. Die Höhe sollte sich selbst anpassen, bis zum Maximum der Monitor-Höhe. Oder eben die ganze Höhe. Geht ja auch. Wo sind die jQuery.-Versteher (ich bin nur Frauen-Versteher

Das könnte ein Modul sein, bzw ein Snippet wie FancyBox, das man einfach ins Template steckt, wenn man FE will. Eventuell könnte das Snippet eine Konstante FREDIT_PRESENT oder so definieren, dann weiß jedes Modul, dass alles vorbereitet ist und kann je nachdem ins Frontend oder ins Backend verlinken.

Die FancyBox selbst geht aus Kompatibitätsgründe n nicht, da liegen schon zuviele Eigenbasteleien herum.

Man müsste sich einfach auf was einigen. Ich bin willens.

[mr-fan]

Wäre das hier vielleicht eine Überlegung wert?

Könnte Thomas da vielleicht mal eine kurze Stellungnahme geben?

https://forum.WebsiteBaker.org/index.php/topic,18857.0.html

warum ich da drauf komme.....(durfte ja mittesten)?

Weil das Dashboard:

a) Snippets bzw. Filter (ich finde Filter hört sich zu unmächtig an...)
b) mit einem einfachen Backend "steuerbar" ist z.b. checkboxen für an/aus und noch mehr
c) sich damit auch scipte laden lassen
d) sich das Snippet je nach Seite UND sogar nach Modul einstellen lässt =>sieht ein Mod scheiße im Overlay aus einfach deaktivieren ginge!

usw.

würde aus Laiensicht danach schreien dafür Verwendung zu finden?

Außer ich hab natürlich was übersehen z.b. das OPF Dashboard zu spät greift oder keine Konstanten definieren kann....daher meine Frage an Thorn.
Verlinke es mal kurz quer!

Grüße Martin

[thorn]

Hallo,

ein Frontend-Edit kann nur mit Hilfe des jeweiligen Modul-Backends funktionieren. Nur das Modul weiß wie und wo die Daten gespeichert werden müssen - und was zur Anzeige im Frontend-Edit nötig ist.

Das, was ins Overlay reinkommt, muss ohnehin vom Modul her kommen - hat an sich mit dem Core nichts zu tun.
Das Modul erzeugt einfach einen Link mit Klasse "frontend-edit" (zb) und target="_blank". Fertig.

Der Haken: Es muss einen Standard geben, wie das gehandelt wird.

Stimmt absolute.


opf kann da erstmal wenig machen. Ja klar JS einbringen, HTML ändern - das geht alles -- das wäre aber erst der letzte Schritt, wenn es darum geht, wie man das Overlay (JS) anzeigen/laden läßt.


thorn.

[Stefek]

was wohl auch Stefek als kleinsten Kompromiss bezeichnet hat, bitte nicht hauen wegen Qualität usw.

Hallo Michael,
als kleinsten "Nenner" meinte ich:
 

Wie gesagt, ich habe sehr viel Interesse, dass es so etwas für WB gibt.
[...]
Dann gibt es noch die dritte Kategorie:
LINK ZUM BACKEND
Das allein würde schon viel mehr Komfort bringen und vielen "Editoren" die Arbeit erleichtern.

Für gewöhnlich gibt es bei jeder Section, die in WB angelegt wird, einen Anchor-Tag, etwa
<a class="section_anchor" id="wb_193" name="wb_193">
Man könnte diese Anchors so präparieren, dass man im Eingeloggten Zustand, wenn man an dem jeweiligen Abschnitt (Section) Editoren-Rechte hat, einen EDIT-BUTTON zu Gesicht bekommt.
Vielleicht könnte man es so arrangieren, dass auch der ganze Bereich "umrahmt" wird, wenn man eigeloggt ist - nicht markant, aber wahrnehmbar.
Das würde den Editoren immer einen guten Überblick über deren  "editierbaren Bereiche" vermitteln.
Normalerweise sind die Backends so vorgesehen (auch wenn sich zwischenzeitlich ein Bug eingeschlichen hatte), dass jeder Abschnitt im Backend ebenfalls einen Anker hat, sodass solch ein Link direkt zu dem Abschnitt im Backend "springen" würde.
[...]
Am meisten gefällt mir die 3te Idee - zum derzeitigen Zeitpunkt.

Was Du da verlinkt hast ist eher die 2te, mittlere Variante und das, was auch Chio vorzuschweben scheint.

Chio hat Recht, man müßte es nicht für jedes Modul haben.
Natürlich ist das komfortabler, als ein "banaler" Link ins Backend - aus meiner Sicht ist es aber dennoch komfortabler, als gar nichts im FE zu haben, anhand dessen sich der Editor orientieren kann.

Über technische Aspekte und Umsetzungsmöglichke iten will ich gar nicht anfangen nachzusinnen.
Einfach machen, ist besser.
Dann hat man vielleicht mehrere Sachen von verschiedenen Programmierern (denn das Wort triffts), von denen man dann eine brauchbare übergreifende Lösung ausarbeiten kann.

Rein von der Idee her, wurde ja von Chio angesprochen:
im FE müßten diese ganzen Settings usw. vielleicht gar nicht rein (in so einer Modal-Box).
Aber vielleicht sollte das mit den Modulen und FE und BE komplett neu überdacht werden, dass man das, was als Section im Backend ist über die selbe Schnittstelle sowohl für das BE alsauch das FE nutzbar ist.
Die Settings usw. sollten nach Möglichkeit auch lieber nur bestimmten Editoren zugänglich gemacht werden.
Heute ist es bei den meisten so, dass wenn man Schreibrechte am Page-Modul hat, dann hat man eben Schreibrechte und kann auch in die Optionen/Settings des Page-Moduls einsehen und ändern (heute kriegt man das nur hin, wenn man es selbst für dieses Modul programmiert, eine Schnittstelle wäre aber nicht nur denkbar, sondern auch von Vorteil).

Sollten die Module für eine kommende Version vielleicht von vornherein einfach eine andere Struktur haben, sodass man sie "bereits aus der Box" auf einheitliche Weise ausschmückt, die dann eben die verschiedenen Vorteile haben: FE Edit, Rechtevergabe am Modul.

Es gibt vieles, was an einer unabhängigen WB Version besser gemacht werden könnte.
Neben den oben erwähnten Features, die heutzutage auch in vielen modernen CMS eingesetzt werden, könnte man auch neu über die einbindung von jQuery für FE&BE nachsinnen (nicht dass ich mir jQueryAdmin nicht angeschaut hätte). Einen vernünftigen OutputFilter (Thomas hat ganze Arbeit geleistet) integrieren und endlich ein vernünftiges BackendTheme kreieren, das nicht nur gut aussieht, aber auch sinvoll ist.

Aber dafür müßten sich die Programmierer zusammen tun.

Werner, bei allem Respekt - aber zu zweit schafft ihr das nicht.
Jeder hat seine Vorstellungen vom Ideal - nur dass Du jetzt "am Ruder" bist, heißt nicht, dass Du im Interesse aller die besten Ideen voranbringst. Niemand ist so allgegenwärtig, alsdass er alle Gesichtspunkte vertreten könnte.
Und zu sagen, dass alles andere "Murks" oder "nette Ideen" sind, ist ... (ich schreibs lieber nicht aus).

WebsiteBaker hängt leider zwei Jahre hinterher.
Eins wurde damit vergeudet Ryan loszueckeln, das andere, um einen Verein zu gründen.

Es ist kein Wunder, dass manche Leute einfach mehr wollen - sie hören auf die Stimme des Zeitgeists.

WB ist mit Sicherheit keine Spielwiese, keine Plattform, die nur dazu existiert, damit sich Moduleentwickler und Coder (ich sag jetzt ganz bewusst nicht 'Programmierer') austoben und selbst verwirklichen, ihr Ego stärken und dabei das eigentliche Ziel aus den Augen verlieren.

Woher weißt Du, was die Ziele anderer sind?
Die Module haben einen Zweck.
Was der Programmierer sonst für ein Ziel hat ist mir sowas von Laterne..

So far..
Stefek

[BlackBird]

Ich staune, denn ich stimme Stefek zu.

[BlackBird]

Übrigens, ständig auf den Modulentwicklern rumzuhacken (es sind ja wohl ganz bestimmte gemeint), statt vielleicht mal zu hinterfragen, warum bestimmte Dinge so gemacht wurden, wie sie gemacht wurden, ist auch nicht zielführend, sondern vergiftet lediglich das Klima. Letztlich klingt nur durch, daß alles, was die Modulentwickler machen, Mist ist, weswegen die teils wirklich guten Ideen - und ich spreche nicht von meinen *g* - dann ihren Weg nie in den Core finden. Was für ein Verlust. (Und das meine ich nicht sarkastisch.)

[mr-fan]

Und schwups wirds schon wieder politisch hier...Oh Mann bleiben wir mal bei dem spannenden Thema um:

Einfach machen, ist besser.

Ich meinte das hier:

Frontend-Edit im Overlay. "Edit in Place" ist zu schwierig, Link zum Backend ist ohnehin banal.
Das, was ins Overlay reinkommt, muss ohnehin vom Modul her kommen - hat an sich mit dem Core nichts zu tun.
Das Modul erzeugt einfach einen Link mit Klasse "frontend-edit" (zb) und target="_blank". Fertig.

und das hier:

Das könnte ein Modul sein, bzw ein Snippet wie FancyBox, das man einfach ins Template steckt, wenn man FE will. Eventuell könnte das Snippet eine Konstante FREDIT_PRESENT oder so definieren, dann weiß jedes Modul, dass alles vorbereitet ist und kann je nachdem ins Frontend oder ins Backend verlinken.

könnte man über den OPF Dashboard einbauen und steuern je nach Seite/Modul ein/anschalten und sehr sehr einfach  "administrierbar" machen...

@Thorn:
kann man mit dem dashboard alles nötige bereitstellen das dann von Modulen einfach wie von chio angedeutet genutzt werden kann?

Wenn ja hätte man für die Darstellung/Anzeige schon einmal eine Lösung die passt!

Ok ist wie Thomas schon sagte der 2. Schritt vor dem 1. ->aber wie das dann in den Modulen am _einfachsten_ zu handeln ist müssen sowieso die Modulentwickler oder das Dev Team bestimmen.

Wenn das Dev Team nicht an dieser Baustelle arbeitet wie angekündigt und auch legitim, weil einfach zuviel anderes wichtig ist für die 2.8.2!

...gibt es 2 Möglichkeiten:

=> einzelne Lösungen ->z.B. Topics

=> eine Basis für Module auf die man sich einigt

genau aus diesem Grund hat Chio nämlich das Thema hier eingestellt und nicht um festzustellen wer was wie und warum "denkt" oder "gemacht" hat! Das wissen wir - die hier regelmäßig mitlesen schon!

Also Praktikable Vorschläge für die Module bitte wie es sinnvoll und einfach gehen könnte...

Gruß Martin

[chio]

Mit dem Output-Filter wird es nicht gehen, weil ich den Modulen ja _vorher_ mitteilen muss, dass FE angewandt werden soll.
Es muss also ein Snippet/eine function im Head sein, das erst mal checkt, ob der User angemeldet ist, und wenn ja das Werkel startet.
Spricht - technisch - was dagegen, das mit einer Konstanten zu machen? if (defined("FRONTEND_EDIT"))... blabla
Ich sehe keinen Grund, FE an- und abschaltbar zu machen. Letztlich gelten die Berechtigungen wie im Backend. Das sollte reichen.

Konkret - was braucht es:
Im Core und den Admin-Template FIles müssen ein paar target="_top" entfernt werden.

Die Schnittstelle und das Handling für die Module muss definert sein: Welche Klassen, welche Parameter.
Wer will, kann dann ja in Topics reinschauen, wie das gelöst ist. Ist an sich kein Theater. Gibt sicher auch andere Möglichkeiten, aber das ist egal wie mans macht, solange das selbe rauskommt.

Der größte Brocken: Ein Modul, das den jQuery-Kram bereitstellt.
2 Klassen sollten reichen: "frontend_edit" und "frontend_edit_modal"

Ähnlich wie Fancy-Box, aber eben etwas anders:
- Transparente Overlay-Fläche: Sieht schicker aus und vor allem: Blockt Klicks auf Links darunter.
- Es sollte per Parameter Breite und (Start)Höhe übergeben werden können (...&few=640&feh=400)
Höhe nur der Startwert, die letzliche Höhe sollte sich an den Inhalt anpassen, sobald er geladen ist.
- beim Schließen der FE-Box sollte die Seite neu geladen werden, aber gleich wieder auf den selben scroll_off gesetzt werden.

In diesem Modul ebenfalls gleich enthalten: Header & Footer des Frontend-Edit Templates. Und: Das Bildchen, das den Edit-Link bekommt. Dann ist es einheitlich und jedes Modul verwendet das gleiche.

Wenns das mal gibt, kann es jeder auf seiner Site verwenden. Es werden mehr und mehr Module FE-tauglich sein.
Ob und wie das ganze in den Core kommt, das ist mir reichlich egal.

[Waldschwein]

Hallo!

Nur kurze Erklärung zu jQuery: Das ist überhaupt kein Problem, jQuery irgendwo einzubauen. Da braucht man auch kein externes Modul, da kann man auch auf WB-eigenes (oder Modul-eigenes) zurückgreifen.
Wichtig ist auch, dass man irgendwie einen "Rahmen" definiert, den man rauslösen kann. Wie zum Beispiel das WYSIWYG Modul, das fest im Backend vorhanden ist, muss ja irgendwie genauso in Frontend übertragen werden, oder einfach nur aufgerufen werden.
jQuery macht mehr oder weniger alles möglich.
Es ist nichts anderes als ein Farbfilter auf einer Kamera. Die Kamera interessiert es absolut nicht, ob da jetzt ein Farbfilter draufliegt oder nicht - Hauptsache der Filter passt auf's Objektiv drauf.
Genauso ist es auch mit jQuery. Du hast dein HTML / CSS Grundgerüst, klatschst einfach jQuery Funktionalität á la "Nimm Klasse XY, mach aus dem ganzen ein Overlay, füge Parameter ABC hinzu, dass es den Rahmen sowieso, die Transparenz xx%, Höhe DEF usw. hat" hinzu und fertig ist es.

http://jqueryui.com/demos/dialog/
Genauso wie es sein soll wäre wohl: http://flowplayer.org/tools/demos/overlay/styling.html
Der Parameter kann sicher irgendwie übertragen werden, das funktioniert grundsätzlich mit PHP zu JavaScript ohne Probleme (kenne ich z.B. von den ganzen WYSIWYG Editoren, das WYSIWYG Modul macht das ja auch alles, Höhe & Breite zu übertragen an etwas, was keinerlei PHP versteht).

Gruß Michael

[chio]

Joup! Wenn du sagst, das ist kein Problem alles..
Das freut mich, dann haben wir ja schon wen, der has hinbekommt

Nebenbei:

"Given a choice between dancing pigs and security,
users will pick dancing pigs every time."

Du hast völlig recht, WB braucht wieder mal "dancing pigs".
Etwas, wo man _sieht_, dass es Entwicklung gibt. Frontend-Edit wäre sowas...

[escpro]

gibts schon seit mehr als 2 jahren als "etop" wer lust dazu hat kann ja mal damit die escpro suche füttern
oder mal die Template-screens durchwühlen.
Ablauf:
Nach anmeldung anmeldepanel
shorttags die auch "während" der bearbeitung zur verfügung stehen ... um zbspl einen Prozess zu beschleunigen wie
"Ich möchte mal schnell den Inhalt dazu ändern und dazu die Metas ergänzen"

Gut ich hab ja schon vor Jahren mal "angefragt" aber da inter es ja keinen ...  es gibt dazu nur positives Feedback und seither gehen keine (escpro)Seiten mehr "ohne" raus.

hoffe geholfen zu haben

escpro

PS: derzeit wird wg einem Shopsystem ein neues umgesetzt - werd mal nen film dazu machen was "geht"


[gelöscht durch Administrator]

[escpro]

achja ... dialog wurde bei der alten pfatter sete integr..
http://www.escpro.de/esc/posts/pfatter---regional-stark-124.php

2 snippets und flutscht in jeden Template

Hallo!

jQuery macht mehr oder weniger alles möglich.....

http://jqueryui.com/demos/dialog/