Alle Section_IDs einer Seite auflisten

[Waldschwein]

Hallo!

Danke dafür. Ich habe dann wohl einen Fehler gemacht. Was ich bezwecken wollte ist eigentlich, dass die Section_IDs nach der Position der SQL-Spalte "position" ordnen. Ich meine, das funktioniert auch - oder habe ich irgendwo doch einen Denkfehler?
Eigentlich habe ich mich hier an die Aufrufe wie sie auch im WB-Core vorhanden sind gehalten, und das wird hier auch nach demselben Schema gehandhabt - und die funktionieren ja eigentlich immer problemlos (z.B. admin/pages/sections.php Zeile 210 ff.).

So, ich schaffe es jetzt, das Fenster aufzurufen und "abzuschießen", ohne dass man irgendwas vom Backend sieht. Dazwischen gibt's noch das klitzekleine Problem, dass keine Daten übertragen werden. Das Problem ist AJAX.
Ja, man könnte iframe nehmen - nur da muss man leider wirklich an WB Core herumfurwerken, und genau das möchte ich vermeiden.

Da stand mal was mit AJAX - isse schwerer als gedacht.

Sicherheitskonzept von WB wird natürlich nicht umgangen dabei - ist ja gar nicht möglich, mit JavaScript PHP zu umgehen.
Und da finde ich das von der aktuellen SVN auch wirklich gut, drum ist es ja auch schon dabei als Klassen-Erweiterung.

Gruß Michael

[Waldschwein]

Hallo!

Ok, jetzt bin ich an dem Punkt angelangt, wo ich schon vor einigen Monaten hinwollte / angedacht habe: Eine externe Schnittstelle muss her für etwas wie AJAX (JSON, REST, ...)
Ich meine, das Modul würde auch so gut funktionieren - muss halt nur noch die Section_ID richtig durchlaufen & ausgegeben werden. Dann gibt's einen Link zum Backend (wenn die Overlay-Funktion abgeschaltet ist im Admin-Tool) und fertig.

Doch mit richtigem Overlay gibt es einfach ein paar Probleme, und über normale Wege kommt man (oder bloß ich?) nicht weiter.
Vor allem:
Wie wird nach korrektem Übermitteln das Fenster abgeschossen? Irgendwo ist da der Haken drin - entweder wird korrekt übermittelt (dann ist man im Backend) oder es wird korrekt geschlossen (dann wird aber nicht übermittelt), aber beides geht (ohne große Verrenkungen) nicht.

Daher muss wohl oder übel das ganze über - bisher komplettes Neuland für WB - GUI-unabhängige Sachen laufen. Also eben AJAX.
"Hole Feld X, Feld Y, Textfeld ABC, sende alles weiter". Irgendwie geht das wohl mit der safe.php vom WYSIWYG Modul schon ein bißchen, doch wie es scheint fehlt einfach etwas.

Aussehen im JavaScript tut's so:

Code: [Select]

$(":input").submit(function() {
            var form_page_id = $('input[name=page_id]').val();
            var form_section_id = $('input[name=section_id]').val();
            var textcontent = $('textarea[name=content'+form_section_id+']');
            var data = textcontent.val();
            var url = "save.php";
// Mit http:, www. oder WB_URL / WB_PATH kommt man nicht weiter - externes geht mit AJAX nicht - Sicherheit!
            $.ajax({
                url: url,  
                type: "POST",
                data: data,
                success: function (reqCode) {                
                // Wenn die safe.php des Moduls einen korrekten (1) Code bekommen hat tue dies, wenn nicht -> Fehlermeldung
                    if (reqCode==1) {
                        alert(url + data + ' _____ klappt');
                        $.nyroModalRemove(); // Damit verschwindet das Fenster
                    } else {
                        alert(url + data + ' ______ klappt ...... nicht ...... ');
                    }                
                }        
            });
            return false; // Damit wird dem Browser gesagt, er soll nichts tun / nicht weitergehen
        });
Hier sollte man sehen, wie in etwa alles abläuft.

Gruß Michael

[chio]

Ich will nicht rechthaberisch wirken...
Dass du zu diesem Punkt kommst, war absehbar. Frontend-Edit muss vom Modul selbst sinnvoll gestaltet sein - unter Benutzung eines bereitgestellten Frameworks.

95% aller Inhalte kommen in typischen WB-Sites aus dem WYSIWYG Modul. Statt dich mit einem biegbaren Besen zwischen den Beinen durch am Kopf zu kratzen, kannst du das auch einfacher haben: Du machst ein paar kleine Änderungen am WYSIWYG-Modul und mit einem 2. Modul stellst du das Framework zur Verfügung.

Und was ist mit weiteren Modulen? Willst du die IDs abfragen, um etwa direkt auf ein Topic zu verlinken? Nur "Topics" selbst kann einen Link zur Verfügung stellen, um etwa direkt einen Kommentar zu bearbeiten. Bakery - das selbe.

Abgesehen davon ist es keine gute Idee, den Admin-Header nur mit display-none auszublenden, weil es trügerisch ist. Jeder Trottel kann ihn einblenden.

[Waldschwein]

Frontend-Edit muss vom Modul selbst sinnvoll gestaltet sein - unter Benutzung eines bereitgestellten Frameworks.

Ja, das muss es natürlich. Im Prinzip muss es so einfach gehen wie auch mit dem momentanen WYSIWYG Modul.
Baue ich einen alternativen Editor, rufe ich nur die PHP-Schnittstelle (ja, eine echte API) des Moduls auf, füttere sie mit ein paar Werten, und schon wird aus FCKEditor ein anderer.

Wenn ich jetzt Änderungen am WYSIWYG Modul mache, habe ich ein Problem - was ist mit thorns WYSIWG history, was ist mit Leuten, die aus Prinzip ihr eigenes / das von der SVN haben?
Ich gehe von mir aus - wenn ein Modul so und so viele Änderungen am Core braucht, nutze ich es nicht. WYSIWYG ist (leider) unbestreitbar teilweise im WB Core integriert.

Dann ist nach wie vor die Frage, wie eine gescheite Verbindung zwischen Topics / Bakery und Frontend-Edit zustande kommt. Ich kann genau genommen nicht einmal jeden Abschnitt einzeln ansteuern - selbst das ist schon eine Krücke mit dem Modul. Eine sinnvolle Verbindung geht aber nur mit PHP. Also muss sich ja ein Modul irgendwie "registrieren" bei Frontend Edit und schreien "Hey ich bin da, nimm mich". Ich habe nur eben mich nie grundsätzlich mit den ganzen Themen beschäftigt, aber werde einmal versuchen, Topics & Bakery zu begutachten, zu vergleichen wie man einen Mittelweg findet, um es dem Modulautoren einfach und dem Anwender ohne eine Aktion zu verlangen ermöglicht.

Dass der Admin-Header ausgeblendet wird ist eher ein Leckerli, als ein "Must-Have". Naja, im Grunde ist es schon ein "Must-Have", weil es einfach inkonsequent wäre, mit einem Pop-Up das ganze Backend einfliegen zu lassen, wo die Hälfte des Fensters erstmal mit Zeug vollsteht, das nicht da sein muss. Wer sich jetzt ein Script baut oder die JS-Dateien ändert kann das ja tun - es umgeht ja nichts an WB, wenn jemand Mediencenter nicht sehen soll, kommt er auch mit "display_block" nicht rein...

Edit: Im Grunde wird (bei mir zumindest) gewinnen, was ich a.) irgendwie realisieren kann und was b.) am einfachsten für den Benutzer und am nachvollziehbarsten für einen Modulautoren ist. Zudem soll es halt nichts von WB untergraben. wenn es jetzt wirklich nicht geht, ohne ein Modul zu verändern - dann ist es eben so.

Gruß Michael

[chio]

Den Header auszublenden ist ein MUST:
Erstens braucht er oft mehr Platz als das aufgerufene Formular (zb Kommentare) und zweitens kommt man damit leicht mal wohin, wo der Spaß aufhört. (Nicht wegen Sicherheits-Aspekten, sondern rein vom Handling her)
Und es sieht einfach "uncool" aus, wenn man da offen das Backend sieht.

Es muss eine "genormte" Schnittstelle geben, das habe ich da schon mal angesprochen:
https://forum.WebsiteBaker.org/index.php/topic,18853.0.html

Und in Topics 0.6 ist das an sich schon mal von Modulseite her eingebaut:
https://forum.WebsiteBaker.org/index.php/topic,18792.0.html
--> inc/headcheck.php, der obere Teil.

Aber: Ich schaff das nicht allein - und habe auch keine Lust, irgendwas zu machen und es mir nachher zerfetzen zu lassen. ("Na mach mal, keiner Trottel..")
So schauts aus.

[Waldschwein]

Ok, ich hab mal ein Video gedreht, was momentan geht:
http://www.youtube.com/watch?v=UyQjuy-Pykc
Also praktisch alles, nur eben das wichtigste nicht - es wird nichts gespeichert. Da bin ich dran.
Aber so von der Idee her finde ich passt es momentan. Natürlich alles noch in Debug-Modus usw.

Achja, Schnittstelle: Möglichkeiten gibt's viele. Letztendlich wird es wohl darauf hinauslaufen, dass man dem Element im Overlay eine ID / Class geben muss (sagen wir "ajax_overlay") und eben abfragen, ob die API-Datei vorhanden ist.
Wird aber wenn ich soweit bin, dass man was erkennt auf jeden Fall eine Dokumentation dazu geben - und bevor es im Detail verfeinert wird, dass man noch Feedback einholt und evtl. das eine oder andere umbaut.

Gruß Michael

[Stefek]

Hi Michael,

Also das Video sieht schon mal ganz gut aus.

Mir persönlich würde sogar die "Einstellung" mit Link ins Backend zu der jeweiligen Section ausreichen.
(Zumindest oft, es würde ja schon enorm helfen sich zu orientieren für manche "Editoren-User".)

Abgesehen davon ist es keine gute Idee, den Admin-Header nur mit display-none auszublenden, weil es trügerisch ist. Jeder Trottel kann ihn einblenden

Das finde ich mal nicht so schlimm.
Der wird ja auch im Backend durch die für ihn gesetzten Rechte eingeschränkt - also wird er ohnehin nicht mehr sehen, als wenn er einfach übers Backend reinginge, stimmts?

Gruß,
Stefek

[Waldschwein]

Hallo!

Jo, das mit den Links ist halt noch etwas "heiß" - erstmal muss ich die richtige Schleife erwischen, dann gibt's ein weiteres Problem, nämlich Buttons auszublenden, wo der Benutzer keine Rechte hat zu editieren, aber trotzdem die richtige Reihe abzufragen (also auslassen, nicht überspringen).
Wenn man wirklich richtig mit Hand und Fuß rangehen möchte führt natürlich ein Weg im Framework etwas zu ändern nicht herum. Doch das will ich nicht machen - schon gar nicht als Voraussetzung, dass ein Modul funktioniert.

Das Backend wird nicht angetastet, ebenso nicht wie das Rechtesystem. In Zukunft wird es eh den anderen Weg rum gehen - mit entsprechender AJAX-Schnittstelle wird nur das Div angezeigt und nicht mehr ausgeblendet. Da müssen allerdings dann wirklich alle Module angepasst werden. Nur hier sollte es wie immer eine "Krückenlösung" geben, dass es mit normalem, unangetastetem WB funktioniert.

Gruß Michael

[Waldschwein]

Ok, kleiner Nachtrag - das mit den richtigen Links ist jetzt erkannt.
Das Problem ist nicht PHP, sondern jQuery. Dem muss man ebenso erklären, durch eine Schleife zu laufen.
Modulberechtigung kann etwas heikel werden, aber natürlich sollte (alleine aus Usability-Gründen) der Editieren-Button ausgeblendet werden, wenn der Editor keine Berechtigung hat, das Modul zu benutzen.
So, momentan stürzt Frontend-Edit ab mit einem Fatal Error, wenn man kein Seitenadmin ist. Wird in der nächsten Alpha-Version behoben sein. (Zudem sollte ich mal vorher lieber gucken, was eine function_exists eigentlich ist  ).

Gruß Michael

[Stefek]

Hallo Michael,

Modulberechtigung kann etwas heikel werden, aber natürlich sollte (alleine aus Usability-Gründen) der Editieren-Button ausgeblendet werden, wenn der Editor keine Berechtigung hat, das Modul zu benutzen.

Vielleicht kann Dir dieser Link und dieses Snippet etwas helfen:
https://forum.WebsiteBaker.org/index.php?topic=18796.0
Schau mal rein.

(Zudem sollte ich mal vorher lieber gucken, was eine function_exists eigentlich ist   )

Das ist eine Funktion, die überprüfen soll, ob eine Funktion existiert.
Man verwendet es, um zu verhindern, Funktionen aufzurufen, die möglicherweise nicht existieren.
Es wird auch verwendet, indem man schaut, ob eine Funktion bereits existiert, BEVOR man sie kreiert - das soll verhindern, dass Funktionen doppelt und dreifach kreiert werden.


Ist so ähnlich wie defined(), nur dass dieses sich auf Konstanten bezieht.

Oder war das jetzt ein Joke? 

Gruß,
Stefek

[Waldschwein]

Oder war das jetzt ein Joke? 

Das war ein Joke, weil ich es falsch übernommen habe, und es sinnlos ist, mit function_exists Funktionen einer Klasse aufrufen, weil das gar keine Funktionen, sondern Methoden sind.
Das Snippet guck ich mir mal an, danke.

Gruß Michael

[Stefek]

Michael goes OOP 
Respekt.


Stefek

[Waldschwein]

Michael goes OOP 
Respekt.

Nö, nicht wirklich - nur fieses OOP-Hacking vom WB-Framework.

Gruß Michael

[Stefek]

Na, dann pass auf, dass Werner Dich nicht aufspürt 

BTW, finde cool, wie Du Dich da reinfummelst.
Nach CKE wird das ein neuer richtig guter Beitrag zum CMS werden. (Wenn auch nur über einen Simplen Link ins Backend, das allein ist schon sehr viel Wert für die Leuts, denen man die Contents anvertraut).

*thumbsup*
Stefek

[Waldschwein]

Im Grunde mache ich nichts anderes, als zwei Methoden, die nur in der aktuellen SVN in der class.wb vorhanden sind bereitzustellen. Also "wenn die Methoden nicht da sind, nimm einfach class.wb282, die die class.wb eben um nicht vorhandenen erweitert". Eben eines der Grundprinzipien von OOP - Mehrfachvererbung. (Nein, das nicht...)

Jetzt eben noch das reinfummeln, dass es nicht aussieht wie im Screenshot, und dann hat man es. Wobei, hier geht es um wirkliches JavaScript, da muss wohl einiges noch umgeflochten werden. Ich weiß zwar nichts über ob_start() ob das überhaupt hier etwas bringt usw., aber ich mache das mal lieber ohne, sonst gibt's bestimmt bloß Konflikte.

Gruß Michael


[gelöscht durch Administrator]

[Waldschwein]

Hallo!

Ich möchte nur sagen, dass mir momentan die Zeit fehlt, das Modul wirklich fertig zu machen - das betrifft leider auch die Section-Links zur jeweiligen Section. Das ganze ist wohl doch größeres JavaScript Geheimnis, ich bin da nicht tief genug drin und hab momentan genug anderes zu tun bei und mit WB.
Der mehr oder weniger letzte Stand der Dinge ist angehängt - war in einem Beitrag mal zuvor.
Ich gehe da von mehreren Wochen aus, die es also noch brauchen könnte - außer natürlich jemand hat bessere Ideen und kann sie einbringen.

Gruß Michael


[gelöscht durch Administrator]