brainstorming: dashboard template UI mit jquery + x

[Timbalu]

good luck, Garvin!
0.6.9.9 - new path options and some finetuning (see changelog)

[garvinhicking]

Hi!

Hey, great. That works. Funnily, now the path is properly detected. Is there a reason why I not only need to enter the HTTP path but also the full server path? I think the full server path should always be internally...?

Plugin looks pretty neat! I like where this is going. One note; seems you always show spamblock-bayes/ham options for comments, even though I don't have that plugin enabled. Also I only see the constants for it and only "ham" has an icon, the "spam" icon is broken since it leads to non existing /plugins/serendipity_event_spamblock_bayes/img/spamblock_bayes.spam.png.

Good work!

Regards,
Garvin

[Timbalu]

Hey, great. That works. Funnily, now the path is properly detected. Is there a reason why I not only need to enter the HTTP path but also the full server path? I think the full server path should always be internally...?

Gnrr!
That is why I got stuck to really understand your problem, as I thought we had this "nearly" before ...
So please tell me, if this http path is doing well for you:

Code: Select all

$serendipity['serendipityHTTPPath'] . 'plugins/serendipity_event_dashboard'

and this fullpath:

Code: Select all

dirname(__FILE__)

also? Then I could get rid of these options again.

As stuck to work with Smarty2 in S9y < 1.7, I do need the fullpath here for {include file=""}'s in the main template file.

One note; seems you always show spamblock-bayes/ham options for comments, even though I don't have that plugin enabled. Also I only see the constants for it and only "ham" has an icon, the "spam" icon is broken since it leads to non existing /plugins/serendipity_event_spamblock_bayes/img/spamblock_bayes.spam.png.

Yepp sorry, I forgot to adapt if(BAYES_INSTALLED) to if(defined('BAYES_INSTALLED')).
The differing image path isn't a pain if the constant toggles right... Update is available. If we can clear the path and option question, I'll bump the version too.

Plugin looks pretty neat! I like where this is going. Good work!

Thank you. I still think there is along way until it features to be more than this, as stuck to the old backend - for now its not much more then a playground, a cap onto the old, without to much need. I am sure, when we roll out the smartified backend, there will be much more possibilities.
I still try to get some more of this into the current state, but this is not easy with the old backend under the hood.

[garvinhicking]

Hi!

Code: Select all

$serendipity['serendipityHTTPPath'] . 'plugins/serendipity_event_dashboard'

This only works for this specific plugin, now I understand why it works. But I still need the variable, if in the future I link it from additional_plugins once you have it there.

However the "full path" is not needed, the dirname(__FILE__) thing should work fine.

Regards,
Garvin

[Timbalu]

I see, thank you. So I am gonna keep http path option for these rare cases.
x.1 version is out.

[Timbalu]

Hee hee, all my willing testers...!

I have commited 0.7.1 now, as made various changes - all heading to be a sparkling new dashboard.
This development is still not finished and I have lots of ideas until this is usable for the public.
Please see the GIT notes, the changeLog and the help screen Gazette.

I'll be back in a week and wait for comments and contributions!

Ciao
Ian

[Timbalu]

0.7.2
Added strict to function check_plugin_status() for E_STRICT environment
0.7.3
fixed bayes rating

[Timbalu]

I just released v.0.9.2 - still a proof of concept - but please help testing!

What happened? New blocks, UI-customizable, various updates to nearly everything. I recommend to start from scratch, if updating a previous version, as I did erase and rename many files.

Zip your new Dashboard here: https://github.com/ophian/serendipity_event_dashboard

Have fun!

[garvinhicking]

Hi!

Maybe to spread usage, you might want to create a new topic and show the dashboard plugin with some screenshots? I'm sure if people can easily see it first, they would much rather use/test it?

Best regards,
Garvin

[Timbalu]

Ich kann bei der Hitze nicht denken...

Hättet ihr eine Idee, wie man einen Upgrade-Wartungsmodus (also 503 mit eigener Ausgabe) für das Frontend so setzen kann, dass eine Backend-Dashboard Funktion per JSON set true/false einen 503 header und den Ausgabetext setzt, der solange für das Frontend und nicht eingeloggte User Bestand hat, wie man dies per Zuruf set false im Dashboard Backend wieder zurücksetzt. Die JSON Methode funktioniert schon gut über external_plugin
Und die Funktion soll in etwa so etwas setzen....

Code: Select all

        if ( !$is_logged_in && $mode ) {
            $retry = 120; // seconds
            $protocol = $_SERVER["SERVER_PROTOCOL"];
            if ( 'HTTP/1.1' != $protocol && 'HTTP/1.0' != $protocol )
                $protocol = 'HTTP/1.0';
            header( "$protocol 503 Service Unavailable", true, 503 );
            header( 'Status: 503 Service Unavailable', true, 503 );
            #header( 'Content-Type: text/html; charset=utf-8' );
            header( "Retry-After: $retry" );
            serendipity_die(nl2br($this->get_config('maintenancenote')));
            exit;
        }

Möglich das man eventuell auch (zusätzlich) noch ein

Code: Select all

Options -Indexes

in der htaccess benötigt...

Allerdings fehlt mir irgendwie noch der Schritt, wie ich dies überhaupt und permant für das Frontend wirksam werden lasse und das für alle User außer mir selbst.
Ich habe schon versucht das in die serendipity_config_local.inc zu schreiben, allerdings fehlen mir da noch wichtige Variablen wie loggedIn().... außerdem muss ja über den ganzen auto-upgrade Prozeß der Zugang für den Admin erhalten bleiben... (mir war immer so als würde man ausgeloggt, während des upgrades...)

Bin ich damit überhaupt auf dem richtigen Weg?

[onli]

Wtf? JSON?

Du bräuchtest einen Hook, der bei jeder Seitenerstellung genutzt wird, oder nur im Frontend. genpage für ersteres frontent_view(_*) für letzteres. Dann kannst du doch in dem Hook problemlos abfragen, ob du du bist, und ansonsten den 503 setzen, der Code sieht dazu passend aus. Allerdings hast du recht damit, dass du dann bei der ersteren Lösung eingeloggt bleiben müsstest, aber das kannst du ja testen. Ich kann mich zumindest an ein automatisches Logout nicht erinnern.

Nach Ablauf der Aktion kannst du dann die Variable zurücksetzen.

Ich kann mir nicht ansatzweise vorstellen, wofür du das brauchen könntest.

[Timbalu]

Wtf? JSON?

JSON (JavaScript Object Notation) is a lightweight data-interchange format.

Du bräuchtest einen Hook, der bei jeder Seitenerstellung genutzt wird, oder nur im Frontend. genpage für ersteres frontent_view(_*) für letzteres.

Wie meinen?
Das hatte ich auch so gedacht und es schon kurz mal mit frontend_display versucht. Allerdings klappte das irgendwie nicht... (lag wahrscheinlich dann am kurz...) -außerdem auch nicht nachhaltig, also über irgendwelche reloads hinaus. Aber 'genpage' könnte vielleicht was werden... allerdings gibts auch hier das Problem der Nachhaltigkeit, denn ich müsste ja eine Serendipity['stop'] Variable setzen, die irgendwie erhalten bleibt (villeicht über die local...?)...

Ich kann mir nicht ansatzweise vorstellen, wofür du das brauchen könntest.

Ich nicht, aber es gab schon mehrfach den Wunsch hier im Forum einen Wartungsmodus auf Knopfdruck setzen zu können, besonders für das Serendipity update. Und da ich dort sowieso rumfummelte, dachte ich diesen Wunsch im P.o.C. zu berücksichtigen.

[Timbalu]

Zur Erklärung:
JSON setzt maintenance auf true bzw false und schreibt dies via external_plugin als globale Serendipity Variable in die config_local. Im case 'genpage': wird dann der 503 header und die Ausgabe gesetzt und alles beendet.
Solange man im Backend bzw eingeloggt ist, lässt sich damit prima herumspielen und es klappt auch vorzüglich. Dummerweise wird aber im ausgeloggten Zustand kein dashboard hook 'genpage' abgerufen. (Jedenfalls hat sich mir nicht erschlossen, wie dies gehen kann.... falls sich da erhellendes finden ließe, bitte her damit!)
Insofern setzt die index.php den header 200 OK und alles läuft durch wie sonst auch, was natürlich nicht in meinem Sinne war.

Aber:
Ich habe es jetzt ohne einen hook gelöst, indem ich den Wartungsmodus einfach in eine service function gestellt habe, die geradewegs vor dem hook event (switch) aufgerufen wird.

Code: Select all

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

        if (isset($hooks[$event]) && serendipity_userLoggedIn()) {
            switch($event) {
                case 'backend_configure': ....
                case 'backend_header': ....
                case 'external_plugin': ....
                case 'backend_frontpage_display': ....

Habe ich mir dadurch eventuell irgendetwas eingebrockt, was diese Lösung nicht zuließe?

Und die Frage ob ein Admin beim Upgrade automatisch ausgeloggt wird, ist auch noch ungelöst.
Wer weiß es?

Edit: Äußerst komisch ist es indes, dass der genpage hook trotzdem aktiviert sein muss, auch wenn dort gar keine Ausgabe o.ä. (mehr) passiert...
Also ehrlich... manchmal ist mir Serendipity einfach ein wenig zu magisch...

[onli]

Hi
Zeig doch mal den Code :)

JSON ist ein Format. Das setzt gar nichts, der Teil deiner Erklärung kann unmöglich stimmen.

Es könnte sein, dass genpage tatsächlich im backend nicht aufgerufen wird.

Indem du die Logik nun vor die Eventauswahl gesetzt hast, dürfte das bei wirklich jedem Event ausgeführt werden. Das passt zwar irgendwie zu dem, was du machen willst, frontend_display wäre dafür aber wesentlich performanter und hätte wohl weniger potentielle Probleme mit dem Logout.

Wenn eine solche Funktion wirklich gewünscht wird, könnte sie imho im Core besser passen, wenn wir einen validen Usecase finden.

[Timbalu]

Hi Malte
Wenn du das gerne selber testen willst musst du auf die 0.9.5 warten.

JSON ist ein Format.

Stimmt natürlich! Sollte auch eher POST heißen, damit es verstanden wird. Json war nur eher mein internes Synonym dafür und hat sich hier ausversehen hereingemogelt, tztztz...

Es könnte sein, dass genpage tatsächlich im backend nicht aufgerufen wird.

Indem du die Logik nun vor die Eventauswahl gesetzt hast, dürfte das bei wirklich jedem Event ausgeführt werden. Das passt zwar irgendwie zu dem, was du machen willst, frontend_display wäre dafür aber wesentlich performanter und hätte wohl weniger potentielle Probleme mit dem Logout.

Sach ich doch! Allerdings nur bedingt (siehe letzter Satz).
Ich habe das natürlich auch alles getestet. Die Sperre muss ja auch multiplen reloads widerstehen.

Ja, 'frontend_display' wäre sicherlich schön, klappt aber mit diesen Voraussetzungen ebenfalls nicht.

Nach all den Test war mein Fazit: "Die einzig gangbare Lösung ist die oben erwähnte!"
Ich hätte eigentlich nur gerne gewußt, Warum genau?!

Sehr wahrscheinlich darf ich mit den erwähnten hooks eben auch nur bestimmte Dinge machen und das passt nicht mit der header stop Geschichte zusammen, die vorher greifen muss.