Beta 2.0 - Statische Seiten

[garvinhicking]

Hi!

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.

Klingt interessant; funktioniert dann aber nur für die Root-Ebene der Navigation, und nicht für Verschachtelungen in der 2., 3. usw. Ebene?

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?

Wichtig wäre hier auf jeden Fall, dass die alten Templates nicht einfach so "kaputt" gingen. Man müsste eine Variante finden, dass die alten Template entweder so funktionieren wie bisher, oder zumindest nicht grob "falsch" werden, oder gar Fehler produzieren.

Ggf. kann man das lösen indem man eine neue Variable nutzt ("$staticpage_navigation_v2" oder sowas), die man dann in den neuen Templates nutzt, und so die alten Templates dann mit einem alten Array arbeiten. Weiß nicht, hängt etwas konkret davon ab, was da geändert werden muss...

[Timbalu]

Klingt interessant; funktioniert dann aber nur für die Root-Ebene der Navigation, und nicht für Verschachtelungen in der 2., 3. usw. Ebene?

Das ist bereits gelöst und arbeitet wunderbar auch mt veritablen Löchern im Array. Sonst hätte das Ganze ja keinen Zweck gehabt. Diese prev/next Navi ist ja sowieso nur eine flache Navigation. D.h., die Einstellung shownavi YES erlaubt sie zu zeigen, unabhangig von ihrer Tiefe.

Wichtig wäre hier auf jeden Fall, dass die alten Templates nicht einfach so "kaputt" gingen. Man müsste eine Variante finden, dass die alten Template entweder so funktionieren wie bisher, oder zumindest nicht grob "falsch" werden, oder gar Fehler produzieren.

Ggf. kann man das lösen indem man eine neue Variable nutzt ("$staticpage_navigation_v2" oder sowas), die man dann in den neuen Templates nutzt, und so die alten Templates dann mit einem alten Array arbeiten. Weiß nicht, hängt etwas konkret davon ab, was da geändert werden muss...

Ich habe einfach das $nav['top'] (synonym für middle segment) array Teil erweitert und die alten varnamen und values als fallback für alte Templates drinnen gelassen.

Wir müssen eigentlich nur templates (2k11 und bulletproof) für das release von 2.0 und dem staticpage plugin für die plugin_staticpages.tpl updaten und die Änderung für andere irgendwo lauthals kommunizieren.

[garvinhicking]

Hi!

Wir müssen eigentlich nur templates (2k11 und bulletproof) für das release von 2.0 und dem staticpage plugin für die plugin_staticpages.tpl updaten und die Änderung für andere irgendwo lauthals kommunizieren.

Also nur dass wir uns richtig verstehen - eine alte plugin_staticpages.tpl würde durchauss noch funktionieren wie bisher, aber die erweiterte Navigation schlicht so nicht anzeigen? Sprich, das wäre nichts kritisches, und man müsste es nicht "lauthals" kommunizieren, sondern es würde z.b. im s9y upgrader für version 2.0-final als "template notice" erscheinen?

[Timbalu]

Also nur dass wir uns richtig verstehen - eine alte plugin_staticpages.tpl würde durchauss noch funktionieren wie bisher, aber die erweiterte Navigation schlicht so nicht anzeigen? Sprich, das wäre nichts kritisches, und man müsste es nicht "lauthals" kommunizieren, sondern es würde z.b. im s9y upgrader für version 2.0-final als "template notice" erscheinen?

1 JA (als ich die Frage stellte, war das auch noch nicht so ganz klar.)
2 OK.

[Timbalu]

Garvin,
Ich sitze gerade an der 2.0 Überarbeitung/Anpassung des staticpage hooks 'backend_category_showform' in die category.inc form.

Dazu ein paar Fragen.
Per staticpage kann man ja jeweils eine category zuordnen. (Ordne eine Staticpage einer Kategorie zu.)

1. Ist bzw sollte das eigentlich nur auf staticpage_categorypage type Seiten beschränkt sein, oder werden? (Macht das überhaupt Sinn für andere articletype Seiten?)

2. In welcher Beziehung steht oder soll diese Eintragung per page im Staticpage Plugin zum Selectauswahl hook für die einzelne category form Eintragung stehen? (Also: Ordne eine Kategorie einer Statischen Seite hinzu.)

Fakt ist, glaube ich wenigstens, dass die bisher nicht zugeordnet/miteinander verknüpft sind, denn nur das Letztere, also das category form, setzt die gewählte related staticpage ID auch wirklich in die serendipity_staticpage_categorypage Tabelle, während das staticpage form die ID per related_category_id Feld in die serendipity_staticpages Tabelle einfügt.

Soll/te das irgendwie verknüpft sein/werden, oder sind diese für völlig unabhängige Zwecke gedacht? (Welche sind das?)

Das kann schon ein alter Fehler (da auch in einem älteren dev blog von mir vorhanden) oder natürlich auch ein neuer von mir im Zuge der Überarbeitung sein, wenn das anders gewollt war.

[garvinhicking]

Hi!

Per staticpage kann man ja jeweils eine category zuordnen. (Ordne eine Staticpage einer Kategorie zu.)

OK. Ich erinnere mich aber nur düster.

1. Ist bzw sollte das eigentlich nur auf staticpage_categorypage type Seiten beschränkt sein, oder werden? (Macht das überhaupt Sinn für andere articletype Seiten?)

Wie ist es denn derzeit? Wenn man alle derzeit zuordnen kann, würde ich das auch so lassen...

2. In welcher Beziehung steht oder soll diese Eintragung per page im Staticpage Plugin zum Selectauswahl hook für die einzelne category form Eintragung stehen? (Also: Ordne eine Kategorie einer Statischen Seite hinzu.)

Die Beziehung sollte sein, dass man wenn man eine Blog-Kategorie auswählt, in dieser Kategorie auch Statische Seiten in die Blogansicht eingebunden werden können. Andersherum sollte, wenn eine statische Seite angezeigt wird, der eine Blogkategorie zugeordnet ist, die Einträge dieser Blogkategorie in einem Bereich der statischen Seite angeteasert werden. Das sind also zwei verschiedene Einsatzzwecke, meinst Du das?

LG,
Garvin

[Timbalu]

Moin

Wie ist es denn derzeit? Wenn man alle derzeit zuordnen kann, würde ich das auch so lassen...

Derzeit ist es offen für alle, aber ich sehe keine Einsatzszwecke außerhalb von type related_category pages. Wie sollen die aussehen?

Die Beziehung sollte sein, dass man wenn man eine Blog-Kategorie auswählt, in dieser Kategorie auch Statische Seiten in die Blogansicht eingebunden werden können.

Genau das ist mir nicht klar. Wie genau soll sich das äußern? Wie werden solch zugeordnete statische Seiten "einbunden"? Wo und Wozu, wenn nicht für den zweiten Teil deiner Antwort? Oder sollen solche Seiten als content entries unter eg. /categories/1-xyz erscheinen, so wie jeder andere dort angesiedelte Blogentry. Das wäre mir -wenn- bisher völlig entgangen. (*)

Andersherum sollte, wenn eine statische Seite angezeigt wird, der eine Blogkategorie zugeordnet ist, die Einträge dieser Blogkategorie in einem Bereich der statischen Seite angeteasert werden. Das sind also zwei verschiedene Einsatzzwecke, meinst Du das?

Ja das meine ich. Das anteasern ist der Einsatzzweck type: related_category page. (s.o.)

--------------------------------------------------------------------------------------
(*)
Edit: In dem interessanten Thread http://board.s9y.org/viewtopic.php?f=4&t=17169 wird diese Frage

ps. What effect has the "related static-page" reference in the category properties window?

leider unbeantwortet gelassen.

Und du selber hast mal gesagt

Even though static pages can be associated to categories, that only applies to related entries showing up. It does NOT put a "staticpage" INSIDE a category.

[garvinhicking]

Hi!

Derzeit ist es offen für alle, aber ich sehe keine Einsatzszwecke außerhalb von type related_category pages. Wie sollen die aussehen?

Andere Frage: Warum sollte man es einschränken?

Die Beziehung sollte sein, dass man wenn man eine Blog-Kategorie auswählt, in dieser Kategorie auch Statische Seiten in die Blogansicht eingebunden werden können.

Genau das ist mir nicht klar. Wie genau soll sich das äußern? Wie werden solch zugeordnete statische Seiten "einbunden"? Wo und Wozu, wenn nicht für den zweiten Teil deiner Antwort? Oder sollen solche Seiten als content entries unter eg. /categories/1-xyz erscheinen, so wie jeder andere dort angesiedelte Blogentry. Das wäre mir -wenn- bisher völlig entgangen. (*)

Dazu bedarf es eines Patches der eigenen entries.tpl, siehe README_FOR_RELATED_CATEGORIES.txt / staticpage-entries-listing.tpl - meinst Du das?

VG,
Garvin

[Timbalu]

Derzeit ist es offen für alle, aber ich sehe keine Einsatzszwecke außerhalb von type related_category pages. Wie sollen die aussehen?

Andere Frage: Warum sollte man es einschränken?

Oder andersherum: Warum soll man es erlauben, wenn es nur in die Irre führt und keinem wirklichen Zwecke dient?

Dazu bedarf es eines Patches der eigenen entries.tpl, siehe README_FOR_RELATED_CATEGORIES.txt / staticpage-entries-listing.tpl - meinst Du das?

Die staticpage-entries-listing.tpl ist aber ja genau das, was per hook in der plugin_staticpage_related_category.tpl für diese Teaserübersicht ab/aufgerufen wird, wenn man die Seite als type related category speichert.

Hmm möglich. Mit dem Text Patch hatte ich tatsächlich noch nicht herumgespielt.
Dann aber nur ein bestimmter Teil desselben, der da wäre:

Code: Select all

{if ($view == 'categories')}
    markup
    {if $staticpage_categorypage}
        <a href="{$staticpage_categorypage.permalink}">{$staticpage_categorypage.pagetitle}</a> zur Artikelübersicht
    {else}
        anderer Fall link HOMEPAGE
    {/if}
    markup
{/if}

Im Grunde also nur ein Backlink zur statischen related category teaser Artikelübersichts Seite. Also dem Fall, der in der categories Form eingetragen wird. (Im Grunde alles nur ein Fall! IMO)

Trage ich eine Kategorie als related auf einer statischen Seite form ein, so wird sie in der categories form nicht als bereits gewählt angezeigt, da Tabellenweise unverknüpft. Und auch der patch findet nicht statt, sondern fällt auf den Homepage link als Artikelübersicht. Das ist (alles) zumindest leicht verwirrend, finde ich.
Was wäre denn möglicherweise verloren, wenn ich sie eventuell aufeinander abstimmte?

Sind das Korinthen?
Ich will die Überarbeitung einfach ordentlich abliefern und verstehen. Also sorry für das insistieren!

[garvinhicking]

Hi!

Oder andersherum: Warum soll man es erlauben, wenn es nur in die Irre führt und keinem wirklichen Zwecke dient?

Ggf. möchte man ja im Blog bei einer speziellen Kategorie auf eine einzelne statische Seite hinweisen? Also wenn ich in einem Law-Blog z.b. die Kategorie "IT-Recht" habe, und dann auf eine statische Seite hinweisen möchte, die einfach einen Text zu "Hier erfolgt keine Rechtsberatung..." enthält? Das ist ja dann keine overviewpage oder related_categorypage, sondern eine ganz normale. Auf der Seite müsste man dann ja wiederum nicht unbedingt Blog-Einträge teasern. Also ich sehe da keine Irreführung eines Users, muss doch jeder selber wissen, womit er die Kategorie gerne verbinden soll?

Trage ich eine Kategorie als related auf einer statischen Seite form ein, so wird sie in der categories form nicht als bereits gewählt angezeigt, da Tabellenweise unverknüpft. Und auch der patch findet nicht statt, sondern fällt auf den Homepage link als Artikelübersicht. Das ist (alles) zumindest leicht verwirrend, finde ich.

Das klingt eher nach einem Bug für mich? Probiert das mal aus mit nem staticpage-plugin von vor ein paar Monaten, vor den Anpassungen auf 2.0 oder anderen gröberen Umbauten. Gut möglich dass da etwas kaputt ging?

Ich will die Überarbeitung einfach ordentlich abliefern und verstehen. Also sorry für das insistieren!

Das ist schon gut so. Sorry dass ich eher nicht verstehe, worum's da genau geht und nicht so tief drin stecke wie Du momentan

[Timbalu]

Ggf. möchte man ja im Blog bei einer speziellen Kategorie auf eine einzelne statische Seite hinweisen?

Aber doch nicht automatisiert verlinkt? Wie soll das gehen? Manuell wäre soetwas doch eine ganz normale statische Seite, die nicht intern mit einer Category verknüpft ist. Wir haben natürlich je nach eingestellter option und tree, ev. die einfache "hat childpage" Anzeige, aber die hat soweit ich weiß nichts mit einer eventuellen Verknüpfung einer category zu tun, sondern läuft ganz unabhängg davon.

Also wenn ich in einem Law-Blog z.b. die Kategorie "IT-Recht" habe, und dann auf eine statische Seite hinweisen möchte, die einfach einen Text zu "Hier erfolgt keine Rechtsberatung..." enthält? Das ist ja dann keine overviewpage oder related_categorypage, sondern eine ganz normale. Auf der Seite müsste man dann ja wiederum nicht unbedingt Blog-Einträge teasern. Also ich sehe da keine Irreführung eines Users, muss doch jeder selber wissen, womit er die Kategorie gerne verbinden soll?

Und warum sollte die Seite dann als related to that category eingetragen werden? Nur zur (späteren) Info des Users, also ohne funktionalem Ergebnis?
Sprechen wir hier noch von derselben Sache? Siehe:

Per staticpage kann man ja jeweils eine category zuordnen. (Ordne eine Staticpage einer Kategorie zu.)
1. Ist bzw sollte das eigentlich nur auf staticpage_categorypage type Seiten beschränkt sein, oder werden? (Macht das überhaupt Sinn für andere articletype Seiten?)

Denn related category Seiten sind nur als Seiten für Kategorie Übersichten gedacht. Etwas anderes machen die Seiten ja nicht, wenn sie zb einfache Articletype 1 = Article Seiten sind. Das jedenfalls ist mein bisheriges Verständnis. Weder die Tabellen sind verknüpft, noch macht ein rc Seite als type 1 irgendetwas anderes, als eine ganz normale statische Seite. Am Beispiel des RC Text Patches sieht man: {$view == 'category'} gibt es nur, wenn ich im Frontend eine Kategorie anklicke. Aber $staticpage_categorypage hat keinen Inhalt, wenn die cat_id nur in der statischen Seite selbst gesetzt wurde. Übersehe ich hier insgesamt irgend etwas?

Trage ich eine Kategorie als related auf einer statischen Seite form ein, so wird sie in der categories form nicht als bereits gewählt angezeigt, da Tabellenweise unverknüpft. Und auch der patch findet nicht statt, sondern fällt auf den Homepage link als Artikelübersicht. Das ist (alles) zumindest leicht verwirrend, finde ich.

Das klingt eher nach einem Bug für mich? Probiert das mal aus mit nem staticpage-plugin von vor ein paar Monaten, vor den Anpassungen auf 2.0 oder anderen gröberen Umbauten. Gut möglich dass da etwas kaputt ging?

Nee, das ist kein Bug (IMHO), bzw. wenn, dann schon ein sehr alter. Wie ich schon schrieb.

Für mich sieht das eher so aus: 2 Entwickler mit unterschiedlicher Herangehensweise für dasselbe Problem (Falk/stm). Und dann wurde einfach vergessen das miteinander zu verknüpfen, dass es auch Sinn bekommt, so jedenfalls mein Eindruck.

Ich würde daher gerne folgendes machen. Die eigentliche Auswertung für das categoryform und die Anzeige im Frontend erfolgt aus der `serendipity_staticpage_categorypage` Tabelle, während die Eintragungen im staticpages table Feld 'category_id' der staticpage form dienen. Trage ich im letzten also eine related category ein, so wird diese ID auch gleichzeitig im Ersteren eingetragen (und vice versa).

Mir schwirren die Gedanken. Kannst du mich irgendwo festnageln, wäre ich dir sehr verbunden

[garvinhicking]

Hi!

Und warum sollte die Seite dann als related to that category eingetragen werden? Nur zur (späteren) Info des Users, also ohne funktionalem Ergebnis?

Ach, ich glaube jetzt verstehe ich. Ich ging die ganze Zeit davon aus dass es um einen Hook geht, der innerhalb der Kategorie-Übersicht geht, nicht innerhalb des Plugins.

Dann wäre die Frage, wenn man den Seitentyp einer Seite ändert, müsste man per javascript die optionen einblenden die dann relevant werden. Hier stimme ich Dir dann zu, diese Kateogrieoption beim bearbeiten einer statischen Seite sollte nur festgelegt werden können, wenn eine statische Seite vom Typ Categorypage ist.

Ich würde daher gerne folgendes machen. Die eigentliche Auswertung für das categoryform und die Anzeige im Frontend erfolgt aus der `serendipity_staticpage_categorypage` Tabelle, während die Eintragungen im staticpages table Feld 'category_id' der staticpage form dienen. Trage ich im letzten also eine related category ein, so wird diese ID auch gleichzeitig im Ersteren eingetragen (und vice versa).

Auch auf die Gefahr hin das hier alles nicht 100% zu durchblicken: Das klingt doch gut so.

LG,
Garvin

[Timbalu]

Ach, ich glaube jetzt verstehe ich. Ich ging die ganze Zeit davon aus dass es um einen Hook geht, der innerhalb der Kategorie-Übersicht geht, nicht innerhalb des Plugins.

Hätten wir denn sowas irgendwo?

Dann wäre die Frage, wenn man den Seitentyp einer Seite ändert, müsste man per javascript die optionen einblenden die dann relevant werden. Hier stimme ich Dir dann zu, diese Kateogrieoption beim bearbeiten einer statischen Seite sollte nur festgelegt werden können, wenn eine statische Seite vom Typ Categorypage ist.

So oder so ähnlich ist es gemeint, jawohl!
(Gibst du "endlich" auf oder hast du am Ende wirklich verstanden was ich meinte... )


Edit:
Frage: Die beiden hooks 'backend_staticpages_update' und 'backend_staticpages_insert' kleben direkt unter dem jeweiligen DB Eintrag Wozu sollen die dienen? Und wo werden die benutzt?

[garvinhicking]

Hi!

(Gibst du "endlich" auf oder hast du am Ende wirklich verstanden was ich meinte... )

Ich GLAUBE ich habe es verstanden

Frage: Die beiden hooks 'backend_staticpages_update' und 'backend_staticpages_insert' kleben direkt unter dem jeweiligen DB Eintrag Wozu sollen die dienen? Und wo werden die benutzt?

Z.b. vom Google Sitemap plugin.

LG,
Garvin

[Timbalu]

Frage: Die beiden hooks 'backend_staticpages_update' und 'backend_staticpages_insert' kleben direkt unter dem jeweiligen DB Eintrag Wozu sollen die dienen? Und wo werden die benutzt?

Z.b. vom Google Sitemap plugin.

tztztz - da muss man erstmal drauf kommen... Danke.

Noch kurz zurück, bitte.
Eigentlich wollte ich gerade meine Lösung für die Tabellenverknüpfung commiten, aber wir haben sowieso folgendes Problem:

• Die serendipity_staticpage_categorypage Tabelle erlaubt nur einen assoziierten Eintrag per Cat. Also Category X assoziiert mit Staticpage Y. Diese assoziierte Seite Y hat damit streng genommen als einzig tatsächlichen Auftrag, related category Übersichts Teaser zu erstellen.
  Trotzdem, so muss ich zugeben, und darauf zielte wahrscheinlich dein "Law-Blog" example, kann man ja auch auf die Idee kommen, einen articletype Article oder Overview dafür zu wählen, um irgend etwas anderes der Pluginseite per link "vorauszuschicken", weil man gerade nicht eine Teaserübersicht haben will. Das natürlich nur verlinkt, so wie es in der TXT Patch Datei vorgeschlagen wird. Und auch nur in diesem Fall.
  Also kurz: Der Seitenleisten Categorylink öffnet das category archive, eventuell mit verlinkten header oder footer zur zugeordnete reCat Seite, und dessen Ausgabe je nach type.

• Die serendipity_staticpages Tabelle ermöglicht aber bisher unbegrenzte Assoziierungen als related_category per Staticpage Entry.

Sie miteinander zu verknüpfen, was ja eigentlich Sinn machen sollte, wirft eben die Frage auf, ob entweder auch in der staticpages Tabelle nur eindeutige Assoziierungen erlaubt werden (siehe auch deine Idee mit dem javascript), oder sie möglicherweise doch nicht miteinander verknüpft werden sollen.
Letzteres hieße, mit dem jetzigen, wenig verständlichen Zustand zu leben, für den (fragwürdigen) Gewinn, multiple statische Seiten ein und derselben Kategorie zuordnen zu können. Für was auch immer.

Meinungen?

Ich persönlich würde wahrscheinlich eher die multiple Assoziierung verbieten, soweit das mit vertretbarem Aufwand möglich ist.