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

Alle Section_IDs einer Seite auflisten

<< < (2/9) > >>

Waldschwein:
Hallo!

Jaja, der Anfänger.  :oops: Hat die while Schleife vergessen und nicht richtig geschaut, wo das return innerhalb der Funktion steht... Sorry für die Aufregung, und danke für die Hilfe. Jetzt ist alles im Array, was da reingehört.

Gruß Michael

chio:
Mir ist nicht recht klar, warum das Pferd von dieser Seite her aufzäumst. Was bringt dir das?
Jegliches Frontend-Edit muss vom Modul her kommen, es muss dafür vorbereitet sein. Über das Abfragen der Sections kommst du gerade dahin, dass du ein Modul zwar im Frontend aufrufen kannst, aber spätestens beim Speichern landest du (derzeit) ganz normal im Backend. Von vielen "Besonderheiten" der Module abgesehen.

Waldschwein:

--- Quote from: chio on July 31, 2010, 06:31:34 PM ---Mir ist nicht recht klar, warum das Pferd von dieser Seite her aufzäumst. Was bringt dir das?
Jegliches Frontend-Edit muss vom Modul her kommen, es muss dafür vorbereitet sein. Über das Abfragen der Sections kommst du gerade dahin, dass du ein Modul zwar im Frontend aufrufen kannst, aber spätestens beim Speichern landest du (derzeit) ganz normal im Backend. Von vielen "Besonderheiten" der Module abgesehen.

--- End quote ---
Es gibt eigentlich ein Totschlagargument, und das ist WYSIWYG in Verbindung mit Abwärtskompatibilit ät.
Was bringt Frontend-Edit, wenn es beim meist verwendeten (und bei allen Edits immer bevorzugten) Modul nicht klappt?
Dass das Frontend-Edit vom Modul her kommen muss ist klar, aber zum Beispiel Topics 0.6 hat ja auch ein Frontend-Edit, ohne auf ein externes Modul zurück greifen zu müssen.
Beim Speichern lande ich übrigens nicht im Backend - dafür gibt's ja jQuery - oder sagen wir lieber JavaScript mit dem Modewort AJAX. http://api.jquery.com/category/ajax/

Gruß Michael

chio:
Beim WYSIWYG-Modul wären die nötigen Änderungen in einer halben Stunde gemacht. Es sind ja nur wenige Dateien betroffen. Vorausgesetzt: Es ist klar, WIE man das machen soll. Da habe ich schon Möglichkeiten aufgezeigt, aber ich kenne die WB-Pläne zuwenig, um hier absolut sattelfest zu sein. Sonst hätte ich es eh schon gemacht ;-)

Außerdem würde ich hier sowieso mehr mit Thorns WYSIWYG-History als "Vorzeige-Kandidaten" liebäugeln, weil Core-Modul-Eingriffe normalerweise Jahre dauern.

Die 2. Sache ist der Behälter, in dem das Ganze dann laufen soll. Der ist unabhängig davon, welches Modul darin läuft.
Da ich wenig jQuery-Erfahrung habe, will ich mir das gar nicht anfangen.

Waldschwein:
Hallo!

Das WYSIWYG Modul kann man natürlich schnell verändern, aber das Problem ist dann einfach, dass man zu viel braucht.
Momentan sage ich, das höchste der Gefühle ein "anständiges" Frontend-Edit zu machen ist das Einbinden von jQuery im Frontend (logisch, sonst geht wenig) und einem PHP-Schnippsel - wohl oder übel auch das manuelle Aktivieren von EDIT_ONE_SECTION, das leider über eine Konstante definiert ist und man hier leider auch nichts mit einem Modul machen kann. Sehr schade - aber gut, ist halt so.
Wenn man jetzt Modulabhängig alles gestaltet, wird das Ganze meiner Meinung nach ein Schuss in den Ofen - wem will man erklären "Um Frontend Edit zu nutzen musst du Modul X aktualisieren, und dann noch Modul Y, usw."
Das ändert nichts an der Tatsache, dass es sinnvoll ist, eine Möglichkeit bereitzustellen "Wenn das Modul bereit ist für Frontend Edit, benutze das auch gefälligst" - aber eben auch "Wenn nicht, nimm Krückenlösung XY".

Das Ganze funktioniert momentan schon ein bißchen - siehe Screenshot. Zwar unschön mit iframe (wegen Rumgebastel kommt der Overlay erstmal später dran) und sonst etwas, aber es funktioniert.

Alternativ könnte man jetzt einfach ein anderes WYSIWYG Modul reinpacken, und das einfach anstatt dem integrierten aufrufen (nein, es betrifft keine Formatierungen, weil die abhängig vom Editor sind, aber nicht vom Modul).
An WB selbst möchte ich nichts ändern, weil mir das zu heiß gestrickt ist. Um das ganze wirklich richtig zu machen, müsste man von Anfang bis Ende das ganze Konzept von WB (aus technischer Sicht) umschmeißen und - mit Verlaub - daran glaube ich nicht. Man könnte natürlich sich den "account" als Vorbild nehmen und einfach alles mal eben doppelt für's Frontend programmieren - aber auch das finde ich viel zu heiß.

Nein, ich denke momentan ist folgendes einfach am Besten:

1.) Frontend Edit Modul wird installiert (ein Admin-Tool) - zeitgleich wird automatisch ein Snippet mitinstalliert - der Benutzer / Admin merkt davon aber nichts (außer er sieht in der Modulliste nach).
2.) Ins Frontend Template muss das Snippet registiert werden (einfach ein <?php frontend_edit(); ?>). Zudem muss entweder WB 2.8.1 unverändert vorhanden sein oder (mit WB 2.8.0 oder folgendem WB 2.8.2) die Konstante "EDIT_ONE_SECTION" in der framework/initialize.php auf true sein. (Leider ist das ganze so verstrickt, dass ich heute noch drüber rätsel, was eigentlich das ganze macht - ist schade, aber nun gut. Wäre viel sinnvoller, dass man auch "extern" die Möglichkeit hat, es zu überschreiben). Natürlich muss "irgendwie" jQuery auch im Frontend vorhanden sein.
3.) Im Admin-Tool (tool.php) kann ich ein paar Funktionen an und ausknipsen. Das ganze wird in der Datenbank gespeichert und an die fedit_functions.php übergeben.
4.) Die fedit_functions.php besteht aus ein paar Funktionen. Die eine holt sich die Werte aus der Datenbank, eine andere
stellt jQuery zur Verfügung (ja, eine Krücke, aber erstmal bleibt es so, kann man später evtl. auslagern), eine andere rödelt durch die aktuelle Seite und stellt die ganzen Sections zur Verfügung (mal gucken, wie das alles noch mit Sicherheit aussieht, WB 2.8.2 hat hier auch ein paar interessante Funktionen wie "section_is_active", die schon Einzug halten sollten). Die eigentliche Funktion dann holt sich die Page_ID, und spuckt alles der Reihe nach aus. Die Section_ID wird als Link an die URL drangehängt.
5.) Noch bin ich nicht soweit - aber gibt es eine "frontend_edit.php" (o.ä.) eines Moduls wird die anstatt der Backend-URL aufgerufen.
Gibt's ja wieder ein Problem - wie weiß das Frontend-Edit welche Section welches Modul hat und ob das Modul die frontend_edit.php überhaupt hat? "Einfach so" geht das nicht - auch hier muss es in der Datenbank herumwälzen. Ich wüsste zumindest keine gescheite, andere Sache. Außer halt wie bei Topics, dass der Edit-Button irgendwie abgefangen wird. Aber ohne eine PHP-Schnittstelle (API) geht das alles ja nicht.

Um die Buttons zu stylen gibt's eine frontend.css, zudem sollte später natürlich alles auch in eine frontend.js reingeschrieben werden, damit keiner in den PHP-Dateien herumpfuschen braucht.

Natürlich - Feinheiten und auch einige "Grobheiten" müssen unbedingt noch fertig werden, evtl. muss man sogar im Backend-Theme eine JavaScript Datei einbinden.

Gruß Michael





[gelöscht durch Administrator]

Navigation

[0] Message Index

[#] Next page

[*] Previous page