Freitag, 20. Januar 2023
entrypaging und Kategorien
Habe heute in meinem Blog etwas gesucht und dabei folgende Kategorie angewählt: https://www.blog.dokumenzi.ch/categories/PC,-Blog
Wenn ich auf Seite zwei blättere, erhalte ich zwar folgende URL: https://www.blog.dokumenzi.ch/categories/PC,-Blog/P2.html doch dargestellt wird mir die diese Seite: https://www.blog.dokumenzi.ch/categories/BLOG
Wenn ich ein zweites mal blättere, erhalte ich folgende URL: https://www.blog.dokumenzi.ch/categories/PC,-Blog/P2/P2.html welche mit Sicherheit falsch ist. Angezeigt wird mir wieder die erste Blogseite.
Die Sache ist ziemlich verwirrend, denn bei einigen Kategorien (Allgemein, Fahrrad, Rikscha) funktioniert entrypaging wie gewünscht, jedoch nicht bei den Kategorien PC,-Blog und Philosophie. Zuerst dachte ich, dass es bei PC,-Blog an den Sonderzeichen liegt. Das ist jedoch unwahrscheinlich, weil es in der Kategorie Philosophie ja kein Sonderzeichen gibt.
Trackbacks
Trackback-URL für diesen EintragDieser 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/2682-entrypaging-und-Kategorien.html«
-
| Weiter: "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 Kategori […]
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Ian Styx am :
Das liegt an verschiedenen Sachen kann ich nur so auf die Schnelle sagen. Eines davon ist, dass es auch
heißt und nicht PC,-Blog wie der link auf deiner Kategorien Staticpage. Wieso ist der so?
Das andere ab Seite 2 ist ein Bug der bestimmt mit der Benutzung des Bindestriches zusammenhängt, so wie wir es schon einmal bei tags hatten, siehe https://www.blog.dokumenzi.ch/2666-Styx-3.6.4-und-PHP-8.0.11.html#c7980
Ich werde nachher einmal tüfteln, muss aber erst etwas anderes fertigmachen.
Ian Styx am :
Nee Nee, wohl doch eher als regression des Peter Phuket Pugfixing, denn sonst macht Philosophie keinen Sinn. 😀
Ian Styx am :
Und auch das stimmt sooo nicht, denn es liegt zuallererst erst einmal an dem menzianischen Gemurkse mit der weggeputzten ID (in diesem Fall für die categories Permalink Pfade). 😁
Denn fügt man die Kategorie ID hinzu, wie es eigentlich auch vorgesehen ist, zB für den Startseitenlink der Philosophie Kategorie a la "https://www.blog.dokumenzi.ch/categories/3-Philosophie", so sind alle etcPP (witzig, der Wortwitz passt) Folgeseiten auch richtig ausgeschildert. Ich habe noch nicht ganz raus wo daraufhin ein geeigneter Platz für eine kleine Hilfestellung wäre und bin auch am Zweifeln ob man Serendipity damit wirklich einen Gefallen täte... 🙄 Nicht umsonst schrieb ich:
Beat Post author am :
🙄 O.K. Hab's verstanden. 😇
Also... Habe im erweiterten Beitrag mal ein Screenshot der styx_categories Tabelle eingefügt. Wenn ich Deinem Beispiel folge, müsste ich also in der Konfiguration die Permalinks in etwa so einstellen:
Könnte ich dann auch gleich den category_name von 5-PC,-Blog auf 5-EDV umbenamsen (um die Sonderzeichen loszuwerden)?
Hat die ganze Aktion irgendwelche Auswirkungen auf bestehende Blog-Beiträge (die ja vermutlich irgendwo die Kategorie beinhalten) oder auf Permalinks die ich auf ältere Beiträge gesetzt habe?
Ian Styx am :
Nö. In der Konfiguration Permalinks diese ersten 5 hier.
archives/%id%-%title%.html
authors/%id%-%realname%
categories/%id%-%name%
feeds/categories/%id%-%name%.rss
feeds/authors/%id%-%realname%.rss
Aber das genau wolltest du ja nicht und hattest vor langer Zeit die %ID% entfernt... bzw archives/ bei den entries (was mich aber immer noch wundert das es trotzdem zu klappen scheint). Diese %XY% sind Patterns die nachher automatisch mit den echten Daten ausgetauscht werden.
Du könntest aber in der staticpage Kategorien Seite die Links mit /3-Philosophie (als Beispiel) usw. starten lassen. Ups warum geht das jetzt nicht mehr? Hast du seit Gestern etwas verändert? EDIT N° 100002.. vielleicht habe ich mich selber hereingelegt und es ging gestern auch schon nicht, bzw war schon so wie beschrieben, doch nicht singulär mit den entries der genannten Kategorie zusammengestellt. Kannst du mal bitte einen Dump der categories und entrycat Tabelle als zip mit unratbarem Namen hinterlegen, damit ich das nachstellen kann? Am besten von beatsblog, denn daher hatte und glaube ich die entries Daten damals zum testen.
Leider wirken die Permalinks Pattern auch auf die entries footer Kategorien und die Seitenleiste Kategorien Links und so manches andere. Und die kann man mal eben so nicht überschreiben ohne die Permalinks Pattern wieder korrekt zu nutzen.
Wichtig für die korrekte Auflösung einer solchen Adresse sind vor allem das WAS - in diesem Fall /categories/ und ich meine im Wesentlichen die ID (+der Bindestrich), (jedenfall bei den entries ist das Verhalten so), so dass du mit der richtigen ID auch irgendeinen Unsinn als Name dahinterschreiben könntest. ZB. /categories/3-Banane und es sich trotzdem korrekt zur Philosophie-Kategorie hin auflösen/adressieren würde/sollte. Aber irgendwie klappt das gerade nicht. Hängt da mit meinem obigen Ups zusammen? Oder erinnere ich mich falsch?
Damit meinst du den Bindestrich in "PC,-Blog" nicht wahr?! Komma und Bindestrich sind keine Sonderzeichen. Das Komma ist aber nicht immer da. Vergleiche mal auf die anderen von deinen Blogs ZB in den entries footern bei Kategorie: xyz von styx.doku. Das muss also irgendwie an deinen Einstellungen bzw Einträgen in den Kategorien liegen.... Wie man oben in deinem Screenshot sieht, hast du als Name auch "PC,-Blog" eingetragen und wolltest damit wahrscheinlich bedeuten, dass diese Kategorie sowohl PC als auch Blog beinhaltet. Was bei tags der Bindestrich, könnte hier das Komma als Ursache für etwaige (andere?) Ungereimtheiten sein, denn u.a. Kommas werden als Separatoren von (Übergabe-) Listen "?v=a,b,c,d,e" usw genutzt.
Ja, ich glaube das ginge. Aber du könntest es auch im Backend unter Kategorien anpassen.
In der gezeigten Tabelle steht bei category_description auch (etwas verwunderlich) die (falsche) Nummer mit drin. Warum wolltest du das so?
Morgen in alter Frische.
Ich muss noch David Crosby hinterhertrauern....🎸
Beat Post author am :
SCHEISSE! Jetzt habe ich auf www.beatsblog.ch herumgebastelt, anstatt hier! So ein Mist! (Ich muss auf www.beatsblog.ch die Hintergrundfarbe des Backends im Dark-Mode verändern, sonst passiert mir das bestimmt wieder einmal).
Nach etwas Basteln scheint es nun jedoch richtig zu funktionieren. 👍
Das habe ich gemacht:
Das Feld category_description ist ein alter Hut. Damit wollte ich die Reihenfolge der Darstellung im Seitenleisten-Plugin beeinflussen, weil standardmässig einfach nach Alphabet oder aufsteigender Nummer sortiert wird. Deshalb habe ich diese Nummer-Struktur (vor Urzeiten) mal eingefügt. Da ich dieses Plugin aber nicht mehr nutze, könnte ich auch all die Beschreibungen löschen.
Ian Styx am :
Super das du das wieder richtig hingebogen hast. Es funktioniert jetzt so wie es soll. 🙂 Auch wenn du dafür auf deine Blog Kategorie als allgemeine Ober-Kategorie verzichten musstest. Jetzt kannst du auch im Blog Menü Navigationslink https://www.beatsblog.ch/?frontpage hinterlegen.
Beat Post author am :
Dem ist nicht so. Im Blog werden nur die Unter-Kategorien von "14-BLOG" angezeigt. Darin nicht enthalten sind die Kategorien 13-Fotogalerie, 18-Verkauf, 19-Links und 20-Recht. Deshalb werde ich auch zukünftig ?frontpage nicht verwenden.
Ian Styx am :
Stimmt. Das wars. Ich bin auf das -14 hereingefallen. Da sie (ID) ja quasi navigatorisch und denn inneren Bezug benötigt werden, "stören" sie dennoch die Anzeige (gegenüber vorher) und so könnte man sicher mit ein wenig Smarty den Anzeigenamen, aber nicht den eigentlichen Link, bearbeiten, in dem man so etwas wie eine kleine |regex: dahinterhängt. Welche genau und Wo in welchem Fall müsstest du herausfinden, weil ich deine beat theme Struktur bzw deine Veränderungen darin nicht exakt genug erinnere oder kenne.
Beat Post author am :
Mein technisches Verständnis ist zu oberflächlich um zu verstehen, was Du damit meinst 🙄. Nun funktioniert entrypaging mit allen Kategorien richtig und somit bin ich zufrieden. An der Kleinigkeit, dass nun die URL die Kategorie-ID anzeigt und deshalb etwas weniger schön daherkommt als ohne, will ich mich nicht ärgern. (Das war vor langer Zeit der Grund, weshalb ich die Kategorie-ID's entfernte).
Beat Post author am :
Zu dem ganzen Thema noch eine abschliessende Frage: Warum wurde mir bei dem Fehlverhalten jeweils nicht eine 404-Warnung auf der Indexseite dargestellt?
Ian Styx am :
Tja gute Frage... 🤔
Ich nehme an, weil es stillschweigend in den richtigen Zweig (der Anzeige) aber eben nur mit falscher Ausschilderung abgebogen ist. 404 page errors entstehen nur, wenn die Umleitungsanweisungen (rewrites) in der .htaccess, die eine Folge der eingestellten allgemeinen Serendipity Konfigurationsanweisungen und der vorgegebenen Code Conditions sind, nicht anschlagen, oder eben so genau darin ausgeschildert sind. Die Code-Orte können an ziemlich vielen Stellen sein, deshalb meinte ich ja auch das ich noch nicht herausgefunden hätte wo exakt genau ich für diesen ungewöhnlichen Benutzungsfall eine kleine Hilfestellung hätte einbauen können.
Ian Styx am :
zb im Banner; also das h1 head und die sub... da könnte man eventuell sowas machen. Für den eigentlichen LINK und Adresse aber muss es jetzt auch so bleiben.
Du könntest aber auch https://www.beatsblog.ch/?blog oder https://www.beatsblog.ch/?beat verwenden für den Menü Blog link. Ich glaube ich habe das schon mal erwähnt.
Ian Styx am :
Ich frage einfach noch einmal nach... ™
Vielleicht musst du ( mir und dir ) auch noch einmal erklären, was eigentlich an
https://www.blog.dokumenzi.ch/categories/14-BLOG
besser ist als
https://www.beatsblog.ch/?blog
Vorallem, wenn aus diesem Startpunkt (der ja auch nur wegen der staticpage Startseite so entsteht) dann das untenstehende entr-ies-paging zusammengestrickt wird, siehe
https://www.blog.dokumenzi.ch/categories/14-BLOG/P2.html etc
gegenüber dem viel simpleren
https://www.blog.dokumenzi.ch/archives/P2.html etc.
Denn an deiner Struktur ändert es ja gar nichts - nur an der hinweisenden URL.
Oder bringt dieses /?start deine Struktur durcheinander, die ja eigentlich nur für dich selbst und deine Ordnung gilt, nicht unbedingt aber für deine Besucher, meine ich...?!
Beat Post author am :
Die grundsätzliche Idee hinter der Haupt-Kategorie "14-BLOG" ist, dass gewisse Kategorien im tagesaktuellen Blog und somit auch im entrypaging nicht vorkommen. An anderer Stelle werden diese Artikel dennoch dargestellt. Als Beispiel: Die Kategorie "20-Recht" enthält zwei Artikel vom 03.10.2019.
Zugegeben: Ich kann das gleiche Resultat erzielen, in dem ich im "Erweiterte Eigenschaften von Artikel" Plugin die Option "Nicht in Artikelübersicht zeigen" aktiviere.
Weshalb ich mich für meine Variante entschieden habe, kann ich gar nicht mehr genau sagen. (Ich fand es smart, dass ich eine ganze Kategorie einfach verschieben kann und so entscheiden, ob sie im Blog gelistet wird oder nicht). Die Anzahl von Artikeln, die im Blog oder entrypaging nicht vorkommen ist jedoch sehr überschaubar (weniger als 10 Artikel). Neue werden wohl auch nur sehr wenige hinzukommen.
Natürlich könnte ich Umbauen und diese paar wenigen Artikel editieren um im entrypaging die schönere /archives/-URL zu erhalten. Doch Hand aufs Herz: Wen interessiert diese URL?
Ich kann mir aber auch vorstellen, dass ich in Zukunft eine Kategorie einführen werde, die nur für Besucher mit S9Y-Login sichtbar ist. Das ist mit meiner Lösung auch ganz simpel zu realisieren.
Ian Styx am :
Natürlich! Danke! Ich bin ein Dummy und leider auch vergesslich und hätte selber drauf kommen können...
Im Grunde also ein staticpage behaviour ohne staticpage(s) obwohl du das ja dennoch benutzt.
https://www.blog.dokumenzi.ch/archives/C14/P16.html ist also ziemlich dasselbe und deine Version dann sogar semantischer.
Wenn ich es mal wieder vergessen sollte einfach einen Hinweis auf diesen Thread... 😃
Beat Post author am :
Ich hätte da noch eine Idee...
Im Backend unter Kategorien habe ich ganz unten den Schalter: Sollen Einträge dieser Kategorie von Eintragslisten und RSS-Feeds ausgeschlossen werden? Ja/Nein
Mit "Ja" könnte ich doch ebenfalls den von mir gewünschten Effekt, gewisse Kategorien nicht in der entry-Liste anzuzeigen, erzielen. Somit könnte ich auf die Hauptkategorie 14-BLOG verzichten. Das wiederum würde die entrypage-URL auf die von Dir angestrebte Weise (z.B.: https://www.blog.dokumenzi.ch/archives/P2.html ) bringen.
Müsste ich bei Gelegenheit mal ausprobieren.
Ian Styx am :
Durch das category_templates Plugin?
Ja vielleicht. In: Zusätzliche Einstellungen durch Plugin: Eigenschaften/Templates von Kategorien. Gute Idee! 😀
Allerdings habe ich einmal damit herumgespielt, weil ich supporten wollte, dass man einer Kategorie eines neues Kleid (theme) anziehen kann und dann unabhängig vom restlichen Blog so nebenher (wie eine Art Nebenblog) betreiben kann, so als eine Art "Statische Kategorie". Wichtig dabei war, dass sie eben aus den entries Listen des "normalen" Blogs und auch auch aus dessen feeds, comments, bzw anderen Stellen, wo Kategorien insgesamt eingeschlossen sind, herausklamüsert werden. Im Zuge dessen fand ich eine Code Stelle - erinnere ich mich - die ich nur auskommentiert aber nicht entfernt hatte, weil sie so aussah, als ob sie etwas täte was gar nicht (mehr?) supported wird.
Du müsstest es also wirklich einmal ausprobieren, damit man weiß, dass man diese Option auch für deinen Zweck benutzen kann. Das wäre also wirklich interessant. Auch vielleicht bezüglich der auskommentierten Code Stelle.
Allerdings musst du das jetzt aber gar nicht mehr, denn alles läuft seit der Permalink pattern Änderung wieder normal und damit auch innerhalb der Möglichkeiten des Systems, auch wenn das vielleicht nicht ganz im Sinne der Erfinder war.
🕵👉❄📌〰
Was mich aber wirklich stört ist das Kommentieren auf Kommentare, die irgendwo - wie gerade hier - in den Untiefen der Kommentarverschachtelung verschwunden sind ohne eine leichten, bestmöglichst klickbaren Weg zu haben zwischen dem Formfeld und dem Bezug nehmenden Kommentar hin und her zuspringen. Das muss doch irgendwie zu machen sein...... und ebenso wenn man die Vorschau sehen will.... hmm...
Beat Post author am :
Wenn Du Dir die Kommentare linear anstatt verschachtelt anzeigen lässt, ist der neuste Kommentar immer zu unterst und Du musst nicht lange suchen.
Stimmt. "Sollen Einträge dieser Kategorie von Eintragslisten und RSS-Feeds ausgeschlossen werden? Ja/Nein" wird erst durch das categorytemplates-Plugin eingebracht (welches ich eigentlich nur dazu nutze, damit ich wählen kann, ob die Einträge einer Kategorie aufsteigend oder absteigend sortiert werden sollen).
Wenn dieses Plugin nicht installiert ist, hat man unter Kategorien immer noch die Möglichkeit "Artikel von Unterkategorien verstecken?". Ich könnte also eine neue Kategorie "XX-Unsichtbar" erstellen, den Schalter auf "Ja" stellen und diejenigen Kategorien, die ich nicht in der entry-Liste anzeigen möchte als Unterkategorien definieren. Also quasi umgekehrt, wie ich es jetzt mit "14-BLOG" (=sichtbar) gemacht habe.
Ich weiss, dass nun alles funktioniert und es eigentlich keiner Änderung bedarf... Eine Verschönerung/Verbesserung/Vereinfachung (im Sinne von Styx-Konformität) könnte ich aber durchaus ins Auge fassen. 😉
Ian Styx am :
Na da schau her... 😁 Da musst du mich an sowas erinnern... Ist das deine Standardeinstellung?
Aber na klar! Dafür ist es ja auch da, ebenso dass es die Quetschung beseitigt. Witzigerweise stellt die Vorschau dann wieder um. War das schon immer so?
Ich würde aber immer zu spät daran denken weil ich mich so an die Treppe gewöhnt habe und müsste also nochmals ganz hoch um auf linear zu stellen und nachher dann vice versa, .... aber vielleicht könnte man das auch vereinfachen und im Kommentarform auch noch mal das Linear / Verschachtelt verlinken... darüber werde ich mal nachdenken..
Unsichtbar vs Sichtbar - Testen !... kann sein! Vielleicht übersieht man eine Folge...
Ich frage mich - auch bei der vorigen Idee - was einfacher und direkter für das System bzw die SQL query wäre. Jede diesbezügliche Plugin Option erweitert die Query, bzw muss im schlimmsten Fall weitere Queries nachschießen um dann mit PHP das gewünschte Resultat herauszufiltern. Besser ist - meine ich - alles was nahe am default workload ist.
Beat Post author am :
Weil mich hier dubiose DB-Probleme plagen, habe ich die Änderungen direkt im Live-Blog, auf https://www.beatsblog.ch/ durchgeführt. Und zwar:
Getestet und für gut befunden. 👍
Nun zeigt das entrypaging auf den Folgeseiten die (gewünschte) URL https://www.beatsblog.ch/archives/P2.html usw. an.
Ich denke, das ist nun so nahe wie möglich am "default".
Ian Styx am :
Mutig! 😎
Allerdings hast du jetzt das Problem das deine ehemaliger Link https://www.beatsblog.ch/categories/14-BLOG nicht mehr wirkt und eine weiße Seite ausgibt. Dem könnte man wahrscheinlich begegnen in dem man 1. den Grund in den error logs sucht, oder 2. wieder eine Kategorie mit ID 14 herstellt und in ihr kurz mitteilt das man jetzt anders arbeitet und jene nur zum Umbiegen dient, oder 3. besser in die .htaccess eine rewrite Rule für /categories/14-BLOG auf /?blog schreibt. Am besten oberhalb der s9y### Struktur damit es beim Neuschreiben nicht gleich weg ist. Wie die genau lautet müsste ich jetzt auch im WWW nachschauen, so kannst du das sicher auch. Oder du probierst es anhand der Beispiele oder schaust ins Styx Buch bei den Erklärungen zu den Rules & Commands so dass du eine Ahnung bekommst wie du es vielleicht auch ohne weiteres Wissen selber basteln kannst. Im Grunde dürfte das ganz einfach sein. 😉
Beat Post author am :
Nö... zuviel Aufwand. 😴
Diese URL gab es gerade mal 10 Tage. Die wird sich niemand gebookmarkt haben. Und wenn doch, dann wird er/sie wohl von selbst auf die Idee kommen, nur www.beatsblog.ch aufzurufen.
Beat Post author am :
Das steht im php.err.log des Servers:
Ian Styx am :
Superb! Wieder einen erschlagen! 😍
Ian Styx am :
Gesagt getan! In pure ist eine erste Experimentalversion online, siehe heutigen commit. Wollen wir das hier mal ausprobieren?
Beat Post author am :
O.K. Habe das neue commentform.tpl hier im pure-Template abgespeichert.
Ian Styx am :
Das waren aber zwei Änderungen in den Templates, im commentform und im comments.tpl. Sonst wirkt das noch nicht. Das eine als Anker auf den preview Kommentar und das andere ein Button um von da aus wieder zum Formular zu kommen um eventuell weitere Änderungen vorzunehmen zu können bzw den Vorgang abzuschießen.
Außerdem kommen dann noch eine Änderung in der functions_routing.inc für den richtigen Ankerpointer der Erfolgsmeldung und später noch in anderen Dateien für mögliche Failure Fälle hinzu, wenn ich mich da durchgewurschtelt habe.
Beat Post author am :
Ah... da gab's noch eine zweite Datei... Da hätte ich wohl etwas runterscrollen müssen 🙄😁.
Also hier wurden nun aktualisiert: commentform.tpl, comments.tpl und functions_routing.inc
Ian Styx am :
testing the comment preview and back to form linking.
Works!
😎 Much better!
Beat Post author am :
In Moment gibt es hier noch ein anderes Problem. Wenn ich ein Bild in die Mediathek hochladen will, erhalte ich folgende Fehlermeldung:
Wenn ich danach im Backend die Mediathek öffne, wird das Bild jedoch korrekt angezeigt.
PS: Scheint auch ein lokales Problem zu sein, denn auf www.beatsblog.ch funktioniert das einwandfrei.
Ian Styx am :
Hmmm... ein paar Fragen...
Ich nehme an es war ein GIF image im Original?!
Und es war groß genug, um Styx zu zwingen daraus ein Thumbnail zu machen?!
Die Meldung an sich ist eigentlich valide, denn es werden in diesem Fall tatsächlich 3 Argumente übergeben, wo nur 2 (in diesem speziellen Fall) erforderlich/erlaubt sind.
Warum taucht diese Meldung aber erst jetzt auf?
Was heißt lokales Problem vs OK auf beatsblog?
Sind es verschiedene PHP Versionen?
Sind es verschiedene GD Versionen?
Was genau unterscheidet die beiden Instanzen bzg. der Voraussetzungen und der Image Einstellungen?
Hast du genau (im Sourcecode zb) überprüft, ob das gezeigte Bild als thumb in der Mediathek tatsächlich als GIF existiert, da es per picture container ausgeliefert wird und dein Browser sich das geeignete aussucht? Ist es, falls vorhanden, tatsächlich als link kopierbar und in einem neuen Tab per Adresseintrag aufrufbar, so dass es erscheint?
Gäbe es die Möglichkeit das ich selber ein paar Experimente mit diesem GIF (im Original) anstellen kann, ... also ist es öffentlich (bzw willst du es)? (Sonst muss ich mr ein anderes suchen um das nachzustellen.)
Ich habe übrigens den vorherigen comment nochmal überarbeitet. (Es war doch schon etwas zu spät gestern.)
Beat Post author am :
Es handelt sich dabei um categories_beatsblog.jpg. Also ein JPG und kein GIF. Die Datei misst 873x1024px und benötigt 191,3kB
Auf www.beatsblog.ch werden Bilder mit ImageMagick konvertiert, hier auf www.blog.dokumenzi.ch mit GD-Lib (weil ImageMagick nicht verfügbar ist). Ansonsten sind die Konfigurationseinstellungen identisch.
PHP-Version auf www.beatsblog.ch = 8.0.25 und hier 8.0.26
Nein, Source-Code habe ich nicht überprüft. Nachdem ich hier beim Hochladen auf die Error-Page abgeworfen wurde, habe ich das gleiche Bild auf www.beatsblog.ch problemlos hochladen können. Danach habe ich hier gesehen, dass trotz des Errors das Bild korrekt in der Mediathek vorhanden ist und auch in einen Beitrag eingebunden werden kann.
Ian Styx am :
Das ist ja äußerst mysteriös..... Was geht da nur vor? Wie kann ein Bild dessen Extension Endung eindeutig .jpg lautet, ausgelesen als .gif interpretiert werden, so dass daraufhin die Funktion
augerufen wird ❓👻👻
Ian Styx am :
Ich kann das leider bei mir auch nicht nachstellen mit dem File. Alles ist so wie es sein sollte. Allerdings mit PHP 8.2.2.
categories_beatsblog.jpg
Ich habe trotzdem einen Commit gemacht der diesen valide angemeckerten ArgumentCountError verhindern sollte wenn ein echtes GIF vorbeikommen sollte. Falls du diesen geisterhaften Fehler im jetzigen Zustand tatsächlich reproduzieren kannst, wäre es sinnvoll ihn danach noch einmal mit dem Fix zu versuchen. Trotzdem müsste man herausfinden wie es überhaupt dahin kommen kann.... Mir ist es ein absolutes Rätsel.😕
Beat Post author am :
Ich vermutete, dass es sich hier wieder einmal um ein Berechtigungsproblem handelt. Habe nun jedoch die Berechtigungen der Verzeichnisse /uploads und /templates_c von hier mit www.beatsblog.ch verglichen und die sind identisch. Daran kann es also doch nicht liegen.
Der obige Fehler tritt hier nun immer auf, wenn ich ein Bild hochladen will. Was mich doch sehr irritiert, ist der Beginn der Fehlermeldung:
Was will das Programm im Verzeichnis 2013.v? Ich will das Bild ganz bestimmt nicht in ein solch altes Verzeichnis hochladen.
Beat Post author am :
Hui! Habe die neue function_images.inc.php eingespielt.Wenn ich nun ein Bild hochlade, kriege ich diese, fast endlose Fehlermeldung:
Ian Styx am :
Sieht schlimmer aus als es ist. Denn das sind ja lauter Prozessmeldungen von dem was gerade passiert. ZB. Trying to store a WebP GD image format variation in: /styx-master/uploads/2009/.v directory.
Das heißt es durchäuft als Synchronisation der Mediathek alle (und insbesondere die alten) Ordner und Medien um sie auf den aktuellen Stand bzgl webp Variation und styxThumb zu bringen. So weit, so gut!
Am Ende bzw mittendrin stellt dieser Prozess aber bei mindestens einem Image fest, dass "Paletter image not supported by webp" ist und failed mit einem Error. So weit, so gut!
Kannst du bitte mal in functions_images.inc in genau Zeile 867 unterhalb vom ini_set diese Zeile einfügen und es erneut probieren.
Ich muss - glaube ich - der Neigung zu spukhaften Glauben Abbitte leisten und bin darüber ganz froh! Ich sollte mir soetwas nicht erlauben... 😆
Beat Post author am :
Nun erhalte ich folgende Fehlermeldung:
Auf Zeile 872 steht aktuell: imagedestroy($im);
Das Bild wird dann auch nicht hochgeladen und befindet sich demnach auch nicht in der Mediathek.
Beat Post author am :
Ich frage mich echt, ob wir hier nicht ein Gespenst jagen und die Sache einfach vergessen sollten. Auf www.beatsblog.ch funktioniert ja alles einwandfrei. Ich denke schon, dass dies ein spezifischens/lokales Problem ist, welches an und für sich gar nichts mit dem Styx_Code zu tun hat.
Vielleicht sollten wir einfach den Sonntag geniessen und abwarten... Vielleicht schraubt Hosttech ja tatsächlich am Server herum und das Problem löst sich irgendwann in Luft auf.
Beat Post author am :
Das Hochladen und Einsetzen von Bildern klappt auch hier ohne Fehlermeldung:
Hosttech: https://www.styx.dokumenzi.ch/archives/29-Testbild.html
Manitu: https://styx.beatsblog.ch/2647-Testbild.html
Ich könnte ja auch einfach mal die neuste Styx-Version downloaden und über diese (fehlerhafte) Installation drüberklatschen. 🤔
Beat Post author am :
Problem gelöst! 👍
Habe eine neue Styx V4.0.1 darüberkopiert und nun funktioniert auch hier alles so, wie es soll.
Ich habe keine Ahnung, was korrupt war.
Sorry, wenn ich Dir damit Arbeit umsonst gemacht habe. 🙄
Ian Styx am :
Huch?! 🤪
Das kann aber - streng logisch - daran liegen, dass es...
Ian Styx am :
Mit genießen ist da nix .... aber es gibt was zu tun und das ist immer gut! 😀 Codehygienisch Genuß pur!
Ich habe die Fehler inzwischen auch schon festgestellt zB mit dem imgedestroy... Und das liegt daran dass PHP 8 für $im statt einer resource nun eine Instanz einer GdImage Klasse zurückgibt, gegenüber dem alten PHP 7. Wenn du also bereit für erweiterte Fixes bist, einfach den letzten Stand der functions_images nehmen.
Ich habe also schon ein paar Fehler berichtet und bereits committet. Auch das genannte Teil musste nochmal an einen besseren Platz verschoben werden. Ich bin mir aber nicht sicher ob es das wirklich schon war. Und komisch ist es mir sowieso, da ich PHP 8 schon mindestens 2 Jahre verwende und bisher nie auf diese Fehler gestossen bin.
Jetzt fängst du auch schon mit den Gespenstern an... (hihihi) 👻 - es hat sich aber immer letzten Endes als etwas herausgestellt das tatsächliche Ursachen hat. Insofern gehört Gespensterjagd einfach nur zu den natürlich versponnenen Gegebenheiten des Menschen und bringt nur den Glauben in die Wirklichkeit. 😊
Beat Post author am :
Gemacht. Bildimport funktioniert ohne Fehlermeldung. 👍
Ian Styx am :
Jupp aber noch etwas anderes nicht für die Synchronisation. Fix ist nachgereicht. Bitte folgen! 😗
Nicht wundern, ich habe mit dem 20xxxxxxxx image herumgespielt weil es keine webp Variationen hatte, bzw waren diese als 0 Kb ausgeschildert. Daraufhin stellte ich fest, dass wenn man es löscht, aber die NEIN Variante wählt, die Mediathek anschließend keinen + Button für die Neugenerierung der Varianten für dieses Einzelbild bildet.
Ist der dir überhaupt schon einmal vorgekommen, anstelle des o--o Variantenanzeige Buttons?
Oder geht das bei dir gar nicht? Dann ist das eventuell ein Bug oder hängt mit einer Condition zusammen die dein Server einfach noch nicht erfüllt. (Es kann aber auch sein dass ich das erst mit 8.1 oder 8.2 erlaubt habe ... ich weiß es einfach gerade nicht mehr.)
Daraufhin habe ich das genannte Bild erneut hochgeladen und dort wurden dann die webP Variationen korrekt gebildet. So habe ich dann die alte Version umbenannt und der Neueren anschließend wieder den Originalnamen gegeben.
Danach habe ich per Wartung die einfache Mediathek Synchro benutzt und stieß dort auf ein paar Fehler. Die sollten mit dem letzten Commit jetzt aber weg sein.
Beat Post author am :
Zuerst das Einfache: Habe die neuste Version der function_images.inc.php eingespielt. Bilder hochladen geht nach wie vor ohne Fehlermeldung.
Das mit der Ja - Nein -Variante beim Löschen eines Bildes ist mir gänzlich neu. Wobei ich auch höchst selten Bilder aus der Mediathek lösche (wieso sollte ich auch).
Habe dann das soeben hochgeladene Bild gelöscht und "Nein" gewählt. Dann habe ich jedoch keine Ahnung von welchem +Button Du sprichst und habe auch nirgends einen solchen gesehen. Habe also dann unter Wartung die Vorschaubilder erneuert und erhielt darauf folgende Fehlerpage:
Ian Styx am :
Ja genau, das war bei mir auch so. Nach dem Fix müsste sich - wenn du das richtige file mit dem richtigen commit genommen hast - zumindest auch die angemeckerte Zeile geändert haben. Insofern hast du dir wahrscheinlich nur die vorherige Version noch einmal hochgeladen. Nimm wirklich die letzte aus dem styx github file system als RAW, nicht irgendeine mit den hashes, denn da kann man leicht danebengreifen.
Ian Styx am :
Der Button der wie [o-o] oder jedenfalls so Ähnlich aussieht und mit dem man die jeweils beste Variation als Vollbild ansehen kann, rechts neben dem Mülleimer. Dieser Button wird ausgetauscht wenn man die Variationen mit dem NEIN case gelöscht hat und durch einen Plus [+] Button ersetzt, mit dem man für dieses eine spezielle image file die Variationen neu bilden lassen kann. Ein wesentlicher Fortschritt.
Ian Styx am :
Ich habe heute noch ein paar Verbesserungen eingebaut.
Zum vermissten Button:
Die einzige Bedingung für den Austausch zwischen dem Button für die Anzeige der jeweils besten full image Variation [o-o] ist, dass das Bild keine webP Variation(en) (mehr) hat.
Insofern habe ich gerade den Verdacht, dass es an fehlenden Permissions im Uploads/ Ordner für Dateien und Ordner liegt, denn das Löschen über [NEIN] soll ja (nur) die Variationen löschen, so dass diese im .v Ordner wirklich auch nicht mehr danach existieren. Wenn nun der + Button bei dir hier (Ach, wie ist es denn auf Manitu?) nicht erscheint, was er definitiv nicht macht, wie ich gerade nochmal überprüft habe, so kann eigentlich nur die Schlussfolgerung mit den Permissions auf den richtigen Weg führen.
Überpüfe das doch bitte mal zb beim letzten Bild (beat dunkelmodus) mit FTP, ob nicht doch noch das webp full file und das thumb im .v Ordner existeren. Dann müsste man an den Permissions schrauben (siehe FAQ).
Beat Post author am :
Also. Habe hier die neuste Version der function_images.inc.php eingespielt (23.01.23, 12:03).
Hier (Hosttech) wie auch auf www.beatsblog.ch (Manitu) sehe ich nun diesen o-o Button.Wenn ich die Vorschaubilder lösche, wird mir jedoch weder bei Hosttech, noch bei Manitu ein +Button angezeigt. Der o-o Button verschwindet ganz einfach. Auf beiden Installationen gibt es im entsprechenden .v-Verzeichnis keine webp-Varianten mehr.
Ich kriege nur neue Vorschaubilder, wenn ich via Wartung, Vorschaubilder erneuern gehe. Einzeln, pro Bild, habe ich keine Möglichkeit.
Auf dem Manitu-Server hat das Uploads-Verzeichnis und alle Unterverzeichnisse 770 Berechtigung und hier sogar 775. Also eher unwahrscheinlich, dass es daran liegt.
PS: Muss jetzt neue Zähne fassen. Bin erst gegen Abend wieder online.
Ian Styx am :
Autsch! To be continued! Viel Glück! 🦷🦷🦷
Wobei den [o-o] müsstest du doch schon seit Styx 3.0 gesehen haben wo es für das jeweilige Bild dann schon (webP) Variationen gab. Um den ging es also ja gar nicht, sondern nur um seine Ersetzung im Falle des Falles.
Dann werde ich mal weiter graben. Ich hätte Zahnarzt werden sollen... 😬
Beat Post author am :
Kann schon sein, dass es [o-o] schon lange gibt. Ist mir halt nie aufgefallen denn wie gesagt, ich lösche höchst selten mal ein Bild. Mir ist auch die Zwischenabfrage ob man das Bild komplett oder nur die webp-Varianten löschen will, bisher nie aufgefallen. 🙄
Und ganz ehrlich gesagt, weiss ich als 0815-Benutzer auch nicht, wozu das gut sein soll. Da interessiert mich eigentlich nur das Bild, welches ich hochgeladen habe. All die Varianten und Thumbnails sind Systemsache. Damit will ich eigentlich nichts zu tun haben. Diese Zwischenabfrage verwirrt mich mehr, als sie mir hilft. Wieso sollte ich überhaupt nur die Varianten löschen wollen? Da fällt mir echt kein Anwendungsfall ein.
Ian Styx am :
Ein Anwendungsfall wäre:
Du hast zwar WebP Variationen, aber noch keine AVIF Variationen, oder etwas ist falsch, wie zB bei dem genannten dark mode Bild. Denn dort wurde nur die full webp Variation gebildet, aber nicht das entsprechende thumb, sagt jedenfalls die info. Da liegt eindeutig irgendwo ein Fehler vor. Am Bild selbst kann es nicht liegen denn das habe ich bei mir lokal schon überprüft.
Und ebenso:
Der Plus Button sollte immer dann erscheinen, wenn ein Bild noch keine Variationen hat, kein externes hotfile ist und nicht selbst ein webp/avif image ist (siehe 3.9.0 changelog).
Der [o-o] Button hat auch nur soweit einen Bezug zum Löschen - insbesondere in der NEIN Variante - als er dann ausgetauscht wird. Sonst ist er immer da um sich das fullfile in der bestmöglichen Variation selbst anzeigen zu lasssen. Denn klickst du nur auf das dargestellte thumbnail Bild, dann bekommst du zwar auch die Preview des full size Bildes, aber das nur als Picture Container, bei dem du nicht sofort weißt was dein Browser dir davon darzustellen beliebt.
Ach ja ich weiß, es sind Details,
sind weder schwarz, noch sind sie weiß!
😉
Bist du jetzt verarztet und wieder schön? 🦷
Beat Post author am :
Einfach noch zur Information. Auch auf den zwei anderen Test-Blogs (https://styx.beatsblog.ch/ und https://www.styx.dokumenzi.ch/) erscheint kein +Button, nachdem ich die webp-Varianten gelöscht habe. Das Verhalten ist zumindest bei mir, auf allen vier Styx-Installationen, gleich.
Ian Styx am :
HEUREKA!
Es hat ein wenig gedauert, doch nun habe ich den Schlawiner. Wenn du es ausprobieren willst einfach die templates/default/admin/media_items tpl Datei in der letzten Fassung kopieren und raufladen. 😀
Ich konnte es nicht fassen warum das bei mir überall ging, aber es war ganz einfach und hing ab von der on-the-fly sync Option in der Image Konfiguration.
Beat Post author am :
Strike! Da ist ja nun der +Button!
Ian Styx am :
Das wiederum passt zu dem Spukhaften in dieser ganzen Sache. Wenn du gar nicht in einen 2013 Ordner hochlädst ist das, bzw kann das nur auf ein Geisterbild, also einen misslungenen Cache o.Ä. hindeuten. Ebenso gif statt jpg. Wie auch immer der intern zustande kommt. So ein Cache wie der von NGINX - und den ich dafür verantwortlich hielte - ist an sich ja eine tolle Sache, da er Dinge erheblich beschleunigen kann. Bei dynamisch generierten Seiten ist es für mich aber sowieso ein Rätsel wie so ein Dopplereffekt effektiv arbeiten kann, denn dynamisch generiert heißt ja dass praktisch mit jeder Tätigkeit (besonders bei Backendarbeiten) etwas neues geordert oder verändert wird. Dem müsste ein solches Abbild folgen. Tut es aber nicht immer, wie man schon bei den versteckten Captchas etc und zb in diesem Fall bemerken kann.
Also haben sie auf dem Server vielleicht gerade mit etwas herumexperimentiert, denn sonst hätte das Phänomen ja auch schon vorher auftauchen müssen. Mehr gibt meine Glaskugel auch nicht her im Moment.
Die Meldung "Trying to store ..." ist eine der Meldungen von Styx in den Endläufigkeiten des Upload-Prozesses, die aber nicht hinweist auf den Ort wo der eigentliche ArgumentCountError entsteht. Der entsteht aber weil er anscheinend mit "geisterhaften ‘Betrugs’daten" gefüttert wird, die nichts mit deiner eigentlichen Aktion und ihrer Bearbeitung zu tun haben.
Gibt es denn im uploads Ordner einen 2013 Ordner der ein Gif Bild enthält und ist dies eventuell beschädigt und hat vielleicht kein eigenes Thumb bzw webp Variation im .v Ordner desselben? Dann könnte es vielleicht sein, dass hier ein Unterprozess in der Mediathek Synchronisation stattfindet, der, in irgendeiner Weise, die wir auch noch herausfinden müssten, dafür sorgt, dass eine Neugenerierung stattfindet. Dann aber müsste mein gestriger Commit schon greifen. 🤨
Oh Gott oh Gott während ich mich Mühe dies zusammenzuschreiben sehe ich dein Folgepost.... dazu dann gleich mehr.
Ian Styx am :
Folge von Kommentar
https://www.blog.dokumenzi.ch/2682-entrypaging-und-Kategorien.html#c8284 und als
Abschluss von https://www.blog.dokumenzi.ch/2682-entrypaging-und-Kategorien.html#c8249
Nachtrag:
Dieser Fund - das die permanente Mediensynchronisation eingeschaltet war/ist - bestätigt auch alle bisherigen "und so geisterhaft daherkommenden" Merkwürdigkeiten und liefert einen sehr logisch erklärbaren Grund für ihr Auftreten.
Zur Info:
Auto-Synchronisation der Mediathek Falls diese Option aktiviert ist, wird Serendipity den Inhalt der Mediendatenbank mit dem echten Inhalt im Dateisystem abgleichen und überwachen. Dies ist - gerade durch die zusätzlichen Variationsformate - ein eher zeitraubendes Monitoring Instrument und kann eine anwachsende Mediathek zunehmend stärker ausbremsen. da jeder Aufruf derselben permanent alle(!) Dateien durchlaufen, überprüfen und neu bewerten muss, inklusive der sich dadurch ergebenden notwendigen Veränderungen. Da letzteres dadurch aber entsprechend oft geschieht, wird dieser Schritt dafür auch entsprechend kürzer. Ansonsten nutzen Sie ab und an die beiden ersten Mediatheks Vorschaubild Aktionen in der Wartung, die ebenfalls eine abschließende Synchronisation beinhalten! Ein "Ja" ist hier also zu empfehlen, wenn Sie entweder selbst oft direkt im Dateisystem der Mediathek herumarbeiten, diese Option nur temporär nutzen oder keine Verlangsamung feststellen, oder ein Developer/Tester mit entsprechend vielen false/positives Ergebnissen sind.
Solltest du also weder das eine oder Andere sein, ist diese Option also besser auf Nein zu stellen.
Beat Post author am :
Ich mag "sowohl als auch" 😉
Hier bin ich Tester und deshalb ist die Auto-Synchronisation der Mediathek EINgeschaltet.
Im Live-Blog (www.beatsblog.ch) dauerte der Aufruf der Mediathek bei eingeschalteter Auto-Synchronisation ca. 45 Sekunden (bei ca. 4'200 vorhandenen Bildern (mit Thumbnails und mehreren webp-Varianten weit über 10'000 Dateien). Dort habe ich die Auto-Synchronisation der Mediathek nun AUSgeschaltet. Der Aufruf der Mediathek dauert jetzt ca. 1 Sekunde. 👍