staticpage pageorder

[Timbalu]

Ich arbeite gerade an einer Umarbeitung gewisser Partien im Staticpage Plugin.
Etwas was mich schon immer gestört hatte, war das move down / move up im 'pageorder' case.
Ich habe das jetzt als draggable sequence verarbeitet.

Dabei frage ich mich die ganze Zeit, wozu genau das eigentlich existiert und welche Merkwürdigkeiten und finetuning Einstellungen es eigentlich beinhaltet, da der code etwas sehr fragil und kompliziert gestrickt ist.

Normalerweise lässt man das untouched (, ich jedenfalls). Dann ist im DB table pageorder überall mit 0 eingetragen. Ich lasse meinen drag&drop event jetzt einfach die Anordnungliste neu in die DB eintragen. Beispielsweise a la:

Code: Select all

Array
(
    [0] => UPDATE s9y_staticpages SET pageorder='0'  WHERE id='1'
    [1] => UPDATE s9y_staticpages SET pageorder='1'  WHERE id='3'
    [2] => UPDATE s9y_staticpages SET pageorder='2'  WHERE id='2'
    [3] => UPDATE s9y_staticpages SET pageorder='3'  WHERE id='5'
    [4] => UPDATE s9y_staticpages SET pageorder='4'  WHERE id='4'
    [5] => UPDATE s9y_staticpages SET pageorder='5'  WHERE id='6'
    [6] => UPDATE s9y_staticpages SET pageorder='6'  WHERE id='7'
)

Spricht irgend etwas in Nutzung von Pageorder dagegen, das so relativ simpel vorzunehmen?

[garvinhicking]

Hey,

hm. Also rein theoretisch spricht da nix gegen, denke ich. Ich bin gespannt auf die Praxis

Grüße,
Garvin

[Timbalu]

Wenn jemand das weiter smartifizierte Staticpages gerne mal probefahren will, bitte melden.
Ich könnte ggf Rückmeldungen gebrauchen, ob es auch die weniger angewandten Nutzungsmöglichkeiten korrekt abdeckt. (Garvin?) Und ob ein paar benutzte CSS Eigenschaften weitgehend überall funktionieren.

Ansonsten committe ich das demnächst.

Eine der Fragen die sich mir dabei ergeben haben ist, warum wir eigentlich eine non-smarty markup hardcoded Version darin pflegen, die das ganze sehr unübersichtlich macht. Wer nutzt das eigentlich, dass sich dieser Aufwand wirklich lohnt?

[Czorneboh]

Hallo!

Die page order - Funktion nutze ich schon. Es gibt teilweise bis 3 Ebenen bei den statischen Seiten. Je nachdem, wie man die hier einstellt, erscheint die Übersicht auch im Frontend.

Ich fände es sehr gut, wenn sich die Seitenreihenfolge einfacher regeln ließe und habe mich über den Eintrag hierzu gefreut, Ian.

Es ist irgendwie zufällig, wie weit eine Seite absteigt oder aufsteigt, wenn man auf den Pfeil nach unten oder den nach oben klickt. Ich wunderte mich schon mehrmals.

Ich weiß ja nicht, wie das bei WP oder anderen Blogsystemen gelöst ist, aber vermute, hier ließe sich Boden gut machen beim Vergleich der Bedienerfreundlichkeit. Für S9y als CMS halte ich das schon auch für wichtig.

Und Verbesserungen "solcher Art" (neben Deiner ARbeit am CKEditor als neuer STandard-Editor) sollten in einem Artikel für Zeitschriften wie Chip oder vielleicht mal ct anlässlich des Erscheinens von Version 2.0 erwähnt werden.

Schönen Sonntag noch
Czorneboh

[Timbalu]

Das (tatsächlich vorhandene) pageorder Problem habe ich dabei nur am Rande gelöst; das war nicht der Ausgangspunkt der Bemühungen. Eigentlich wollte ich nur mal schnell einen Bug aus dem letzten listentries commit fixen.
Es wäre wahrscheinlich sogar ganz gut, wenn du als magazin user das auch mal testen könntest. Bereit?

[Czorneboh]

Ok, bereit zum Risiko, trotz "never change a running system".

[garvinhicking]

Hi!

Ich schau mir das auch gerne mal an, schick gerne mal den Link dazu rum (am besten so dass die Dateien wget'en kann).

Die Non-Smarty-Version war damals glaub ich nur drin, als die neue version noch nicht 100% zuverlässig hätte laufen können, daher wollte ich noch ein "fallback" drin haben. Inzwischen denke ich auch das wir das rausschmeißen könnten, die Smarty-Version kann ja soweit ich das beurteilen kann alles, was die Non-Smarty-Version auch kann (und mehr).

Grüße,
Garvin

[Timbalu]

Ich habe inwischen weitergearbeitet...

und doch noch eine kleine Frage zu den Smarty Variablen {$staticpage_lastchange} und {$staticpage_created_on} build by

Code: Select all

                $pagevar . 'created_on'         => $this->get_static('timestamp'),
                $pagevar . 'lastchange'         => $this->get_static('last_modified'),

In den templates wird nur lastchange als Datum für den Staticpage Footer benutzt und created_on taucht in den template Dateien gar nicht auf. In meinen Testszenarien habe ich mich gerade gewundert, dass meine alten Staticpage Entries bei Änderung plötzlich neue Daten trugen. Eigentlich wollte ich das alte Erstell-Datum aber gerne behalten, vor allem, da dies auch bei den Blog Entries so gehandhabt wird und ich das Verhalten dann konsistent fände.

Nun kann ich ich das für mich persönlich ja leicht durch eine Änderung der template plugin_staticpage.tpl bewirken, frage mich aber doch, ob wir das nicht optional anbieten sollten.

Dummerweise müsste man (im Gegensatz zu Blog Entries) die jetzige Einstellung mit der Ausgabe von last_modified als Default nehmen, könnte aber für alle benutzen Templates diese neue Option so einbauen,

Code: Select all

                $pagevar . 'lastchange'         => $this->get_config('show_modified_date') ? $this->get_static('last_modified') : $this->get_static('timestamp'),

dass keine weiteren Änderungen irgendwo anders nötig wären.

Einwände, Meinungen?

[garvinhicking]

Hi!

Hm, ich finde defaultmäßig ist es interessanter wann die Seite bearbeitet wurde, nicht wann sie erstellt wurde... eine Option aber zu haben das so zu "überschreiben" klingt gut. "create_on" als Variable sollten wir aber beibehalten, weil ja Leute ggf. diese Variable in ihren templates ansprechen.

VG,
Garvin

[Timbalu]

Im staticpage backend form wird das Datum eines erstellten Eintrags übrigens als create Datum angezeigt und nicht mit last_modified überschrieben.
Das die "create_on" als Smarty-Variable weiterhin erhalten bleibt, habe ich mit dem Vorschlag vorausgesetzt.

[Timbalu]

See follow-up "Dev Beta Announcement": http://board.s9y.org/viewtopic.php?f=10 ... #p10439277