Donnerstag, 2. Februar 2023
verstecken von Kategorien
Habe nun bemerkt, dass man nicht mehr ganze Kategorien (oder deren Unterkategorien) verstecken kann. Ich habe ja im Live-Blog (und nun auch hier) eine neue Kategorie "Unsichtbar" eröffnet und dahin verschiedene Unterkategorien verschoben. Bei der Kategorie "Unsichtbar" habe ich den Schalter "Artikel von Unterkategorien verstecken?" auf "Ja" gestellt.
Zu Beginn der Woche hat das noch wunderbar funktioniert und alle Kategorien unter "Unsichtbar" wurden im Blog und im entrypaging nicht dargestellt.. Siehe dieser Kommentar.
Nachtrag vom 03.02.2023: Falsch! Das hat nie so funktioniert. Ich habe das zu wenig gut getestet. Die Funktion "Artikel von Unterkategorien verstecken" kann nicht auf der Blog-Entry-Seite angewendet werden, da hier alle Kategorien aufgelistet werden. Verstecken lassen sich Beiträge/Artikel nur mit dem entryproperties-Plugin und der Funktion "Nicht in Artikelübersicht anzeigen".
In der Zwischenzeit haben wir am categorytemplates-Plugin herumgeschraubt und nun funktioniert das nicht mehr. Es werden immer alle Artikel angezeigt. Egal, ob der Schalter "Artikel von Unterkategorien verstecken?" auf "Ja" oder "Nein" steht.
(Wobei... Eigentlich gehört das zum Core und hat nichts mit dem Plugin zu tun). 🤔
Hier (und auch im Live-Blog) ist derzeit die Kategorie "Rikscha" mit über 300 Einträgen eine Unterkategorie von "Unsichtbar". -> Trotzdem sichtbar. z.B.ab hier: https://www.blog.dokumenzi.ch/archives/P12.html
Dieser Link ist nicht aktiv. Er enthält eine kopierbare Trackback-URI, um manuell ein Ping- und Trackback zu diesem Eintrag für ältere Blogsysteme zu generieren; zB (immer noch valide) über das zur Verfügung gestellte Eintragsfeld des serendipity_event_trackback Plugins. Serendipity und andere Blogsysteme erkennen die Trackback-URL heutzutage aber automatisch anhand der Artikel-URL. Die Trackback-URI für ihren Link des Sender-Eintrages lautet daher wie folgt: »https://www.blog.dokumenzi.ch/2683-verstecken-von-Kategorien.html«
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Ian Styx am :
Mein Hirn windet sich.... Nochmal für alte Herren..:
In der Kategorie "Unsichtbar" gibt es keine Artikel ? Ja.
Die Kategorien" Fotogalerie", "Verkaufe", "Links" und "Rechts" sind Unterkategorien von "Unsichtbar"? Ja.
Sie sind direkte Nachkommen, ergo Geschwister? Ja.
Unsichtbar steht auf "Artikel von Unterkategorien verstecken?" auf "Ja" ? Ja.
Das hat letzte Woche noch geklappt und plötzlich nicht mehr? Ja.
Beide Instanzen nutzen ebenfalls das categorytemplates Plugin (und bevorzugt auch an gleicher Stelle in der Liste) in letzter Version mit gleichen Einstellungen und sind beide sicherheitshalber noch einmal mit denselben abgespeichert? Ja.
Sind die 4 genannten Unterkategorien in der Option "Übergeordnete Kategorie" auf "Unsichtbar" gestellt worden? 😀
Falls ja, entsprechen die Eintragungen der styx_category Tabelle diesen Eintragung bzgl der inneren Verzahnung?
Beat Post author am :
Die meisten Fragen hast Du Dir ja schon selbst beantwortet.
Wenn ich nur die letzte Frage beantworten soll, dann eindeutig "Ja" -> Das sieht man ja auch an der Baumstruktur der Kategorien.
Verstehe ich nicht wirklich, doch ich checke das mal in der DB. -> Ja, die "parentid" ist richtig gesetzt (Auf die id von "Unsichtbar").
Ian Styx am :
Wichtig ist da zB die parent ID und die hide sub. Bei der Ersteren muss die ID der Unsichtbar Kategorie stehen. Hide sub hat eine 1 wenn es aktiviert, sonst wohl eher 0.
Meine "Ja." waren eher Fragen ... so wie Richtig, nicht wahr? 😀
Huch was ist jetzt los... beim Absenden erscheint hier plötzlich die funtions_config und das sogar farbig behandelt so wie es auf GitHub zu sehen ist...
Beat Post author am :
Ja, die Kategorie "Unsichtbar" hat ID 24 und hide_sub steht auf "1"
Die Unterkategorien haben als parentid "24" und hide_sub steht auf "0" (habs aber auch schon mit "1" probiert, was aber auch nichts bewirkt (logisch, weil es darunter ja auch keine weiteren Subkategorien gibt)).
Und ja, alle Deine angenommenen Jas sind auch effektive Jas. 😉
Ian Styx am :
JAHA... 🙂
Aber du sagst das alle anderen nun versteckten (unter) Kategorien nun aus der Entries Liste/Anzeige herausgerechnet sind außer der Rikscha Kategorie. Richtig?
Dann schau dir mal die Kategorie (form) Einstellungen an. Rikscha ist die einzige deren Option
Sollen Einträge dieser Kategorie von Eintragslisten und RSS-Feeds ausgeschlossen werden?
auf JA steht.
Probiere es mal damit sie wieder auf Nein zu stellen.
Das ist ja eine Option aus dem categorytemplates Plugin und dient dazu die ( von mir schon mal beschriebene neue Funktion einer unabhängigen Kategorie mit eigenem Kleid ) so zu ermöglichen, dass auf dem "normalen" Blog diese Kategorie dann in den feed und entries Listen ausgeschlossen wird. Wahrscheinlich ( wenn es so ist ) liegt dann irgendeine Art von Regression vor, so das sich die normale Core Möglichkeit ( die du jetzt nutzt ) mit der neuen Unabhängigen irgendwie verheddert.
Beat Post author am :
Nein. Ich sage, dass gar keine Unterkategorie von "Unsichtbar" herausgerechnet (oder: nicht angezeigt) wird. Ich habe das Verzeichnis "Rikscha" nur deshalb zu einem Unterverzeichnis von "Unsichtbar" gemacht, weil mit über 300 Einträgen sehr schnell ersichtlich ist, ob nun diese Artikel versteckt werden oder nicht. Das entrypaging zeigt ja u.A. die Summe aller dargestellten Artikel (also der nicht versteckten) dar. +/- 300 ist somit schnell ersichtlich.
Am Montag habe ich dies in Live-Blog genau so gemacht und da hat alles einwandfrei funktioniert. Ich habe damals sogar das "history_daylist"-File gelöscht um zu kontrollieren, ob auch dort die versteckten Artikel verschwinden, was sie auch getan haben. Deshalb bin ich mir so sicher, dass es am Montag noch richtig funktioniert hat.
Ian Styx am :
Ich sachs ja ... Alter Herr ...🤪
Morgen in alter Frische!
Beat Post author am :
Das hat keinen Einfluss. Damit habe ich herumexperimentiert. Bewirkt aber nichts. Ausserdem ist das ja ein Teil des categorytemplates-Plugin, die "Artikel von Unterkategorien verstecken?" - Geschichte ist aber Teil des Core. (Deshalb irritiert es mich ja auch sehr, dass das nun plötzlich nicht mehr greift).
Es muss jedoch etwas mit dem category-Templates zu tun haben, denn das ist programmtechnisch das Einzige, was im Live-Blog seit Montag geändert wurde.
Ian Styx am :
Ich gebe mal kurz eine Zwischenstandsmeldung.
Ich habe kontrolliert, ob es mit dem categorytemplates Plugin zu tun hat, in dem ich dieses kurzerhand deaktiviert habe. Ergebnis: Ohne Veränderung auf die Anzeige der eigentlich versteckt gewünschten Kategorien.
Dann habe ich die mir die SQL für die Entrieslistenausgabe angesehen und festgestellt, dass dort gar nichts diesbezügliches erwähnt wird.
Wir beide sind/waren also (kurzfristig) auf die "Annahme" hereingefallen, dass die Core Kategorie Option: Artikel von Unterkategorien verstecken? generell für die entries Listen gilt. Vor allem da du ja gesagt hast, es hätte funktioniert und ich das bei der "MUTIG!" Geschichte auf den ersten Blick auch bestätigen konnte ( meine ich mich zu erinnern ).
ABER
In der Info von Artikel von Unterkategorien verstecken? steht:
Standardmäßig werden bei der Ansicht einer Kategorie im Frontend alle Artikel der gewählten Kategorie und aller Unterkategorien angezeigt. Wenn diese Option aktiviert wird, werden Artikel von Unterkategorien nicht angezeigt.
Und da müsste man das "bei der Ansicht einer Kategorie" besonders betonen. Es ist also schon immer so gewesen. Und ich erinnere mich jetzt auch Dunkel, dass da ein ähnliches Problem war als ich die zusätzliche categorytemplates Option mit dem neuen Kleid eingeführt hatte und deshalb akrobatische Übungen machen musste, um die anderen Kategorien in der Anzeige genau dieser Kategorie herauszurechnen, es also weitgehend unabhängig scheinen zu lassen.
Und weil das schon wieder Jahre her ist, geraten solche Extras auch gerne mal in Vergessenheit und müssen für neuere Gegebenheiten auch wieder genauer überprüft werden.
Soweit so gut ... aber nicht für das Statement warum das anscheinend ja kurzzeitig doch geklappt zu haben schien. Insofern sollte auch dieser Zwischenstand noch nicht endgültig sein.
Beat Post author am :
Ich vermute, dass wir des Rätsels Lösung gefunden haben: Es hat noch nie so funktioniert, wie ich mir das gewünscht habe! 😢
Wie ich dazu komme:
Heute Morgen hatte ich die Idee, dass ich die serendipity_event_categorytemplates.php von V 2.3.1 wieder einspiele und somit den Plugin-Zustand vom Montag wieder herstelle (weil ich ja annahm, dass es damit zu tun hatte). Das habe ich nun gemacht und (leider) keine Veränderung im Verhalten bezüglich "versteckter Kategorien" festgestellt. Da versteckt sich rein gar nichts.
Wie komme ich denn dazu um zu behaupten, dass es Anfang der Woche funktionierte?
Ich glaube nun, dass meine Fehlinterpretation erst mit dem 4.Schritt passiert ist.
Jedesmal, nachdem ich eine Kategorie von "14-BOLG" nach "ohne Oberkategorie" verschoben habe konnte ich bei einem Pagerefresh der Blog-entry-Liste sehen, wie sich im entrypaging die Anzahl der angezeigten Beiträge verringerte, bis gar nichts mehr angezeigt wurde (war aus meiner Sicht logisch, denn die Kategorie "14-BLOG" war leer und alle Unterkategorien von "24-Unsichtbar" wurden -wie gewünscht- versteckt).
Und vermutlich habe ich erst dann:
E voilà: Ich habe wieder die gewohnte Enty-Liste gesehen. Das darin auch (die wenigen) Beiträge der Unterkategorien von "24-Unsichtbar" angezeigt wurden, habe ich wohl aus lauter Freude nicht gemerkt.
Und was ist nun die Konsequenz daraus?
Wenn ich bei der Anzeige /?blog und /archives/P....html bleiben will, muss ich alle Beiträge, die ich in der entry-Liste verstecken will einzeln editieren und die entryproperties-Plugin-Funktion "Nicht in Artikelübersicht zeigen" aktivieren. Der Aufwand dafür hält sich in Grenzen, da es nur um die 10 Artikel sind.
Oder: Ich baue wieder zurück auf die Hauptkategorie BLOG (neu wird sie vermutlich ID=25 kriegen) und alles funktioniert wieder so, wie vor einer Woche. Mit der Entry-List-Adresse /categories/25-BLOG und den entrypaging-Seiten /categories/14-BLOG/P....html
Beat Post author am :
PS: Ich kann Deine obigen Ausführungen bestätigen. Ich habe auf https://www.styx.dokumenzi.ch/ etwas rumgespielt, weil es da kein categorytemplates-Plugin und nur 27 Artikel gibt. Ich habe alle Kategorien mit Einträgen unter die Oberkategorie "Uebriges" verschoben und dort den "Verstecken von Unterkategorien"-Schalter auf Ja gestellt.
Wenn man jetzt im Sidebar-Category-Plugin auf die Kategorie "Uebriges" klickt, sieht man nur den "bla-Bla-Artikel", der als einziger Artikel in dieser (Mutter-)Kategorie ist. Alle anderen Artikel (der Unterkategorien) werden versteckt.
Wie Du richtig erwähnt hast, funktioniert die Verstecken-Geschichte nur innerhalb oder unterhalb einer /categories/
Direkt in der Entry-Liste (/?frontpage oder so) kann man Artikel anscheinend nur mit der entryproperties-Plugin-Funktion "Nicht in Artikelübersicht zeigen" verstecken.
Ian Styx am :
Tja so ist es wohl ... aber es ist eben auch kompliziert und so unterstellt man Serendipity Sachen die gar nicht existieren. Das geht mir selber oft so.
Ich würde jetzt an deiner Stelle warten ob aus dieser Gemengelage nicht doch noch etwas Sinnvolles entspringt.
ZB habe ich - dank dir - in den letzten Stunden gesehen, dass meine "3 auf einen Streich" wenigstens für eines dieser Tiere genial danebenlagen. Da kommt also noch was, wenigstens eine Reparatur. Vielleicht fällt im Zuge dessen oder danach für das Ausschlussproblem auch noch etwas ab.
Ian Styx am :
Ich habe jetzt erstmal die categorytemplates Sache gefixt und der Kategoriebekleidung eine experimentelle Note verpasst. Haute Couture sozusagen. 😊
Auch das könnte eventuell auch nur einer Annahme, die der Wirklichkeit möglicherweise nicht standhält, folgen. Die Aussage selbst ist wahr wenn es um die normale Benutzung geht, aber ob sie auch auf das von dir gewünschte Korsett passt ist mir gerade noch fraglich. Am besten du experimentierst damit erst ein wenig auf styx.doku herum, denn in den Unsichtenbaren Kategorien sind es doch auch entries Listen und da sollen sie doch erscheinen.
Ich muss da selbst erst noch ein wenig mehr darüber nachdenken...
Beat Post author am :
Für weitere Tests wollte ich das categorytemplates-Plugin auf https://www.styx.dokumenzi.ch/ installieren. Nach erfolgter Installation erhielt ich folgende Error-Page:
Der erste Satz sagt es und auch ein erster Augenschein zeigt, dass das Plugin installiert wurde.
Wenn ich nun in der Seitenleiste der Hauptseite auf die Kategorie "Uebriges" klicke, erscheint im archives-Plugin (darunter) folgende Warnung:
Das war vorher nicht der Fall.
Was ich zum categorytemplates-Plugin noch sagen kann ist, dass der letzte Punkt: "Sollen Einträge dieser Kategorie von Eintragslisten und RSS-Feeds ausgeschlossen werden?" nach wie vor wirkungslos ist. (Das wäre ja auch eine Lösung für meine Anforderung gewesen).
Ian Styx am :
Das warning - also Meldung Nr 2 - kann aber womöglich auch nur ein crossover sein, weil irgendwelche weiteren workflow Sachen wegen des geschmissen "Fehlers" nicht gesetzt wurden.
Ist die categorytemplates Tabelle denn wirklich installiert worden (PMA fragen) ?
Sonst liegt es vielleicht nur am workflow, da es besonderer Weise schon in der introspect_config_item() augerufen wird und muss daher vielleicht nur als known to fail "db-tiert" werden. ...Aber nicht das uns schon wieder ein falsch formatiert heraufgeladenes RAW file dazwischenfunkt... 😋
Anzumerken ist "deine Beschreibungen werden immer genauer und sind" Altherrengerecht! 🤗
Super das das nun geklappt hat und alles zufriedenstellend arbeitet! Und meine Bedenken dann doch unbegründet.
Einen gesegneten Abend!
Beat Post author am :
Zur categorytemplates Tabelle von https://www.styx.dokumenzi.ch/phpMyAdmin sagt: Ja, die Tabelle wurde erstellt.
Unheimlich ist jedoch, dass als Typ "Aria" eingetragen ist (alle anderen Tabellen sind "MyISAM") und die Kollation ist "utf8_general_ci" (alle anderen Tabellen sind "utf8mb4_general_ci")
Hier (https://www.blog.dokumenzi.ch/) ist die categorytemplates Tabelle genau gleich ausgezeichnet, wie alle anderen Tabellen.
Nachtrag: Ich habe die Tabelle nun auch auf "MyISAM" und "utf8mb4_general_ci" geändert. Die Warnung im archives-Plugin erscheint nun nicht mehr.
Ian Styx am :
Nein, eigentlich nicht so unheimlich, denn My ist die eine Tochter von Monty Widenius, dem Begründer von MySQL. Als MySQL von Oracle aufgekauft wurde (Pfui Deibel) kam das neuere InnoDB Format hinzu. Als sich später ihre Wege wieder trennten, entstand MariaDB (die zweite Tochter von Monty) und dem schon sehr alten Format MyIsam gesellte sich das viel neuere Aria Format hinzu. Das wurde mit 10.3 bis 10.5 Versionen ständig weiter ausgebaut, so dass es ab Version 10.5 endlich über soviel genügenden Indexierungs Cache verfügt, dass die ganzen Unicode Anpflanzungen (Emojis etc) über genügend Platz im utf8mb4 bit Raum verfügen.
Styx nimmt darauf (abgestuft) Rücksicht. Seit Version 3.2.0 wird ARIA als storage Engine verwendet (suche im NEWS ChangeLog). Irgendwann (wenn das komplett im Mainstream gelandet ist) wird es eine Umstellung für alte Tabellenformate geben. ARIA sollte eigentlich auch Maria heißen, wurde jedoch wegen der Namenskollision so genannt und bedeutet soviel wie "edel". 😀 Du hast als noble in das alte Format geändert, was aber nicht schlimm ist, denn die categorytemplates Tabelle braucht eigentlich keine erweiterten Formen.
Wie denn? (im Unterschied.)
Gab es da einen inneren Zusammenhang? Also, ...erschien die Warnung (+ vielleicht sogar die Exception) denn immer noch als du categories bzw config des ct plugins vor der Veränderung neu aufriefst?
Beat Post author am :
Wie oben beschrieben:
nächste Frage:
Keine Ahnung. Ich habe das nicht weiter/genauer verfolgt. Meine Beobachtung war, dass die Warnung vor der Änderung der categorytemplates-Tabelle da war und danach nicht mehr.
Beat Post author am :
Ich versuche mal zusammenzufassen. Meine Anforderung ist:
Ich will bestimmte Beiträge/Artikel nicht in der Haupt-Eintragsliste (Entry-Page) sehen und diese sollen dann ebenfalls nicht vom history-Plugin erfasst werden. Wichtig zu wissen ist hierbei, dass die Hauptseite meines Blogs eine statische Seite anzeigt. Über den Menülink "BLOG" kommt man dann auf die eigentliche Haupt-Eintragsliste (oder eben: Entry-Page)
Mein urspünglicher Ansatz basierte auf Kategorien und umging damit die Haupt-Eintragsliste (Entry-Page) vollständig. "Meine" Haupt-Eintragsliste hiess also nicht mehr /?frontpage sondern /categories/%name (in meinem Fall: categories/BLOG). In dieser Kategorie gab es keine Blog-Beiträge sondern nur Unter-Kategorien (die ich darstellen wollte). Daneben gab es andere Kategorien, die ohne Hauptverzeichnis waren (also nicht Unterkategorie von BLOG. Diese wurden demzufolge nicht angezeigt.
-> Das hat soweit alles recht ansprechend funktioniert. Nur das entrypaging-Plugin hustete etwas (bei bestimmten Kategorien).Dieses Problem habe ich mir selbst eingebrockt, weil ich in der Konfiguration die ID der Kategorie (categories/%id%-%name%) entfernt habe. Nachdem diese IDs wieder eingefügt wurden, hat alles zur Zufriedenheit funktioniert. (Das wurde hier im Beitrag /2682-entrypaging-und-Kategorien.html abgehandelt).
Ein kleiner Störfaktor war die etwas "unschöne" URL-Vergabe. Die Haupt-Eintragsliste hiess bei mir also /categories/14-BLOG anstatt Programm-konform /?frontpage und die Archivseiten (entrypaging) hiessen /categories/14-BOLG/P....html anstatt /archives/P....html.
Um diese schöneren/korrekteren URLs zu erhalten, startete ich verschiedene Versuche.
Mein aktueller Wissensstand ist so:
Meine Anforderung (gewisse Beiträge/Artikel oder ganze Kategorien zu verstecken) wird nur dann erfüllt, wenn man jeden einzelnen Beitrag, den man nicht in der Eintragsliste sehen will, öffnet, mithilfe des entryproperties-Plugins den Schalter " Nicht in Artikelübersicht zeigen" auf "Ja" setzt und danach den Artikel wieder speichert.
Auf Ebene der Kategorien (core) und mit dem categorytemplate-Plugin lässt sich die Aufgabenstellung nicht lösen. Egal was man einstellt. auf der Haupt-Eintragsliste (/?frontpage) und im entrypaging (/archives/P....html) werden immer alle Beiträge angezeigt.
Zugunsten der schöneren/korrekteren URLs habe ich also im Live-Blog alle zu versteckenden Artikel editiert. Soweit passt das jetzt.
Ich will das Thema somit zur Seite legen.
Ian Styx am :
Ich würde ergänzen: ..Haupt-Eintragsliste, durch die Voranstellung einer permanenten Startseite (statischen Seite), hieß also..
😉
Auch wenn du damit abgeschlossen hast...
Frage: Hat sich dir schon bewiesen dass sich das history Plugin wirklich daran hält?
Beat Post author am :
Ja. Habe gestern Abend einen Testbeitrag mit Datum 03.02.2021 erstellt. Via entryproperties-Plugin "Nicht in Artikelübersicht zeigen" und "Eintragsinhalt im RSS-Feed verstecken" beides aktiviert und dann den Beitrag gespeichert.
Danach das history_daylist-File gelöscht und mit Refresh der Blog-Haupteintragsseite neu generiert. Dort wurde dieser Beitrag nicht dargestellt, was richtig und gewollt ist. Auch beim zurückblättern mit entypaging wurde der Beitrag nicht angezeigt.
Damit jetzt nicht alles nur Friede,Freude, Eierkuchen ist, noch diese Feststellung: Im Archiv (https://www.beatsblog.ch/archives/2021/02/summary.html) wurde dieser versteckte Eintrag trotzdem aufgelistet.
Zur Verdeutlichung bilde ich das hier mal kurz nach.
Um der Frage vorzubeugen, WO denn dieser Beitrag überhaupt noch dargestellt werden soll, so ist die Antwort: In dessen Kategorie und dem zugehörigen category-entrypaging. Und das funktioniert auch. Siehe diese Seite: https://www.blog.dokumenzi.ch/categories/5-EDV/P3.html
Ian Styx am :
Ei ja wo kämen wir da hin... 😀
Ich habe getüftelt. Und ein Problem mit den Kleidern des categorytemplates hat mich total aus der Bahn geworfen, bis ich das vorhin endlich gelöst hatte. Es lag hauptsächlich daran, dass das multilingual Plugin vor meinem categorytemplates Plugin gelistet war und deshalb alle Einstellungen des ct Plugins über das globale $serendipity['smarty_vars'] Array immer wieder zunichte machte.
Erst wenn ich mein DEV Plugin aufgeräumt habe werde ich allerdings wissen, ob ob es nur daran lag oder ob ich nicht doch noch etwas repariert habe.
Dann habe ich mich etwas konzentrierter dem genannten obigen "Problem" zuwenden können. Schon im Laufe der Tage wurde allerdings deutlich, dass es wohl verschiedene Wege geben würde das "Problem" anzugehen bzw zu beheben.
Jetzt sehe ich etwas klarer, wobei mir wie immer das Schreiben hilft.
Ich denke jetzt dass dies kein "Problem" einer unvollständigen "Versteckung" ist, sondern dass dies nur an der Offenheit des Systems selber liegt. Tatsächlich ist die entryspezifische Option "Nicht in Artikellisten zeigen" des entryproperties Plugins absichtlich auch nur in-so-weit gedacht, dass es die frontpage Blog Artikelliste bestimmt. Jede weitere Spezifizierung in Archive - ihre geordnete Anzahl nach Jahren und Monaten und in den Archive summaries - also über öffnende Anzeige oder als Titellisten Aufzählung zählt daher nicht als (frontpage) Artikelliste, ebensowenig wie zb auch die Kategorienanzeige des Seitenleisten categories Plugins, und ist als - sagen wir mal - Unabhängig zu betrachten.
Nun kann man da sicher unterschiedlicher Meinung sein, welche dieser Anforderungen denn eigentlich wichtiger sei, je nach Benutzung und persönlicher Erfordernis und deshalb mehr in die eine oder andere Richtung neigen. Jede weitere Festlegung innerhalb des Systems würde aber die Möglichkeiten beschränken. Je nachdem tendiere auch ich mal eher so oder andersherum. Allerdings finde ich ist der Charakter von Serendipity hier entscheidend und der heißt Offenheit.
Langer Rede, kurzer Sinn.
Ich würde also raten, da die Unterscheidung in Blog entries mit Kategorien als "Kapitel" und statische Seiten als die CMS Fähigkeit des Systems die hauptsächliche ist, und die Nachbildung einer solchen über (versteckte) Kategorien und (versteckte) Einträge nur eine Variante derselben ist, die Festlegung auf template Ebene zu versuchen.
Dies betrifft in deinem Fall die pure entries.tpl und die pure entries_summary.tpl. Beide müssten als Kopie in dein Theme um unabhängig und spezifisch zu sein. Ich glaube die entries tpl ist es ja auch schon.
In der entries_summary.tpl müsste unterhalb von
eine Zeile ( in ca Zeile 8 ) eingefügt werden, die bei Array-Durchlauf den gewünschten Eintrag mit gesetztem ep_no_frontpage also ignoriert.
Damit wäre das schon einmal erledigt.
Die Zählung der Einträge für Archive wird ja im Core vorgenommen und orientiert sich an der Gesamtzahl der Einträge die per SQL über die Herzfunktion von Serendipity - serendipity_fetchEntries() über die .._PrintEntries() - zum Archiv geliefert wird. Das können wir also nicht so leicht beinflussen. Und müssen wir meinethalben auch nicht.
Die Archive summary bzw Monats-öffnende-Artikelanzeige wird wieder über die entries.tpl ausgeführt. Darin sind zwei Durchäufe der Smarty $entries Listen, bei den wir nun etwas Ähnliches hineinpfriemeln müssen. Ebenfalls ca Zeile 8
und wenig später
Dann werden schon einmal die ep_no frontpage Blogeinträge nicht mehr angezeigt.
Kurz darüber - im header - werden die dategroups als die Tage(s)-Gruppen, zb Donnerstag, 07. Februar 2019, gebildet. Gibt es also ein(e) dategroup mit nur einem entry das ein ep_no frontpage flag besitzt, so wird die Tag Gruppen Klammer nun trotzdem angezeigt, auch wenn der eigentliche Eintrag nun weg ist. Das liegt an der Struktur der entries tpl. und ist meist nicht besser zu lösen. Also wird aus
das hier
Ich hoffe, dass die Lösung mittels {$dategroup@index} alle möglichen Fälle abdeckt, sonst müssten wir uns dafür noch etwas mehr verrenken.
Beat Post author am :
Manchmal helfen ein paar freie Tage um den Nebel im Kopf etwas zu lichten.
Grundsätzlich kann ich gut mit S9Y leben, so wie es ist. Mache Dinge packe ich vielleicht falsch an, oder zumindest nicht so, wie vom Erfinder gedacht. 😉
Lange verfolgte ich die Idee, dass nur die Startseite eine statische Seite ist und dass ich alles Andere in Form von Kategorien und Beiträgen löse. Das erste Mal strauchelte ich dann bei der "Blog-Suche", die ich nicht von der Seitenleiste (oder vom Header) in einen Blogeintrag brachte. Siehe hier: /2600-Suche-auf-statischer-Seite.html
Die Kategorienliste in einem Blogeitrag zu erstellen wäre zwar einfach gewesen, weil mir aber bewusst war, dass dies ein einziger Beitrag bleiben wird, wollte ich nicht extra eine neue Kategorie mit nur einem Beitrag eröffnen und wählte dann dafür ebenfalls die statische Seite.
Dito mit der statischen Seite "Stichworte". Zwei Jahre später hast Du mir dann dabei geholfen, dass die Tags in der statischen Seite automatisch aktualisiert werden (/2668-Styx-3.7.0-und-PHP-8.0.13.html#c8090). Also auch hier ist die statische Seite der richtige Weg.
Gestern stellte ich mir dann die (berechtigte) Frage, ob für die Menülinks Fotogalerie, Link(s) und Recht(s) nicht auch der Aufbau einer statischen Seite der richtige/bessere Weg wäre. Das sind genau die drei Kategorien, deren Beiträge ich möglichst überall verstecken wollte.
Das sind drei Kategorien, die insgesamt nur 8 Beiträge beinhalten. Und die Chance, dass in diesen Kategorien weitere Beiträge hinzukommen, ist doch sehr klein. Ich könnte also drei neue statische Seiten erstellen und diese mit dem Quellcode der 8 Beiträge befüllen. Keine grosse Sache.
Damit hätte ich alle Probleme von wegen "Blogbeiträge verstecken" gelöst (und zwar ohne irgendwelche Verrenkungen).
Ich werde nicht gleich handeln, sondern das Ganze noch etwas sacken lassen.
Vielen Dank für Deine Code-Schnipsel oben und die Mühe, die Du Dir machst. 👍
Da ich jedoch nie über ein Laien-Niveau herauskommen werde (oder werden will), möchte ich so wenige Core- oder Template-Dateien ändern, wie nur möglich. Ich weiss, dass ich mich (Jahre) später kaum mehr erinnern kann, was ich wo und weshalb geändert habe. Und bei Updates immer aufpassen zu müssen, dass ich eine Änderung verliere, ist mir auch zu mühsam. Ich habe mir schon jetzt eine Datei angelegt, welche alle "Beat-spezifischen" Änderungen dokumentiert. Das sind jetzt schon fast 10 Seiten Text.... 🤔
Ian Styx am :
Ja, da hast du völlig Recht. Sie sind allgemein besser als statische Seiten aufgehoben. Nur bei Verkaufe ist es eher berechtigt sie als Blogeinträge einer Kategorie zu implementieren. Auch die kann man über die Navigation verlinken aber/und braucht sich nicht darum zu scheren, dass sie auch in anderen Zusammenhängen angezeigt werden.
Das meinte ich mit "Unterscheidung in Blog entries mit Kategorien als "Kapitel"-artige Seperatoren und statische Seiten als die CMS Fähigkeit des Systems die hauptsächliche (ist)". Zur Möglichkeit und Offenheit des Systems gehört aber eben auch die Nutzung die du nun über so lange Zeit hinweg geflegt hast. Und es gäbe noch die dritte, oder als eine der Erweiterungen einer solchen, die mit den funktionalen Smarty Möglichkeiten.
So bleibt es spannend und herausfordernd! 🙂