brainstorming: dashboard template UI mit jquery + x

[garvinhicking]

Hi!

Hast Du mal frontend_configure und backend_configure als event hooks probiert?

Grüße,
Garvin

[Timbalu]

Hi Garvin
Ja, habe ich! Funktionierte nicht.

Und muss dieser zusätzliche 'genpage' event hook - auch wenn ansonsten leer - trotzdem da sein, damit das überhaupt geparst wird. Denn nur damit klappt meine bisherige Anordnung.

Kannst du mir die Frage mit dem ev. ausloggen beim upgrade beantworten? Sonst muss ich hier mehrere Testreihen mit upgrades aufsetzen..., denn wenn, dann habe ich sowieso Schwierigkeiten...

[garvinhicking]

Hi!

Also soweit ich mich erinnere loggt s9y niemanden aus, wenn man das "Remember login" Checkbox-Ding angekreuzt hat. Es wird höchstens ein neuer Token ausgegeben, wenn der alte verfallen ist - aber dann bleibt mal eingeloggt.

Mich wundert jedoch dass frontend_configure nicht klappen soll. Nach dem hook sollte eigentlich die ganze s9y API zur verfügung stehen für Aktionen...

Grüße,
Garvin

[Timbalu]

Also soweit ich mich erinnere loggt s9y niemanden aus, wenn man das "Remember login" Checkbox-Ding angekreuzt hat. Es wird höchstens ein neuer Token ausgegeben, wenn der alte verfallen ist - aber dann bleibt mal eingeloggt.

Oh Mist! Du meinst 'Save information/Daten speichern' beim login, oder?
Mach ich nie, soweit ich mich erinnere....; vielleicht wurde ich deshalb im installer modus ausgeloggt... Aber geschah das am Anfang oder am Ende des Installations-Prozesses?
Das wäre ungemein wichtig für den upgrade Teil des Wartungsmodus.
Kann man das checkbox Ding irgendwie einfach checken?

Mich wundert jedoch dass frontend_configure nicht klappen soll. Nach dem hook sollte eigentlich die ganze s9y API zur verfügung stehen für Aktionen...

Ja mich auch, deshalb habe ich ja auch so viel herumprobiert....
Es kann aber trotzdem sehr gut sein, dass ich das trotzdem falsch versucht habe....
Bereinigt in etwa so

Code: Select all

$propbag->add('event_hooks',   array(
                           'genpage'                       => true,
                           'frontend_configure'            => true,
                           'backend_configure'             => true,
                           'backend_header'                => true,
                           'external_plugin'               => true,
                           'backend_frontpage_display'     => true
                           )
);

und

Code: Select all

  case 'frontend_configure':
  case 'backend_configure':
       // this will stop serendipity immediately throwing the 503 maintenance message, 
       // if var is set and user is not logged into admin group
       // if using with isset($serendipity[GET][subpage]), which is frontend only, 
       // it would allow to log in! But we want to be strict.

        if ( !serendipity_checkPermission('adminUsers') && serendipity_db_bool($serendipity['maintenance'])) {
            $this->service_mode();
        }
        break;

Die function service mode setzt dann die 503 header, den text und stirbt.

[garvinhicking]

Hi!

Oh Mist! Du meinst 'Save information/Daten speichern' beim login, oder?
Mach ich nie, soweit ich mich erinnere....; vielleicht wurde ich deshalb im installer modus ausgeloggt... Aber geschah das am Anfang oder am Ende des Installations-Prozesses?
Das wäre ungemein wichtig für den upgrade Teil des Wartungsmodus.
Kann man das checkbox Ding irgendwie einfach checken?

Was meinst Du mit "checken"?

Wenn die Box beim Login ausgewählt wird, passiert folgendes: Serendipity erzeugt einen Token mit Ablaufdatum und ordnet dem Token in einer Datenbanktabelle die Gültigkeit serverseitig zu. Der Token wird als authorInformation (oder so) Cookie an den Browser geschickt und dauerhaft gespeichert. Wenn der Browser so einen Cookie sendet, loggt Dich serendipity automatisch ein und gibt Dir einen gültigen PHP-Sessioncookie; wenn der Token expired ist, wird ein neuer erzeugt.

Wenn die Box NICHT ausgewählt wird, kriegst Du NUR einen PHP-Sessioncookie. Sobald Du den Browser schließt, oder das klassische Zeitfenster von 21-Minuten Inaktivität überschreitest, hast Du keinen Login mehr.

Dein Code sieht eigentlich sinnvoll aus, hast Du mal debuggt ob er den Hook ausführt und evtl geschaut an welcher IF-Abfrage das scheitern könnte? Es wäre möglich dass zur frontend_configure Zeit der Login nicht stattgefunden hat, bin mir gerade nicht 100%ig sicher. Aber einfach mal so nen HTTP-Header setzen und schauen ob er in diese Codestelle gehen würde. Der Grund warum das nicht läuft würde mich schon interessieren...

Grüße,
Garvin

[Timbalu]

Was meinst Du mit "checken"?

Ich habe mir das gerade mal kurz angeschaut. Rein theoretisch müsste ja ein

Code: Select all

if(isset($serendipity['COOKIE']['author_information']))

ausreichen, oder?

Wenn die Box NICHT ausgewählt wird, kriegst Du NUR einen PHP-Sessioncookie. Sobald Du den Browser schließt, oder das klassische Zeitfenster von 21-Minuten Inaktivität überschreitest, hast Du keinen Login mehr.

was natürlich doof wäre... und die Möglichkeiten sich damit konsequent auszusperren steigen also...
Es sieht ja fast so aus, als müsste man für den Maintenance Mode ein solches autologin Cookie zwingend setzen, um einigermaßen sicher zu gehen.

hmm ...

Könnte man das vielleicht auch (ev. sogar ungefragt automatisch) nachträglich machen, wenn man den maintenance mode auf true setzt? So a la:

Code: Select all

if(!isset($serendipity['COOKIE']['author_information'])) {
            serendipity_issueAutologin(
                array('username' => $serendipity['user'],
                      'password' => $serendipity['pass']
                )
            );
}

Und wenn man den Wartungsmodus wieder abstellt einfach

Code: Select all

            serendipity_deleteCookie('author_information');
            serendipity_deleteCookie('author_information_iv');

wieder zurücksetzen?

Dein Code sieht eigentlich sinnvoll aus, ...

Donnerwetter!!! Ich habe es jetzt auch genauso hinbekommen... Ich kann nicht mehr sagen was ich vorher eventuell verbaselt hatte. Ich könnte schwören es war alles sehr ähnlich... Allerdings traue ich dem Frieden erst morgen oder so! Der X-debug header war ein heißer Tipp! Danke.

[Timbalu]

Ich wage es kaum zu sagen....

Next day: Alles wieder beim alten.... Kein 503!

Meine debug hook header (nummeriert) werden im zweiten Browser(IE9) als Test-Besucher nicht gesetzt, weder in *_configure, noch in genpage. Das kann doch wohl nicht am Browser liegen....?

1.6.1 und 1.6.2 mit mod_rewrite true und vereinfachtem testcase:

Code: Select all

switch($event) {
    case 'backend_configure':
        header('X-Debug1: backend_configure'); 
        break;

    case 'genpage':
        header('X-Debug2: genpage'); 
        break;

    case 'frontend_configure':
        header('X-Debug3: frontend_configure');
        if (!serendipity_checkPermission('adminUsers') 
            && serendipity_db_bool($serendipity['maintenance'])) {
            $this->service_mode();
        }
        break;

    case 'backend_header': ... etc

FF - eingeloggt und im Backend: - X-D1=backend_configure und X-D3=frontend_configure
FF - eingeloggt und im Frontend - X-D2=genpage und X-D3=frontend_configure
FF - eingeloggt und aus dem Frontend umschalten auf Backend
- /admin - nur X-D3=frontend_configure
- /serendipity_admin.php - X-D1=backend_configure und X-D3=frontend_configure
FF - ausloggen zur login Seite - X-D1=backend_configure und X-D3=frontend_configure

FF - zur Frontpage erster click - keine Dashboard debug hook header - ergo kein 503!
FF - reload (auch mehrfach Strg-F5 - keine Dashboard debug hook header - ergo kein 503!
IE9 - nicht eingeloggt im Frontend - keine Dashboard debug hook header - ergo kein 503!

Sobald eingeloggt als admin user (Zugang gewährt 200) oder test user (kein Zugang 503) klappt alles, da immer frontend_configure durchlaufen wird. Nur nicht im Frontend!

[onli]

Evtl werden die Header vor dem Hook geflushed?

[Timbalu]

Oh man - Ich bin ein Esel!
...und betriebsblind sozusagen. Ich habe mir das aus Sicherheitsgründen schon vor langer Zeit selber eingebrockt, denn natürlich werden so auch keine hooks durchlaufen wenn ich nicht eingeloggt bin...

Code: Select all

if (isset($hooks[$event]) && serendipity_userLoggedIn()) {

[Timbalu]

Hi
(wahrscheinlich @Garvin und alle Javascript Experten)

Die bisherige Version 0.9.8 läuft pretty stable (außer Frage 1) und ist nahezu fertig. Also habe ich mich an die Weiterentwicklung gemacht, für die ich noch ein paar wichtige Fragen zu klären hätte:

1.
Wie genau kann meine Dashboard autologin remember-me function für den Wartungsmodus, einen browser close, wie die Original Funktion beim Login, überstehen? Siehe:

Code: Select all

if($set && !isset($serendipity['COOKIE']['author_information'])) {
    // set a global var to remember automatic autologin
    $serendipity['dashboard']['autologin'] = true;
    serendipity_setCookie('dashboard_autologin', 'true');
    // This for now works until the browser is closed, while in maintenance mode.
    // Then you can log-in back at least w/o being referenced to the maintenance mode 503 page!
    // ToDo: make this same stable as the origin remember-me cookie, which still survives a browser closed
    if( serendipity_authenticate_author($serendipity['user'], $serendipity['pass'], false, true) ) {
        if($_SESSION['serendipityAuthedUser'] === true) {
            serendipity_issueAutologin(
                array('username' => $serendipity['user'],
                          'password' => $serendipity['pass']
                )
            );
            echo 'true'; // console or ajax post answer 
        }
    }
}

[/size]

2.
Kann man mit Serendipity während backend runtime aus dem Dashboard Plugin den path für die backend entries.tpl, manche media_*.tpls und eventuelle Plugin tpls in das Plugin hinein verbiegen? Und wenn ja wie geht das?

Warum?
Ich bin schon relativ weit darin, 'alle' aufzurufenden Backend Seiten aus dem Dashboard per $.ajax in einen Modal Container umzuleiten, wenn man das per config Einstellung so will.
Daher benötige ich für das Dashboard u.a. dort geringfügige Änderungen [(function() { ... });] in js <script> include oder function() Aufrufen, um sicherzustellen, dass sie erst zum document.ready geparst werden. Leider trifft das auch noch auf entryproperties (in customfields), wahrscheinlich staticpages und vielleicht noch anderen Plugins zu, die ein solches Konstrukt benutzen.

Etwas spezieller und verzwickter sind dann noch die Inline-Javascripte die mit document.write() arbeiten. Ich habe es bei den bbc-code document.write Aufrufen nur hinbekommen, wenn ich diese in der default/admin/entries.tpl in plain smarty/html umschreibe.

3.
Warum werden die textarea serendipityPrettyButton input_buttons für bbc-code und media library serendipity_admin_image_selector.php window.open, so a la:

Code: Select all

<script type="text/javascript" language="JavaScript">document.write('<input class="serendipityPrettyButton input_button" type="button" ...

in der admin entries.tpl, sowie im entryproperties plugin und anderen, grundsätzlich mit javascript document.write() hergestellt? Ist das unbedingt nötig? Und wenn ja warum genau?

Es scheint gerade bei den bbc-codes auch ohne dieses js zu klappen.... Anders ist es zB beim Media Upload mit den addField document.write input buttons.
Ich habe bisher also noch keine Lösung gefunden, wie ein 'document.write' in meinen "modal 'dialog'" container so umgebogen werden kann, dass es eine per $.ajax gerufene Seite nicht als document.open() aufruft. [document.write() implicitly calls document.open(), which wipes the entire document]. Es ist ja schließlich kein IFrame....

4.
{if $entry_vars.wysiwyg_advanced} wäre $serendipity['EditorBrowsers'] = '@(IE|Mozilla|Safari)@i';
Was ist mit chrome? Wofür ist das genau? Und was hat das mit dem javascript document.write zu tun ?

5.
Die staticpages benötigen wahrscheinlich ein komplettes rewrite. Das es irgendwie um- bzw weiterleitet, was ich per ajax call so bisher nicht erfassen konnte. Ich hänge aber noch bei den Fragen 2-4, so dass ich dem noch nicht wirklich nachspüren konnte...

[garvinhicking]

Hi!

Also ich glaube zu 1. müsstest Du den backend_auth event hook in deinem Plugin nutzen, dort dann auf den Cookie den Du vorher gesetzt hast aufsetzen um dann einen Login zu ermöglichen... der Cookie wird ja eigentlich nach Browser-Close nicht gelöscht, sondern vermutlich wird der auto-login über authenticate_author() zwar aufgerufen, aber danach sperrt dein plugin den User dann aus?

Die Sache ist leider durchaus kompliziert, evtl kannst Du das nochmal in zusammenfassende Worte fassen was derzeit genau passiert (also den Workflow) - evtl wird durch das Formulieren hiervon auch schon klar, wo man eingreifen müsste...

2.
Kann man mit Serendipity während backend runtime aus dem Dashboard Plugin den path für die backend entries.tpl, manche media_*.tpls und eventuelle Plugin tpls in das Plugin hinein verbiegen? Und wenn ja wie geht das?

Zu welcher Runtime genau? Du kannst im frontend_configure event hook durchaus $serendipity['templatePath'] oder $serendipity['template'] umbiegen... wenn Du also in diesem eventhook prüfst ob gerade eine $.ajax URL aufgerufen/angefragt wird, dann kannst Du für diesen geltenden Request (also die Scriptlaufzeit des ajax-requests) den Pfad grundsätzlich derart umbiegen, denke ich.

3.
Warum werden die textarea serendipityPrettyButton input_buttons für bbc-code und media library serendipity_admin_image_selector.php window.open, so a la:

Code: Select all

<script type="text/javascript" language="JavaScript">document.write('<input class="serendipityPrettyButton input_button" type="button" ...

in der admin entries.tpl, sowie im entryproperties plugin und anderen, grundsätzlich mit javascript document.write() hergestellt? Ist das unbedingt nötig? Und wenn ja warum genau?

Das ist, damit nur bei Browsern mit Javascript diese Buttons ausgegeben werden. Dient also dazu bei deaktiviertem Javascript auch nur die Buttons zu sehen die auch funktionieren...

Ansonsten denke ich könnte man um das document.write auch herumkommen indem man den Code so ändert dass man ein leeres HTML-DIV erstellt und im javascript darauf per "document.getElementById('blabla').innerHTML += 'xxx' zugreift und das so reinschreibt. Ob das allerdings in das modale dialogkonzept reinpasst weiß ich auswendig nicht; ich denke das wird nicht so trivial sein das in beiden Kontexten mit einem Code abzubilden...

4.
{if $entry_vars.wysiwyg_advanced} wäre $serendipity['EditorBrowsers'] = '@(IE|Mozilla|Safari)@i';
Was ist mit chrome? Wofür ist das genau? Und was hat das mit dem javascript document.write zu tun ?

Ich meine Chrome gibt sich doch auch mit "Mozilla" String im User Agent aus und trifft daher zu. Das ist einfach eine Abfrage weil einige Code-Sachen hiervon damals in Opera z.b. nicht ordentlich klappten.

Viele Grüße,
Garvin

[Timbalu]

Ahhh, da habe ich ja wieder was zum Nachdenken...!

Zu 1. Das muss ich natürlich erst einmal ausprobieren, ich hatte aber eher das Gefühl, als wenn serendipity_authenticate_author() und nachfolgend serendipity_issueAutologin() durchaus korrekt funktionieren, den cookie etc auch korrekt setzen, aber das dann noch irgendwie die Abstimmung mit der Datenbank und dem Token fehlt, denn einen Browser close überlebte dieses Konstrukt nicht.

Zu 2. Geht das auch, wenn ich gar nicht über das Dashboard selbst per $.ajax(get, url) gehe, also zb external plugin benutze, sondern direkt nach load Dashboard per Jquery weitere Seiten per $.ajax() nachlade? Die Zusammenstellung dieser Seiten, zb backend entries, würde also vor dem fetch der entries.tpl, auch über den Dashboard frontend_configure event hook laufen und dort den verbogenen template path finden. Verstehe ich das richtig? Wenn es wirklich so einfach wäre... toll! Wahrscheinlich muss ich es erst einmal ausprobieren... Diese beiden Variablen ändern ja aber die globale Einstellung, ich möchte ja eher darauf hinaus, nur bei einem speziellen (zb entries.tpl) ajax Seitenabruf den template path zu verbiegen, so dass ich per ajax irgendein Kommando mitschicke, was die Zusammenstellung auch nur dann verbiegt...

[garvinhicking]

Hi!

Prüf einfach mal mit LiveHTTPHeaders (Firefox) was für einen HTTP-Header der Cookie-Befehl bei Dir genau setzt, und dann welchen HTTP Header der Browser beim Öffnen nach dem Schließen schickt, also ob der Cookie überhaupt durchkommt.

issue_autologin darf nicht mehrfach geschickt werden, die Cookies überschreiben sich sonst, und dann schickt Dir s9y nen neuen logincookie wenn dort da was durcheinander gerät...

Zu 2: Du musst für jeden Request in dem dein plugin den pfad verändern soll innerhalb dfes dashboard plugins solche URLs abfangen um den Pfad zumzuschreiben... "weitere Seiten" kennt der Kern nicht, der weiß ja nichts von solchen Abhängigkeiten. frontend_configure (bzw. backend_configure) wird bei jedem Request auf eine s9y URL neu aufgerufen...

Wenn Du dir alle Variablen ausgeben lässt müsstest Du anhand der Serendipity GET/POST Variablen ja erkennen, welche Seiten man umschreiben müsste...?

[Timbalu]

Ansonsten denke ich könnte man um das document.write auch herumkommen indem man den Code so ändert dass man ein leeres HTML-DIV erstellt und im javascript darauf per "document.getElementById('blabla').innerHTML += 'xxx' zugreift und das so reinschreibt. Ob das allerdings in das modale dialogkonzept reinpasst weiß ich auswendig nicht; ich denke das wird nicht so trivial sein das in beiden Kontexten mit einem Code abzubilden...

Ist es ja auch nicht ...aber es könnte helfen!
Hardcodiert habe ich solches, außer in tpls, bisher im serendipity_event_entryproperties.php und in der category.inc.php gefunden. Wäre das OK für dich, wenn ich solcherlei Fundstellen im Master und folgend generell umschreibe?

[To summarize, an anti-pattern is a bad design that is worthy of documenting. Examples of anti-patterns in JavaScript are the following: ...
The use of document.write where native DOM alternatives such as document.createElement are more appropriate. document.write has been grossly misused over the years and has quite a few disadvantages including that if it's executed after the page has been loaded it can actually overwrite the page we're on, whilst document.createElement does not. ... It also doesn't work with XHTML which is another reason opting for more DOM-friendly methods such as document.createElement is favorable.]

[garvinhicking]

Hi!

Da hätte ich keine Einwände, solange das auch mit createElement funktioniert bin ich voll dafür.

Grüße,
Garvin