Frontend-Edit Überlegungen

[chio]

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.

[escpro]

Mir und ein_paar_anderen reichts  
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.

[Waldschwein]

Mir und ein_paar_anderen reichts  

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

[Stefek]

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

[Waldschwein]

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

[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

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

[Waldschwein]

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

[Stefek]

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?

[chio]

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.

[Stefek]

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

[chio]

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.

[Stefek]

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

[Waldschwein]

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

[Waldschwein]

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]

[Stefek]

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

[Waldschwein]

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

[Stefek]

Cool Michi, tob Dich aus.
Bin gespannt, was bei rum kommt.

LG,
Stefek

[Waldschwein]

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]

[BlackBird]

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.

[Stefek]

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

[Dex_Solo]

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

[Stefek]

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

[chio]

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.

[Stefek]

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

[BlackBird]

Oh, ich bin ziemlich sicher, daß er mitliest...