Beta 2.0 - Statische Seiten

[Timbalu]

Sehr skurril: Mittlerweile (ich habe das Plugin seit der Installation nicht modifiziert oder aktualisiert) sind die überschüssigen zwei Einträge verschwunden, „Staticpage with related category“ taucht nur noch einmal auf. Das Einzige, was ich zwischenzeitlich gemacht habe: Seiten angelegt.

Skurril ist, dass meine posts nicht immer wirklich gelesen werden

Das mit den 3x related cats habe ich gesehen. Komisch. Ich habe die zwei gelöscht, ist ja nicht so schlimm, da als File nur virtuell und ein DB Eintrag.

[yellowled]

Skurril ist, dass meine posts nicht immer wirklich gelesen werden

Gelesen schon, aber nicht (richtig) verstanden. Ich dachte, Du hättest in Deinem Repository des Plugins etwas gelöscht, zumal Du auf Dateien und DB im devblog keinen Zugriff hast. Sorry.

Test-Wasserstand: Ich habe eine Menge statische Seiten angelegt und bis auf ein paar Dinge – denke ich – so ziemlich alles getestet, der Rest folgt wohl heute später am Nachmittag. Bisher 2 Dinge, die ich als Fehler einstufen würde, ein paar (finde ich) Nützlichkeiten, die ich mir noch wünschen würde (aber z.T. nicht weiß, ob sie machbar sind) und einige Details, die ich am Backend-Bereich ändern würde.

Ich denke, es macht Sinn, das weiter auf Deutsch zu diskutieren. Ich werde dann heute abend oder morgen einen separaten Thread dazu aufmachen, damit das hier einigermaßen überschaubar bleibt.

YL

[Timbalu]

Ein paar weitere Fragen:

Ich arbeite an den (drei) verschiedenen Navigationen der Statischen Seiten und habe u.a. das von Don geschilderte unvollständige Parent-Child-Anzeige-Verhalten der breadcrumb Navigation gelöst. http://board.s9y.org/viewtopic.php?f=4&t=18951

Ich würde alle drei gerne erhalten, aber mit klar definierten Aufgaben.

Nun zu der entrypaging Navigation:
Die function fetchPublishedStaticPages() bzw der cache liefert das array für die staticpage_navigation (prev - top/blog/current - next). Darin sind alle statischen Seiten enthalten.

Das ist ein Problem, verglichen mit anderen Anzeigen. Das Seitenleisten Plugin unterscheidet nach lang Einstellungen und holt sich nur diejenigen, die lang = current lang, lang='' und lang = all sind. Das macht das staticpage entrypaging ($staticpage_navigation) prev/next nicht. Dito für die Anzeige der "404" Seite(n), für die das allein durch ihre Aufgabe schon gar keinen Sinn macht und auch deshalb nicht, weil sie meist ohne irgendwelche Navigationsanzeigen eingestellt wird. Sogar für die Overview und Related Category Seiten müsste man genau überlegen, ob man sie darin eigentlich haben will, unabhängig von ihrer Konfiguration bezüglich einer Navigation. (Etwaige fetch Änderungen (*) hätten wahrscheinlich auch wieder Auswirkungen auf die (später aus dem array zusammengebastelte) breadcrumb Anzeige, wenn sich darin relevante Modalitäten verstecken.)

Ist das nun nur nicht bedacht worden, oder ist das vielleicht sogar gewollt (warum?), oder einer der Wildwüchse einer historisch gewachsenen Bedürfnisanpassung? Wie soll ich das für künftige Versionen nun einstellen, damit wir ein konsistentes und verlässliches und vor allem durchschaubares Verhalten anbieten?

Ebenso würde ich gerne wissen, ob die $staticpage_childpages bzw erweiterte $staticpage_extchildpages Anzeige für die singulare (level 1) parent/childs Verlinkung, mit der Lösung der entrypaging und breadcrumb Navigation als einzige event Navigationen, rein auf die Ausgabe der Overview aboutpage.tpl beschränkt werden kann. Damit entfiele die Notwendigkeit komplexerer Ausnahmen auf anderen Seiten. (Btw. Bulletproof und das Pluginfallback nutzen extchildpages mit content Vorschau, 2k11 nur childpages als reiner linkdumper. [@YL, Absicht?])

Alles in allem eine hochkomplexe Angelegenheit wirklich alle strukturellen Möglichkeiten gegeneinander abzuwägen.

(*) Ein

Code: Select all

SELECT id, pagetitle, parent_id, permalink FROM serendipity_staticpages WHERE publishstatus = 1 AND articletype != 0 AND (shownavi = 1 OR show_breadcrumb = 1) AND (language = 'de' OR language = '' OR language = 'all') ORDER BY parent_id, pageorder

hilft schon, müsste aber durch ein etwas kniffliges Subselect ergänzt werden, dass alle child pages, deren höchster parent (level 0) sich nicht im eigentlichen select befindet, wieder herausrechnet. Daran hapert es noch, wenn dieser Weg (siehe Fragen) überhaupt so gegangen werden kann. Beispiel: Overview Seite ohne Navigationen, nicht im array, deren childpages aber, aus welchen internen Gründen auch immer, shownavi oder breadcrumb zugelassen haben.

[garvinhicking]

Hi!

Ist das nun nur nicht bedacht worden, oder ist das vielleicht sogar gewollt (warum?), oder einer der Wildwüchse einer historisch gewachsenen Bedürfnisanpassung? Wie soll ich das für künftige Versionen nun einstellen, damit wir ein konsistentes und verlässliches und vor allem durchschaubares Verhalten anbieten?

Ich würde sagen, es wurde einfach nicht bedacht. Irgendwann kamen Sprachen dazu, und es hat dann nicht in allen Bereichen Implementation gefunden. Ich bin sehr dafür, das konsistenz zu halten, also zu ändern.

(*) Ein

Code: Select all

SELECT id, pagetitle, parent_id, permalink FROM serendipity_staticpages WHERE publishstatus = 1 AND articletype != 0 AND (shownavi = 1 OR show_breadcrumb = 1) AND (language = 'de' OR language = '' OR language = 'all') ORDER BY parent_id, pageorder

hilft schon, müsste aber durch ein etwas kniffliges Subselect ergänzt werden, dass alle child pages, deren höchster parent (level 0) sich nicht im eigentlichen select befindet, wieder herausrechnet. Daran hapert es noch, wenn dieser Weg (siehe Fragen) überhaupt so gegangen werden kann. Beispiel: Overview Seite ohne Navigationen, nicht im array, deren childpages aber, aus welchen internen Gründen auch immer, shownavi oder breadcrumb zugelassen haben.

Statt eines Sub-Selects sollte man probieren hier einfach JOINs auf dieselbe Tabelle zu machen, um dann im WHERE-Teil z.b. abzufangen welche Datensätze nur ausgegeben werden sollen, also sowas wie

Code: Select all

SELECT p.id, p.pagetitle, p.parent_id, p.permalink
  FROM serendipity_staticpages AS p2
LEFT OUTER JOIN serendipity_staticpages AS p2
                      ON p2.id = p2.parent_id
WHERE p.publishstatus = 1 
AND p.articletype != 0 
AND (p.shownavi = 1 OR p.show_breadcrumb = 1) 
AND (p.language = 'de' OR p.language = '' OR p.language = 'all') 
AND (p2.shownavi = 1)
ORDER BY p.parent_id, p.pageorder

Das tut was anderes, geht mir eher ums Prinzip. Wie genau die Bedingung sein soll habe ich nicht ganz verstanden...

LG,
Garvin

[Timbalu]

Das tut was anderes, geht mir eher ums Prinzip. Wie genau die Bedingung sein soll habe ich nicht ganz verstanden...

Hi Garvin
Das ist auch etwas schwierig zu beschreiben.

Das normale bisherige select

Code: Select all

"SELECT id, pagetitle, parent_id, permalink FROM {$serendipity['dbPrefix']}staticpages WHERE publishstatus = 1 ORDER BY parent_id, pageorder"

liefert natürlich alles.
Daraus berechnet sich die "entrypaging" next/prev "shownavi" Navigation, wie auch die breadcrumb Navigation und das einfache "hat child" array. Die breadcrumb Navigation hatte die von Don geschilderte Einschränkung. Ich habe nun in dieser späteren Berechnung, die breadcrumb Navigation so gelöst, dass sie auch downwards alles korrekt bis zum letzten child anzeigt, nicht nur vom letzten child aufwärts. (zB blog - parent - child - subchild - grandchild).

Soweit so gut. Aber:
Problem 1: das array entspricht nicht dem sidebar array, dass nach weiteren Kriterien auswählt.
Problem 2: füge ich nun u.a. diese Kriterien hinzu,

Code: Select all

SELECT id, pagetitle, parent_id, permalink FROM serendipity_staticpages WHERE publishstatus = 1 AND articletype != 0 AND is_404_page = 0 AND (shownavi = 1 OR show_breadcrumb = 1) AND (language = 'de' OR language = '' OR language = 'all') ORDER BY parent_id, pageorder

ist eigentlich alles in Ordnung.

Allerdings habe ich hier nun zwei Besonderheiten zum testen.

• Es sollen natürlich nur echte statischen Seiten sein (also zB kein Kontaktformular, Gästebuch, 404, etc.), deshalb das articletype != 0 AND is_404_page = 0.
• Ich habe eine Overview Seite. Sie ist, da sie kein shownavi oder breadcrumb enthält, laut query schon nicht mehr im Array enthalten. Einige ihrer Kinder sind es aber, da sie zur besseren Orientierung breadcrumb 1 haben; ein denkbares Szenario, meine ich.

Erst hatte ich gedacht, ich könnte jetzt diese Kinder per SQL irgendwie wieder herausrechnen, aber inzwischen glaube ich, dass das ein Denkfehler ist. Eher müsste man wohl den Stammvater, also die Overview Seite wieder hereinnehmen und sie, wie ihre Kinder und Kindeskinder mit einem flag auszeichnen, mit dem ich sie später in der "shownavi" Anzeige umgehen kann. Und das natürlich nur wenn es dafür auch Kinder mit diesen Bedingungen gibt. (Das main array dient der Berechnung der korrekten breadcrumb Folge und sollte zur korrekten Berechnung alle Instanzen einer parent/child Beziehung aufzeigen.)

Kannst du mir noch folgen?

Wie kann man nun das Select so erweitern, dass es, im Falle dieser Overview Kinder den Stammvater wieder einsetzt und jede einzelne als 'special' flagt?

Über die Gültigkeit eines solchen Szenarios müsste man sprechen, alllerdings wäre es natürlich schön, wenn es möglich wäre. Related Category mit Ähnlichem habe ich erst mal persönlich ausgeschlossen.

Was ist mit der zweiten Frage bezüglich Beschränkung des einfachen Child links auf die aboutpage?

(Bezüglich der Beta 3 brächte dies eventuell auch noch ein paar core template Änderungen. Aber ob die Beta darauf Rücksicht nehmen soll ist eine andere Frage. Hm... immerhin nicht ganz unwichtig.)

[garvinhicking]

Hi!

Puh, ich glaube ich kann da meinen Kopf nicht ganz drum wickeln. Kannst Du das etwas konkreter beschreiben anhand von Beispielen? Sowas wie:

Es gibt die Seite A, B, C und D. C und D sind Kindseiten von Seite B, das ist eine Overviewpage. Das Array sollte nun die Werte A, C und D enthalten.

So in der Art. Das obige ist falsch, denke ich. Aber ich bräuchte so eine Beschreibung, besser sogar noch direkt einen SQL-Dump mit solchen Beispielseiten, und dann genau die Info, welche Datensätze man genau erhalten möchte.

Was ist mit der zweiten Frage bezüglich Beschränkung des einfachen Child links auf die aboutpage?

Habe ich nicht verstanden leider.

LG,
Garvin

[Timbalu]

Code: Select all

ID	NAME	PARENT_ID		ARTICLETYPE 	NAVIS (navi + breadcrumb)
1      A 			0				1						1		1
2		B 			0				1						1		1

3		C 			0				2 (overview)		0		0
4		D 			3				1						0		0
5		E 			3				1						0/1		1
6		F 			5				1						0/1		1
7		G 			3				1						0/1		1

8		H 			0				1						1		0
9		I 			0				1						1		0
10...

SELECT wie beschrieben:
ergibt array (1=A, 2=B, 5=E, 6=F, 7=G, 8=H, 9=I)...

Das id 4 (1. child von 3) nicht im Array ist, ist gewollt da keine NAVIS und OK
Das id 5 (2. child von 3) da ist, ist OK
Das id 6 (1. child von 5) da ist, ist OK
Das id 7 (3. child von 3) da ist, ist OK

Das id 3 - die overview Seite - und Stammvater von 4,5,6,7 nicht im Array ist, liegt an ihrem navigationslosem Zustand.
Da ein Teil ihrer Kinder und Kindeskinder aber da sind, muss auch der Stammvater C wieder hinein. Nur Wie? (Abstrahiert für alle ähnlichen und möglichweise auch komplexeren Situationen.) Außerdem muss dabei der Stammvater id3 und seine im Array enthaltenen Kinder und KK mit "nonav" = true ausgezeichnet werden.

Wenn das nicht hilft, mache ich einen dump.

(zur Info: Man kann nicht mit Articletype hantieren, außer für 0, da das userseitig veränderbar ist.)

Andere Fragen später.

[garvinhicking]

Hi!

Das id 3 - die overview Seite - und Stammvater von 4,5,6,7 nicht im Array ist, liegt an ihrem navigationslosem Zustand.
Da ein Teil ihrer Kinder und Kindeskinder aber da sind, muss auch der Stammvater C wieder hinein. Nur Wie? (Abstrahiert für alle ähnlichen und möglichweise auch komplexeren Situationen.) Außerdem muss dabei der Stammvater id3 und seine im Array enthaltenen Kinder und KK mit "nonav" = true ausgezeichnet werden.

Evtl doofe Frage - aber: Warum ist denn die ID3 nicht einfach mit shownavi=1 eingetragen? Ich meine, wenn der Bloguser die Seite in der Navi haben wollen würde, müsste er die Option doch einfach nur aktivieren und alles wäre gut?!

LG,
Garvin

[Timbalu]

Will "er" eben nicht. "Er" will sie eben außerhalb der shownavi benutzen können. Und das, weil es eine Overview Seite ist. Ich nehme stark für das Aufgabengebiet: Überblick über einen eigenen, wie auch immmer geratenen und komplexen Block an (statischen) Seiten. Da macht zumindest eine Vor - Zurück Navigation, als Klinke zu den anderen statischen Seiten außerhalb dieses Blocks, keinen Sinn. Breadcrumb schon eher, aber auch das kann ja optional sein.
Insofern eine Einschränkung wenn das nicht möglich wäre und deshalb schade.
Ich finde es es gut, dass wir Articeltype 0 = gehookte Pseudo Statische Seiten, ("1" =) normale statische Seiten, ("2" =) overview und ("3" =) related category Seitentypen haben können. Und das sogar selbst noch unendlich erweitern können. Das macht das Ganze sehr vielfältig einsetzbar. Diese schier unendliche Komplexität als Schnittstelle zum CMS würde ich gern erhalten.

[garvinhicking]

Hi!

Aber Du schriebst doch, wenn ich dich richtig verstanden habe, weiter oben dass Du solche Overview-Seiten doch in der Navi haben willst, wenn die Kinder erscheinen? Das ist ja dann ein Widerspruch in sich - entweder, man will die Seiten in der Navi haben (dann muss man sie auch aktivieren, und wir müssen nichts ändern in der Abfrage). Oder man will die Seite nicht in der Navi haben, dann müssen wir auch nichts ändern in der Abfrage, weil es ja bewusst nicht erscheinen soll?

Ich glaube ich versteh das ganze immer noch nicht.

LG,
Garvin

[Timbalu]

Nein. Sie sind außerhalb der normalen Navi als ein eigenständiger Block an Seiten. Dieser Block wird durch das flag aus der normalen Navi für alle durch das SELECT bereitgestellten Seiten herausgerechnet, aber ermöglicht trotzdem soetwas wie ein eigenes Unternavi.

Ich schreibe also nicht, dass ich solche Overview-Seiten doch in der Navi haben will, wenn die Kinder erscheinen, sondern ich schrieb, dass ich solche Overview-Seiten (geflagt) doch im Array haben will, wenn die Kinder erscheinen.

[garvinhicking]

Nein. Sie sind außerhalb der normalen Navi als ein eigenständiger Block an Seiten. Dieser Block wird durch das flag aus der normalen Navi für alle durch das SELECT bereitgestellten Seiten herausgerechnet, aber ermöglicht trotzdem soetwas wie ein eigenes Unternavi.

Aber dort gibt es ja dann gezielt die ID der aktuellen Seite, dann würde ich den SELECT darauf ausrichten alle Seiten, unabhängig von shownavi, auszuwerten und später das Array durchzulaufen. Sprich, eine eigene Datenbankabfrage davon, das kann man nicht verallgemeinern mit dem SELECT der dann für die "normale" Navigation genutzt wird?

(P.S.: Die sonderformatierungen von Dir hier im Forum machen Texte für mich immer SCHWERER zu lesen, nicht leichter. )

[Timbalu]

Aber dort gibt es ja dann gezielt die ID der aktuellen Seite, dann würde ich den SELECT darauf ausrichten alle Seiten, unabhängig von shownavi, auszuwerten und später das Array durchzulaufen.

Auch wenn ich mir gerade nicht ganz klar bin ob ich die Konsequenz dessen vollständig überblicke (Aufgabe des cache arrays, noch mehr per request Einzel Berechnungen per $thispage), glaube ich doch, dass es das Ganze noch komplizierter werden ließe. Es war schon schwierig genug, aus einem Array das auf shownavi ausgerichtet ist, die korrekte Abfolge, gerade dann auch für breadcrumb und zukünftig für den aktuellen pointer mit diesem spezial nav unter Beibehaltung der vorgegebenen Arbeitsweise zu berechnen.

Sprich, eine eigene Datenbankabfrage davon, das kann man nicht verallgemeinern mit dem SELECT der dann für die "normale" Navigation genutzt wird?

Ist das eine Frage?

In meinem Tunnel wenigstens, erschien mir meine SELECT Wunsch Geschichte als einzig vernünftige Lösung, die ich noch halbwegs lös-, beherrsch-, und überblick-bar fand. Wenn du allerdings sagst das wäre so wie gewünscht sql-technisch gar nicht möglich, käme das höchstwahrscheinlich in den Keller. Ist das so?

[garvinhicking]

Hi!

Auch wenn ich mir gerade nicht ganz klar bin ob ich die Konsequenz dessen vollständig überblicke (Aufgabe des cache arrays, noch mehr per request Einzel Berechnungen per $thispage), glaube ich doch, dass es das Ganze noch komplizierter werden ließe. Es war schon schwierig genug, aus einem Array das auf shownavi ausgerichtet ist, die korrekte Abfolge, gerade dann auch für breadcrumb und zukünftig für den aktuellen pointer mit diesem spezial nav unter Beibehaltung der vorgegebenen Arbeitsweise zu berechnen.

Hhhm ok...ich kann meinen Kopf da nicht so richtig drumrumrangeln. Das Problem bei SQL ist ja, dass man eigentlich keine "Reverse"-Lookups macht, sondern nur JOINS nach "vorne" und nicht "zurück" entwickelt. Auch müsste es potentiell sonst kein Join sein, sondern tatsächliche in subselect. Subselects werden aber nicht von allen Datenbanken ermöglicht, das wäre dann potentiell eine MySQL-Sackgasse.

Kurzum...ich glaube ich kann da derzeit keine Lösung präsentieren. :-/

[Timbalu]

Ich aber, per Zufall und viel Hirnschmalz für die folgende Bearbeitung!

Code: Select all

SELECT id, pagetitle, parent_id, permalink, shownavi, show_breadcrumb FROM serendipity_staticpages WHERE publishstatus = 1 AND articletype != 0 AND is_404_page = 0 AND (shownavi = 1 OR show_breadcrumb = 1 OR (parent_id = 0 AND shownavi = 0 AND show_breadcrumb = 0)) AND (language = 'de' OR language = '' OR language = 'all') ORDER BY parent_id, pageorder

Das setzen vom flag 'excludenav' und herauspflücken für das $nav array geschieht später.
Das kann ich aber jetzt nicht alles erklären, daher erstmal weiter mit den Fragen.

Das weitere Ordnen hatte zur Folge, dass ich das $nav array etwas erweitert habe, damit das mittlere Segment zwischen PREVIOUS und NEXT, einen wirklichen Sinn bekommt, wenn man es nicht grundsätzlich nur auf den Namen von current page beschränkt. Dies würde dann so ausehen:

Code: Select all

Top (link) | << name von current page >> | Homepage (als Exit Link) 

Top oder Homepage würden nur dann zusätzlich erscheinen, wenn sie tatsächlich Sinn machen, also zB., wenn wenn PREV == Top, erschiene Exit, oder wenn PREV == child, erschiene Top. Bisher hatte man nur entweder CurrentPage oder TOP (beide als Link).

Das wiederum hat natürlich zur Folge, dass ich die frontend templates anfassen muss, im Plugin selber, wie auch in 2k11 (*) und Bulletproof, sofern vorhanden. Und natürlich, dass nach dem offiziellen Release, jeder mit eigenem Template und lokalen Kopien diese Dateien bearbeiten oder kopieren muss. Da in diesen frontend templates von staticpages sowieso noch etwas zu tun ist, auch in den 2k11 Kopien, ist das glaube ich vertretbar.
Umcoden scheint mir zu aufwendig, aber es ist eine knifflige Angelegenheit, da weit verbreitet.
Wie kann man das am Besten lösen?

(*) 2k11 verzichtet bisher sowieso ganz auf die shownavi und breadcrumb Navigation. Weil sie inkonsistent gelöst und daher fragwürdig waren? Das würde sich hiermit ändern!

Edit: committed to my dev repository and tagged as 4.23 (see page one of this thread).
Edit: fixed to 4.24!
Edit: finalize recursion for shownavi excludements in 4.25.