Alle Section_IDs einer Seite auflisten

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

<< < (6/9) > >>

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: ---$(":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
   });
--- End code ---

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:

--- Quote ---Frontend-Edit muss vom Modul selbst sinnvoll gestaltet sein - unter Benutzung eines bereitgestellten Frameworks.
--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version