WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: chio on July 27, 2010, 10:22:31 AM
-
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.
-
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
-
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.
-
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.
-
...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.
-
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.
-
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
-
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
-
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?
-
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. :-D
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
-
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?
-
... 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
-
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
-
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.
-
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
-
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.
-
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 (http://de.wikipedia.org/wiki/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
-
Ich staune, denn ich stimme Stefek zu. :-D
-
Ü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.)
-
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
-
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.
-
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
-
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...
-
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]
-
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/
-
Naja - dann ist dieser Teil ja einfacher als ich gedacht habe.
Ein Modul muss es trotzdem werden, weil es weitere Dateien gibt, die an einem festen Ort sein müssen.
Header, Footer, Bildchen zb.
Außerdem sollte es möglich sein, die Dinger auszutauschen.
-
Mir und ein_paar_anderen reichts :-P
aber vorsicht: wer einmal drinsteckt kommt aus der Frontend-Sucht nicht so schnell wieder raus!
Naja - dann ist dieser Teil ja einfacher als ich gedacht habe.
Ich versuchs mal anders...
Wo sollen sich denn die "Bildchen" bei dir befinden ? /modules/deinirgendwas/ ?
Evtl ist es sinnvoll mal zu überdenken was wirklich der user anstellt und wer der user ist. denn da steckt ansich der Wurm in allem.
Ein Modul muss es trotzdem werden, weil es weitere Dateien gibt, die an einem festen Ort sein müssen.
Header, Footer, Bildchen zb.
-
Mir und ein_paar_anderen reichts :-P
In welchem Bezug und was reicht?
Naja, eigentlich haben wir doch schon das Backend im Frontend - ich sage ja nur der ominöse "account" Ordner.
Wenn ich mir den Account so ansehe, ist er ziemlich losgelöst vom Core - mehr oder weniger komplett.
Würde man also "account" als Modul erstellen, hat man eine vollständige Backend-Funktionalität komplett im Frontend.
Daher kann es eigentlich gar nicht so schwer sein, bzw. müsste sogar ohne jegliche WB Coreänderung es geschehen. Ich meine, man kann per Modul show_menu(2), PHPlib, Einstellungen usw. "umgehen", also sollte es wirklich kein Problem darstellen, Frontend-Edit echt & ernsthaft zu ermöglichen.
Wo Bildchen usw. sind, kann man doch alles definieren. Natürlich wäre zu überlegen, nicht einfach ein Frontend-Edit Modul als mehr oder weniger eierlegende Wollmilchsau zu erstellen - wobei wohl für so etwas manche kein Verständnis haben und mir dann doch irgendwo das Handwerkszeug, respektive die Entwicklererfahrung fehlt.
JavaScript (also auch jQuery) ist ein sehr weites Feld. JavaScript kann genauso kompliziert und umfangreich sein wie PHP (man sehe sich einmal die YUI Dateien in /includes an), aber auch sehr mächtig.
Was sollte ein Frontend Edit Modul können?
Auswahl & Abschnittsweises Konfigurieren des Editors.
Geht alles - gucke z.B. hier http://ckeditor.com/demo
Problem:
Wer hat welchen Editor installiert? Das Frontend Edit Modul müsste einen Editor mitliefern.
Hier wäre der von Willy Wonka vorgeschlagene Aloha http://aloha-editor.com/index.html nicht so schlecht. Alternativ sollte es evtl. noch eine Schnittstelle zum FCKEditor geben - auch den kann man ohne Probleme angepasst aufrufen.
Eigentlich alle Editoren haben dasselbe System - man ruft den Editor auf, passt einiges an usw.
Übrigens wären hier Presets zu empfehlen - man erstellt sich verschiedene Presets und ruft dann nur noch dieses auf.
Ich habe das alles schon einmal hier https://forum.WebsiteBaker.org/index.php/topic,18593.0.html aufgegriffen, allerdings nicht nur in Bezug auf Frontend.
Wichtig ist nur, dass man sich nicht auf einen einzelnen Editoren versteift, was aber wegen Presets kein Problem darstellen sollte. Dann kann man sogar für Modul X Editor Y und für WYSIWYG einen anderen nehmen. Groß sind die kleineren Editoren alle nicht - zumindest kleiner als das langweilige Editarea allemal (50-80kb).
Anpassung vom Design & Funktionalität
Ist ja logisch eigentlich. Man muss ja nicht alles zusammenklicken, aber zumindest rudimentär sollte man eine Möglichkeit bekommen, ohne großartige externe Module, die wieder Module, die wieder... Also einfach eine x-beliebige Datei und / oder Datenbankeintrag mit den Anweisungen: "Frontend Edit soll dies und jenes von jQuery nehmen, und daraus dann einen Overlay mit den und jenen Eigenschaften machen". Im Prinzip kann man das Ganze analog zu den Editoren machen - der Unterschied ist praktisch nicht vorhanden, gerade weil heutzutage das JavaScript alles ein wenig nach jQuery aussieht - auch das der Editoren. Ob Presets - nun, schön wäre es ebenfalls.
Wer darf was machen?
Problem:
WebsiteBaker hat (noch) keine Möglichkeit, dass registrierte Module selbstständig Zugänge erteilen können. Gleichzeitig kann man ja aber festlegen, wer welche Seite wie ansehen / editieren darf. Hier muss darauf geachtet werden, dass die ganzen Einstellungen wer was machen darf im Backend-Seitenbaum auch übernommen werden und ohne Herumtricksen laufen.
Soweit mal erste Überlegungen.
Gruß Michael
-
Naja, eigentlich haben wir doch schon das Backend im Frontend - ich sage ja nur der ominöse "account" Ordner.
Nee... das ist nich Backend im Frontend - das ist doppelter Code.
Wer darf was machen?
Problem:
WebsiteBaker hat (noch) keine Möglichkeit, dass registrierte Module selbstständig Zugänge erteilen können. Gleichzeitig kann man ja aber festlegen, wer welche Seite wie ansehen / editieren darf. Hier muss darauf geachtet werden, dass die ganzen Einstellungen wer was machen darf im Backend-Seitenbaum auch übernommen werden und ohne Herumtricksen laufen.
Im Baum wird das nicht reichen. Und abgesehen davon, sieht man im PageTree nicht einmal die Sections und deren verwendeten Module.
Es sollte im Modul selbst definiert werden können.
Sprich -> das Modul sollte bei der Installation ein Feld mit installieren, wo ein Array der Rechte als String gespeichert wird.
Zumindest solange es keine zentralisierte Stelle gibt, wo Rechte an Sectionen gespeichert werden.
Gruß,
Stefek
-
Im Baum wird das nicht reichen. Und abgesehen davon, sieht man im PageTree nicht einmal die Sections und deren verwendeten Module.
Es sollte im Modul selbst definiert werden können.
Sprich -> das Modul sollte bei der Installation ein Feld mit installieren, wo ein Array der Rechte als String gespeichert wird.
Zumindest solange es keine zentralisierte Stelle gibt, wo Rechte an Sectionen gespeichert werden.
Gruß,
Stefek
Also das Modul sollte nicht selbstständig Rechte verteilen - natürlich kann ich über einen Array zu String (Hrm... ich mag kein implode) jetzt lustig herumfurwerken - aber das wäre dann eine Insellösung, die keinen Sinn macht.
Was passiert, wenn man eine neue Seite erstellt?
Wenn man Abschnitten selbst übe WB keine Rechte zuordnen kann, sollte man das aus meiner Sicht vorerst auch lassen. Man kann ja trotzdem ein Modul erstellen - das frägt halt vorerst nur die Seiten- und Modulberechtigung ab und fügt nicht irgendwas selbst hinzu. Das ist nicht tragbar, gerade in Hinsicht auf Upgrades.
Gruß Michael
-
Also das Modul sollte nicht selbstständig Rechte verteilen - natürlich kann ich über einen Array zu String (Hrm... ich mag kein implode) jetzt lustig herumfurwerken - aber das wäre dann eine Insellösung, die keinen Sinn macht.
Was passiert, wenn man eine neue Seite erstellt?
Wenn man Abschnitten selbst übe WB keine Rechte zuordnen kann, sollte man das aus meiner Sicht vorerst auch lassen. Man kann ja trotzdem ein Modul erstellen - das frägt halt vorerst nur die Seiten- und Modulberechtigung ab und fügt nicht irgendwas selbst hinzu. Das ist nicht tragbar, gerade in Hinsicht auf Upgrades.
Gruß Michael
Es gibt bessere Funktionen als implode, um Arrays in der DB serialisiert zu speichern.
Natürlich könnte man das lassen, will aber grade verwendet werden, dann muss man das Modulabhängig machen.
Und ähnliche Verfahren werden bereits verwendet, um zu bestimmen, wer welche Rechte am Modul hat (Bsp. Bakery).
So lange sich am Core nichts ändert, muss drumherum gewerkelt werden, ob es jemandem gefällt oder nicht.
Chios FE Edit ist ja auch "drumherum" gebaut, weil das Core nichts bereithält und das Core-Team sich nicht darum bemüht (nicht in der "zweier Reihe" - kannst Du weiter oben lesen).
Und was soll sein, wenn man eine neue Seite erstellt?
Man kann dem Modul "Standardwerte" einstellen, die bei jeder neuen Section übernommen werden und dann in den Sections section-individuelle Werte einstellen.
Du weißt doch, wei eine Datenbanktabelle aussieht, oder nicht?
Stefek
-
Stefek, wir müssen jetzt nicht zeigen wer besser programmieren / coden / was auch immer kann.
Es geht hier darum, eine gemeinsame Linie zu finden - ich bin auf jeden Fall daran interessiert und würde auch mit vielen Kompromissen meinerseits mich daran beteiligen.
Ich habe nur Probleme damit, dass es ein Modul gibt, das eigenständig um das CMS herum das Rechtesystem mehr oder weniger aushebelt (ja, wenn es Bakery macht kann sein, ich kenne das Modul nicht).
Man muss eben nur bedenken, dass man es hier mit einem weiteren "God-mode" Modul zu tun hat, das prinzipiell alles aushebeln könnte. Und da muss man in technischer Hinsicht schon recht sensibel sein, nicht dass man dann über nicht bekannte Umwege jegliche Berechtigungen umgehen kann - es wäre halt schade.
Aber nur zum Nachvollziehen - ich erstelle eine neue Seite im Seitenbaum und setze diese auf Privat, drei Gruppen dürfen sie sehen und zwei bearbeiten (oder soll das Frontend Edit Modul auch Seiten erstellen dürfen?)
Meine Frage: Wie übernimmt das Frontend Edit Modul diese Werte - direkt aus der Datenbank oder schert es sich nicht drum und ich habe die doppelte Arbeit, weil ich alles noch einmal konfigurieren muss im Modul?
Gruß Michael
-
Wenn ich richtig verstehe, willst Du die Rechte pro Seite vergeben?
Falls ja, dann ist es sinnfrei.
Jede Section sollte die Möglichkeit bekommen, bearbeitbar zu sein oder eben nicht.
Zu Deutsch: man sollte bei jeder Section angeben können, welche Gruppe sie editieren kann.
Der Bereich "Sections" /sections.php
wäre dafür also eigentlich der richtige Ort.
Aber merk mal auf, wieviel Arbeit es wäre, ein solches System zu programmieren und die Module müßten ebenfalls dadrauf abgestimmt werden.
Also bleibt - zumindest im Moment - nichts anderes übrig, als es vom Modul abhängig zu machen.
In den Einstellungen des Modules selbst.
Anders wird es nicht funktionieren.
Und Bakery ist nicht das einzige Modul, welches es hat/tut.
Viele andere Module bedienen sich ähnlichen Verfahrens, um z.B. den Button "Settings" nur der 0-Gruppe (Admins) zu zeigen.
Es geht nur von Modul zu Modul.
Eine andere Herangehensweise könnte sein:
- eine Liste von Modul-Kandidaten, für die man FE Edit haben will aufzustellen
- sich diese Module anzuschauen, welche Bereiche im FE Sinn machen würden und für wen
- zu schauen, ob man einheitliche Verfahren etablieren kann, die sie alle gemeinsam haben (sollten)
- eine übergeordnete Lib/Framework etablieren, welches mit diesen Modulen korrespondiert und die nötigen FE Dateien, samt Scripte etc. mitliefert
(solange das nicht im Core ist, muss eine Lib/Zusatzframework herhalten - anders wird es NICHT gehen)
Man sollte aber zuerst überlegen, welche Module so ein FE Edit haben sollten (mit den erweiterten Einstellungen, Freigabe zum Editieren je nach User und Section).
Was wären die Kandidaten?
Und in wie fern ähneln sich diese Kandidaten und wie könnte man das vereinheitlichen?
Wie oben schon erwähnt - das Guestbook Modul könnte locker mit "Edit-in-Place" arbeiten, somit gibt es auch einige unterschiedliche Herangehensweisen bei den verschiedenen Modulen.
Man plant am besten vom Endprodukt zurück, bis man auf die richtige Technik kommt.
Und die Module selbst, sind hier die Endprodukte.
Module sind unterschiedlich, weisen aber untereinander ähnliche Charakteristika auf.
Es würde möglicherweise 3 Gruppen von Modulen geben:
solche, die mit Edit-In-Place umgehen können,
solche, wo man die modify.php reinlädt und
solche, wo man (wie bei News z.B.) die view_(item).php reinzieht, wo der Inhalt des Items bearbeitet wird. (wobei das nach einer Mischtechnik schreit, sodass sowohl die einzelnen Items/News editierbar sind, als auch die modify.php selbst)
Ganz schön umfangreich und abenteuerlich das ganze.
Aber ohne eine Liste von Kadidaten kommt man nicht dadrauf.
Ein Projekt von " Frontend Editable Modules for WebsiteBaker " könnte der ganzen Problematik auf den Grund gehen.
Mit ein paar Leuten, die Lust haben, dadran zu werkeln.
Wäre aber momentan natürlich ein "am Core vorbei"....
Schlimm?
-
Wir sollten die Kirche im Dorf lassen.
Frontend Edit soll eine Erleichterung sein, kein Ersatz fürs Backend.
Für FE-Edit gilt das gleiche wie fürs Backend. Vom Core her soll das Berechtigungssystem geregelt werden und fertig.
Es ist letztliche nur eine andere Darstellungsform der selben Dateien. Es ist den Modulautoren überlassen, wie sie das im Detail handhaben.
In Topics wird einfach ein Flag gesetzt und dann sind Kleinigkeiten anders. Aber es ist keine Datei doppelt (BE und FE) vorhanden. Wo kämen wir denn da auch hin, wenns eine move_up_fe.php usw geben müsste.
Natürlich verwendet man den selben Editor, da käme man ja in Teufels Küche: Der eine macht <p> bei Return, der andere <br/>, der dritte <div>... ganz zu schweigen vom Umgang mit <embed> usw.
Fürs erste muss man mal die Rahmenbedingungen definieren.
Dann kann nach und nach jeder Modulautor hergehen und (sein) Modul anpassen. Oder jemand anders - auch das geht ;-)
Letztlich macht ja das Modul selbst den Schalter rein, und der ist eben erst da, wenns wohl auch funkioniert. Bei WYSIWYG ist das ein Kinderspiel, bei News etwas mehr arbeit (viele Dateien betroffen). Bei Code wird mans wohl nie machen. Wozu auch.
Mit ein Grund, warum ich für die Bereitstellung von frontend-edit ein eigenes Modul nehmen würde: Das ist viel flexibler. Es kann sogar verschiedene geben. Solange sich alle an die Rahmenbedingungen halten.
Das kann sogar soweit gehen, dass es ein neues Modul geben könnte, mit dem zb Seiteneinstellungen im Frontend geändert werden können. Da braucht man nicht unbedingt die Core-Dateien dazu.
-
Hi Chio,
Für FE-Edit gilt das gleiche wie fürs Backend. Vom Core her soll das Berechtigungssystem geregelt werden und fertig.
Ist natürlich eine Frage dessen, WAS man alles im FE laden will.
Was ich da beschrieben habe, zielt nicht direkt auf FE-Edit ab, sondern auf die momentan mangelnde Rechtevergabe an so wichtigen "Ecken" wie den Settings der Module.
Es ist letztliche nur eine andere Darstellungsform der selben Dateien. Es ist den Modulautoren überlassen, wie sie das im Detail handhaben.
Ja, aber wenn es auch dafür eine gut regulierte Vorlage gäbe, warum nicht.
Was hat das jetzt mit einer Kirche im Dorf zu tun?
Natürlich macht das der Entwickler rein oder auch nicht.
Mit ein Grund, warum ich für die Bereitstellung von frontend-edit ein eigenes Modul nehmen würde: Das ist viel flexibler. Es kann sogar verschiedene geben. Solange sich alle an die Rahmenbedingungen halten.
Klar, ohne Lib wird's nicht gehen.
Nicht so lange nichts fest ins Core kommt.
Das kann sogar soweit gehen, dass es ein neues Modul geben könnte, mit dem zb Seiteneinstellungen im Frontend geändert werden können. Da braucht man nicht unbedingt die Core-Dateien dazu.
Genau deswegen meine ich, dass das besser geregelt werden sollte - nicht jedem, der Inhalte Editieren kann, will ich auch Rechte zum Setzen der Einstellungen geben.
Ich denke einfach einen Schritt weiter (auch wenn ich die Kirche dafür in meinen Garten stellen müßte).
Stefek
-
Klar, Stefek, dass da auch andere Sachen ins Spiel kommen.
Das überlasse ich aber GERNE unseren 2 Megapearls - dem Dev-Konzentrat ;-)
Und da will ich hier auch nicht diskutieren. Für mich ist es _nur_ eine andere Darstellungsweise des Backends. Was die Zukunft bringt, werden wir sehen, wenn sie da ist. "Warten" brauchen wir _nicht_ drauf.
-
Hallo Chio,
ich muss ehrlich sagen, die ganze Idee und was Du vorhast gefällt mir - doch ich kann es zeitlich nicht schaffen, mir im Moment weiter Kopf darüber zu machen.
Ich wünsche Dir jedenfalls viel Erfolg damit.
Sicher wäre so ein "Klub der lebendigen Baker" gut, um Ideen zu sammeln, sich auszutauschen und Prototypen zu entwickeln - denn die MegaPearls werden es vielleicht umsetzen können, aber ohne vorher gut durchdachte Ideen wird es so enden wie das derzeitige Backend.
Zu schade dass WB linear entwickelt wird und man nicht in "Projekt-Branches" zu denken gelernt hat.
Andere machen es - hier ist es nicht der Fall.
Gruß,
Stefek
-
Hallo!
Man kann ja jederzeit sich zusammensetzen. Ideen austauschen Prototypen entwickeln usw. geht doch alles.
Wenn man eine SVN braucht - Github, Sourcefourge o.ä. ist ja immer da, wenn jemand einen (Root-)Server hat kann man auch Redmine / trac sich installieren. Technisch ist alles kein Problem. Und wenn eine andere Umgebung besser ist als das Forum hier - nichts leichter als das.
Projekt-Branches ist ein gutes Stichwort, wäre zu wünschen. Ist halt sehr schwer, nicht alle haben damit gute Erfahrungen gemacht, und ich habe Bedenken, dass jemand bei WB länger als 1-2 Jahre Atem hat etwas aktiv zu machen.
Branches wäre natürlich gut - z.B. könnte man so alle "ungeliebten" Module mal auf eine Liste setzen, rauswerfen und von vorneherein gescheit aufziehen. Weil nichts gegen die beiden Entwickler (sie machen viel und sie machen gut) - nur wenn ich mir die Zeitspanne ansehe, was alle seit WB 2.8.0 passiert ist und was noch alles in WB 2.8.x passieren soll kann man sich ausmalen, dass das mit WB3 nichts mehr wird - alleine schon zeitlich.
Wenn man mehr ins Boot holt - nun, auch damit hat WB schlechte Erfahrung. Aber man kann doch alles abtreten, was man nicht will. Müssen die Entwickler sich drum kümmern, ob das Backend valide ist gut aussieht - nö, dafür gibt's Webdesigner. Und wenn sich jemand bereit erklärt XY zu machen setzt man eine Deadline, und dann sieht man weiter oder macht es halt doch selber - verloren ist dabei aber nichts.
Gruß Michael
-
Hallo!
So, erster Prototyp rennt hier bei mir in der Gegend herum. Er kann noch nicht viel mehr als das Droplet, das in WB 2.8.2 integriert ist. Wird aber als Modul installiert und funktioniert auch unter WB 2.8.0 (die entsprechenden neuen Funktionen aus WB 2.8.2 / SVN werden als wb-Class-Erweiterung mitgeliefert).
Ins Template muss natürlich ein Aufruf Einzug halten - sowas wie <?php frontend_edit(); ?> (kennt man ja schon aus dem alten Modul). Das Aussehen wird über eine frontend.css gesteuert - die Funktionalität des Ganzen kann über ein Admin-Tool angepasst werden. Rudimentärer Screenshot s.u.
Wer mehr will meldet sich hier oder halt sonst wie - wenn jemand meint "Is nix, kann ich besser" - umso besser, bin ja kein Profi.
Gruß Michael
[gelöscht durch Administrator]
-
So eins habe ich auch (als Snippet, ohne Admin-Tool).
Aber interessanter wäre, wenn sich das in jede Section einfügt, auf denen der Eingeloggte User Schreibrechte besitzt (natürlich dann nur für den Edit Button).
Ich arbeite vielleicht nach meinem (kurzen) Urlaub dadran.
Es sei denn Du, oder jemand sonst, hat auch andere Ideen.
Gruß,
Stefek
-
Das mit jeder Section sollte sich nicht als allzu großes Problem darstellen, da es ja im Core (seit WB 2.8.1) "ein wenig" Section-Abhängiges Editieren gibt. Muss man nur wieder auf true setzen durch das Modul und dann sollte es eigentlich gehen. Bleibe ich aber dran.
Interessant wird es dann in Verbindung mit jQuery, dass man denkt, man bleibt im Frontend. Das denke ich wird nicht ganz so einfach, weil man das Backend-Theme manipulieren muss durch jQuery (blende XY aus, nehme dies und jenes und mache einen iframe draus usw.). An WB soll ja trotzdem alles gleichbleiben, und ich finde in allen WBs ab mind. 2.8.0 ohne Probleme laufen.
Das Admin-Tool ist sinnvoll, weil das zugrunde liegende Droplet einen Parameter hat, mit dem man dies und jenes an und ausschalten kann. Und in PHP-Dateien herumfuhrwerken ist pfui. Ist aber alles ein Paket. Interessant eben, weil man später wenn einem etwas einfällt ohne Probleme erweitern kann, und technisch keine großen Hürden mehr dann vor sich hat, weil das Grundgerüst eh schon steht.
Gruß Michael
-
Cool Michi, tob Dich aus.
Bin gespannt, was bei rum kommt.
LG,
Stefek
-
Dann viel Spaß im Kurzurlaub.
Allerdings werde ich mit einem Ergebnis, das ich ohne jetzt riesigen Bedenken zu haben aus den Händen geben kann sicher etwas länger brauchen. Aber ist ja egal - wie gesagt, wenn jemand anderes tun will, oder gemeinsam oder wie auch immer ist ja alles keine Sache.
Edit: Übrigens - an alle die meinen "mit jQuery Admin geht das alles viel besser" - ich werde mich nicht weigern, wenn es keine Installationen betrifft die jQuery Admin nicht installiert haben eine Schnittstelle einzubauen, sofern hier jemand drüberguckt. Einzige Bedingung: Das Programm muss auch ohne jQuery Admin vollständig und fehlerfrei laufen, ich möchte eben nichts zu arg um den Core herum programmieren. Weil gerade hier sieht man mögliche Probleme im Core deutlich (gerade deswegen würde das Programm wie es ist unter keiner WB Installation laufen außer auf der aktuellen SVN, man muss ja modern bleiben, aber zum Glück ist WB ja ein bißchen OOP und man kann die vorhandenen Klassen erweitern ohne Probleme befürchten zu müssen).
Gruß Michael
Anbei mal zwei Screenshots. Im Frontend geht das ganze natürlich schon mit jQuery Pop-Up auf - ich bin gerade dran, das ganze mit AJAX zu gestalten und nur Teile des Backends anzuzeigen - sprich nur WYSIWYG Form von Section X usw. Geht momentan aber wirklich nur mit WYSIWYG, weil die anderen Seiten-Module i.d. Regel "irgendwie" eingebaut sind, aber leider nicht greifbar.
Was dann später mal Schnittstellen betrifft - ja gut, da muss man dann weiter sehen.
Natürlich braucht's jQuery im Frontend, sonst geht nicht viel. Verlassen wird sich auf nichts, was nicht seit WB 2.8.0 fest in WB drinnen ist.
Warum AJAX?
Ganz einfach - iFrame geht auf, man editiert wild drauf los, klickt auf "Speichern" und dann sendet AJAX alles an WB. Gibt's Erfolg wird das Fenster geschlossen. Einfacher geht's nicht (für den Benutzer, für mich schon, kenn mich da ja nicht so wahnsinnig toll aus...), ohne den Core von WB anzutasten.
[gelöscht durch Administrator]
-
Ich denke, Du könntest da problemlos bei der FG abschauen. Die Version 1.0.2 läuft perfekt sowohl mit als auch ohne JQA.
-
Hallo Chio,
einmal übern Teich geschaut:
http://diem-project.org/blog/online-demo-available
Selten elegantes FrontendEdit,
ansonsten habe ich mir das CMS aber nicht sonderlich angeschaut.
Sieht gesund aus.
Gruß,
Stefek
-
Ich bin so frei und poste mal unseren derzeitigen Ansatz. Wir haben zwischen Frontend und Backend ein Backend light geschoben. Das kombinieren wir dann noch mit einem abgespeckten FCK Editor:
Damit kommt so ziemlich jeder Kunde klar, sogar meine 6 jährige Tochter.
Anwendung -> Rechts anmelden, dann im Frontend auf die gewünschte Seite wechseln. Hier das Editiersymbol drücken und gewünschte Seite bearbeiten. Speichern und oben auf den Riesen zurück Knopf drücken. Fertig ist der Spass.
http://demo.pinzweb.at
Vorteile -> Sehr übersichtlich, Alle Module können verwendet werden und für die Streber gibts die Möglichkeit sofort wieder ins Hardcore Backend zu wechseln.
Das ganze ist noch nicht zu 100% ausgereift, weshalb wir es noch nicht der Community zur Verfügung gestellt haben.
lg
Christian
-
Hi, ich war mal so frei...
schon mal was, aber interessanter wäre, wenn jede Section einen Edit-Button erhält.
Außerdem, beim Drücken auf Speichern, kommt doch das ganze BE in Sicht?
Danke für die Testmöglichkeit jedenfalls.
Gruß,
Stefek
-
Ich bin momentan mal dabei, bei diversen Kunden ein "frontend-edit" für einzelne Module einzubauen. An sich immer der gleiche Weg: [Edit]-Schalter im Modul wenn angemeldet und berechtigt -> mit parameter fredit=1 öffnet sich das Backend-File ohne ADMIN-Header, mit eigenem CSS via fancybox in einem iFrame.
der Parameter fredit wird immer durchgereicht, auch beim Speichern usw. Einige Dinge machen so auch keinen SInn - zb "abbrechen" - das wird dann einfach ausgeblendet. Auch "Optionen" sind einfach zu groß für sowas.
Bei Topics 0.6 ist das ebenfalls schon mal eingebaut, allerdings muss man sich den jQuery-Teil noch selber dazu machen.
http://WebsiteBaker.at/topics/frontend-edit-bei-topics.html
In wie weit das Ganze "breitentauglich" ist, bin ich mir noch nicht sicher. Ein Konsens über eine gemeinsame Vorgangsweise scheint nicht möglich, da will jeder sein eigenes Süppchen kochen. Und ich habe schlichtweg zu wenig KnowHow mit JS und jQuery. Und auch keine Lust. Ich bin nicht für alles zuständig.
Blicke übern Tellerrand: jo, da stehen halt ganz andere Konzepte dahinter, da kann man sich nicht allzuviel abschauen. Und meine Begeisterung über exzessives AJAX hält sich in Grenzen, mir reicht GoogleAnalytics schon, mit der ganzen überflüssigen Klickerei.
-
Hallo,
kann sich einer erinnern, ob Michael damals auch Code-Beispiele hochgeladen hat?
Oder nur diese obigen Screenshots?
Oder Michael, falls Du doch noch ab und zu hier mitliest, könntest Du mir eine PM schicken?
Gruß,
Stefek
-
Oh, ich bin ziemlich sicher, daß er mitliest... :roll:
-
-> https://forum.WebsiteBaker.org/index.php/topic,18894.25.html
-
Dankeschön.
Michael, falls Du das mal liest, meld Dich einfach mal per PM bei mir.
LG,
Stefek