[Solved] Problem beim Cache mit der Pagination

[moonchild]

Hallo zusammen,
ich habe ein merkwürdiges Problem bei der Verwendung des S9Y Cache mit der Pagination (Seite vorwärts / Rückwärts, Sprung auf eine Seite im Blog von Seite 1 bis zum Ende) festgestellt. Sobald ich den Cache des Plugins serendipity_event_entryproperties aktiviere, funktioniert alles, auch die Links auf die Kategorien, auf Tags usw.

Deaktiviere ich diesen Cache und verwende den aus Konfigurationsmenü / Generelles, ist die Pagination sowie die Links etc. futsch und die Reihenfolge in der Artikelübersicht stimmt nicht mehr. Ich habe bisher:

- .htaccess gelöscht, neu angelegt. Diverse URL Rewritings probiert. Aktiv ist apache mod_rewrite
- das Permalink Plugin auf die aktuellste Version 1.17 upgedatet. Hintergrund "The requested page could not be found (404)" ist hier behandelt. Dieses Problem ist durch das Update gelöst.
- das Verzeichnis templates_c geleert
- diverse Themes probiert. 2k11, Timeline, (aktiv ist: Bulletproof v1.4 fork)
- Option für das stabile Archiv ein / ausgeschaltet. Zur Zeit sind sie abgeschaltet.
- die Plugins Freie Tags, Karma deaktiviert
- Datenbank optimiert

Alles jeweils in Kombination zigfach ausprobiert - keine Änderung des Cacheverhaltens.

Es sollten eigentlich - je nach Wahl - beide Caching Möglichkeiten funktionieren, wobei die aus dem Konfugurationsmenü wesentlich schneller ist und auch mit weniger Serverlast arbeitet und daher für mich wichtig ist. Jedoch werden hier die einzelnen Beiträge in einer willkürlichen Reihenfolge angezeigt und die Pagination ist weg. In der Seitenübersicht taucht momentan ein Beitrag vom 15. April 2017 als erster Beitrag auf. Es fehlen die davor und nach dem 15. April veröffentlichten Beiträge...

Ich komme nicht mehr weiter und bräuchte Hilfe. Dankeschön im Voraus.

Bei mir läuft Serendipity 2.1.1 und PHP 5.6.30. Die Verwendung von PHP 7.0.15 bringt ebenfalls keine Änderung des Problems.

[onli]

Danke für die ausführliche Beschreibung. Da hat was bei mir Klick gemacht. Stellt sich raus: Da ist ein Bug im Cache-Code, die Footer-Erstellung kann nicht funktionieren. Denn serendipity_printEntries ruft serendipity_getTotalEntries auf, und das braucht die gesetzte Variable $serendipity['fullCountQuery'], die in serendipity_fetchEntries nur dann gesetzt wird wenn der Cache leer war.

Das heißt aber auch, dass er in den anderen Blogs - meinem z.B - nicht oder nicht vollständig cached. Denn dort wird trotz des Bugs der Footer ja erstellt - und zwar, weil ein anderer Bug, der scheinbar in deiner Konfiguration *nicht* auftritt, die cache-key Berechnung kaputtmacht. Die Einträge im Cache werden dann nicht gefunden.

[onli]

Ein erster Patch ist in https://github.com/s9y/Serendipity/comm ... 47d1dbf340. Er funktioniert in meinem Entwicklungsblog, aber wäre toll, wenn du ihn testen könntest!


PS:

Bei mir läuft Serendipity 2.1.1 und PHP 5.6.30. Die Verwendung von PHP 7.0.15 bringt ebenfalls keine Änderung des Problems.

Du solltest schon aus Performancegründen auf PHP 7 umstellen.

[moonchild]

Hallo Onli,
Danke für die Mühe, ich habe die gepatchte Datei eben hochgeladen, leider ändert das nichts: Ich habe Cachen via Konfiguration / Generelle Einstellungen deaktiviert, Deinen Patch hochgeladen, das Cacheverzeichnis geleert und das Caching wieder aktiviert.

Ich bin noch auf PHP 5.6.30, weil eine andere Anwendung mit PHP 7x nicht läuft. Ich habe aber eben nochmal PHP 7 aktiviert und den Server neu gestartet. Ich habe auch nochmals einen Wechsel des Themes probiert und den Rest der Prozedur.

Es bleibt dabei: Caching an: Linkstruktur im Eimer. Caching aus: Alles ok, dafür kippt der Server beinahe aus den Latschen

Ahh, ich sehe gerade auf github, dass Garvin meint, da seien noch ein paar Variablen. Ich stehe für weitere Tests gerne zur Verfügung.

Ein erster Patch ist in https://github.com/s9y/Serendipity/comm ... 47d1dbf340. Er funktioniert in meinem Entwicklungsblog, aber wäre toll, wenn du ihn testen könntest!


PS:

Bei mir läuft Serendipity 2.1.1 und PHP 5.6.30. Die Verwendung von PHP 7.0.15 bringt ebenfalls keine Änderung des Problems.

Du solltest schon aus Performancegründen auf PHP 7 umstellen.

[onli]

Ist bei dir der Cache derzeit aus? Weil ich sehe nun zumindest die Navigation wieder. Und die sollte mit dem Patch da sein :/

Garvin hat gerade kommentiert, dass da noch ein paar weitere globale Variabeln die Funktion beeinflussen. Du wirst bald einen zweiten Patch testen dürfen :)

[moonchild]

Hallo Onli,
Cache ist an. Die Navigation steht, Kategorien, Einstieg direkt über die Hauptseite usw. nicht, d.h. da kommen Beiträge sonstwie sortiert. Ich warte also auf den Patch Nr. 2

Ich würde dann auf Ansage auch die Tags zuschalten, damit das auch behoben werden kann.

Ist bei dir der Cache derzeit aus? Weil ich sehe nun zumindest die Navigation wieder. Und die sollte mit dem Patch da sein :/

Garvin hat gerade kommentiert, dass da noch ein paar weitere globale Variabeln die Funktion beeinflussen. Du wirst bald einen zweiten Patch testen dürfen

[onli]

https://github.com/s9y/Serendipity/comm ... e7c64618d5 ist der nächste Patch. Ich glaube, diesmal alle globalen Variables erwischt zu haben. Zumindest sollte dieser Patch die Bugs deutlich reduzieren.

Vergiss bitte nicht, nach dem Einspielen des Patches einen Artikel zu speichern, um den Cache zurückzusetzen.

[onli]

Sprachs und fand einen Bug...

Der Cache hat zwei Ebenen, einmal den für die Funktion, der die Datenbank anspricht, und einmal für die Funktion, die danach daraus das HTML baut. Den Cache für letztere habe ich jetzt erstmal entfernt, nachdem ich gesehen habe, dass das problematisch ist als anfangs gedacht. So können wir uns erstmal auf den Cache für die Datenbankfunktion konzentrieren und dann später schauen, ob der zweite Cache noch etwas bringt wenn der erste jetzt richtig funktioniert.

Das sind https://github.com/s9y/Serendipity/comm ... 52ffb8f1a9 und https://github.com/s9y/Serendipity/comm ... 330731f9d8.

[moonchild]

Hallo Onli,
Danke, ich habe die beiden Dateien hochgeladen. Es scheint so, als würde fast alles funktionieren, bis auf das Plugin serendipity_event_freetag: Im Eintragsfuß werden die gesetzten Tags angezeigt, beim Anklicken wird jedoch die Startseite unterhalb der Tagwolke im Browser angezeigt, obwohl in der Adresszeile der Link zum Tag angezeigt wird. Hier ein Beispiel: Der Tag "Baskenland" ruft alles mögliche auf, auch Beiträge die damit nicht getaggt sind...

Sprachs und fand einen Bug...

Der Cache hat zwei Ebenen, einmal den für die Funktion, der die Datenbank anspricht, und einmal für die Funktion, die danach daraus das HTML baut. Den Cache für letztere habe ich jetzt erstmal entfernt, nachdem ich gesehen habe, dass das problematisch ist als anfangs gedacht. So können wir uns erstmal auf den Cache für die Datenbankfunktion konzentrieren und dann später schauen, ob der zweite Cache noch etwas bringt wenn der erste jetzt richtig funktioniert.

Das sind https://github.com/s9y/Serendipity/comm ... 52ffb8f1a9 und https://github.com/s9y/Serendipity/comm ... 330731f9d8.

[onli]

Gut, immerhin :)

Die Inkompatibilität mit dem Freetag-Plugin ist leider unschön, es verzahnt alles miteinander, setzt Variablen bei der Datenbankabfrage und fiddet sie dann nicht, wenn die Datenbankabfrage nicht stattfand. https://github.com/s9y/Serendipity/comm ... c44bb072e2 ist ein erster Workaround. Teste den doch bitte auch noch.

[moonchild]

Hallo Onli,
soeben getestet und für passend gefunden. Puhhh...

Pagination, Kategorien und Trackbacks laufen korrekt mit eingeschaltetem Cache. Ich werde das jetzt mal eine Weile beobachten und testen. Dankeschön!

Wenn wir schon dabei sind: Soll ich sonst noch ein Plugin zum weiter testen installieren?

Gut, immerhin

Die Inkompatibilität mit dem Freetag-Plugin ist leider unschön, es verzahnt alles miteinander, setzt Variablen bei der Datenbankabfrage und fiddet sie dann nicht, wenn die Datenbankabfrage nicht stattfand. https://github.com/s9y/Serendipity/comm ... c44bb072e2 ist ein erster Workaround. Teste den doch bitte auch noch.

[onli]

Zum Testen des Caches? Weil wir haben eine Liste mit Plugins die generell Tests bräuchten, https://github.com/s9y/Serendipity/wiki ... ze-Plugins ;)

Für den Cache selbst sind vor allem die Plugins wichtig, die Einträge beeinflussen oder neue Seiten anlegen. Das Konktaktformular, Freetags, statische Seiten, das sind die drei die mir dazu einfallen. Normale Nutzung des Blogs und weiterhin melden, wenn etwas nicht klappt, das reicht.

Danke nochmal übrigens. Ist ein bisschen schade, dass es jetzt im 2.1 Release nicht sauber funktioniert hat, aber diese Debugging-Session war super wichtig für den Cache als Feature in den kommenden Versionen.

[thh]

Ist ein bisschen schade, dass es jetzt im 2.1 Release nicht sauber funktioniert hat, aber diese Debugging-Session war super wichtig für den Cache als Feature in den kommenden Versionen.

Release early, release often.

Für 2.1 gab's ja erhebliche Änderungen an verschiedenen, durchaus zentralen Bereichen; insofern halte ich es nicht für besonders schlimm, wenn dann eben in kürzerer Folge Patch-Releases erscheinen, die die Fehler beheben.

Und je kleiner die Community, desto geringer die Wahrscheinlichkeit, dass Release Candidates wirklich intensiv getestet werden. Dann ist der finale Test eben das Release ...

[moonchild]

Hallo Onli,
wird eigentlich das Backend auch gecachet? Mir ist aufgefallen, dass es dort ziemlich zäh zugeht. Und im Editor ist mir jetzt bei einigen Testbeiträgen, die ich danach wieder gelöscht habe, aufgefallen, dass die trotzdem noch vorhanden sind, obwohl s9y behauptete, dass die Beiträge gelöscht wurden.

Mehrfach ist auch Text im Editor von älteren, existierenden Beiträgen, jedoch ohne Überschriften, Tags und Kategorien aufgetaucht. Ich habe den Text gelöscht und irgendwas anderes rein geschrieben, um zu sehen, ob das Auswirkungen auf den älteren Beitrag hat - dem ist nichts passiert.

Ich kann das nicht wirklich reproduzieren, ich habe den Browsercache jeweils gelöscht und Chrome sowie Firefox getestet. Trat bei beiden Browsern auf.

Hier ein Screenshot von so einem Textzombie:



Ich glaube für die Tags wäre ein neuer Thread sinnvoll, oder?

Zum Testen des Caches? Weil wir haben eine Liste mit Plugins die generell Tests bräuchten, https://github.com/s9y/Serendipity/wiki ... ze-Plugins

Für den Cache selbst sind vor allem die Plugins wichtig, die Einträge beeinflussen oder neue Seiten anlegen. Das Konktaktformular, Freetags, statische Seiten, das sind die drei die mir dazu einfallen. Normale Nutzung des Blogs und weiterhin melden, wenn etwas nicht klappt, das reicht.

Danke nochmal übrigens. Ist ein bisschen schade, dass es jetzt im 2.1 Release nicht sauber funktioniert hat, aber diese Debugging-Session war super wichtig für den Cache als Feature in den kommenden Versionen.

[onli]

wird eigentlich das Backend auch gecachet?

Der Cache greift bei der Abfrage von Einträgen. Einträge bearbeiten, da wird das helfen, ansonsten nicht. Smarty hat einen eigenen Cache, der ist auch an, soweit ich weiß.

Generell sollte das Backend eher schnell sein. Ich mein, Serendipity läuft bei mir auf einem schwächlichen ARM-Server (Quad core, aber schwache Kerne) und hat ziemlich gute Ladezeiten Frontend und Backend. Natürlich verbesserbar, aber nicht zäh.

Mehrfach ist auch Text im Editor von älteren, existierenden Beiträgen, jedoch ohne Überschriften, Tags und Kategorien aufgetaucht.

Das ist der Editor-Cache, der läuft lokal über deinen Browser. Er wird gelöscht, wenn ein Eitnrag abgesendet wurde. Wenn du also anfängst zu schreiben und dann auf einen anderen Menüpunkt klickst udn dann wieder zurück gehst, dann wirst du den alten Text im Editor sehen. Wir sollten das besser erklären.

bei einigen Testbeiträgen, die ich danach wieder gelöscht habe, aufgefallen, dass die trotzdem noch vorhanden sind

Kannst du das genauer erklären? Wo löschst du die, wo sind sie noch da? Gerne in einem eigenen Thread, ja.

Für 2.1 gab's ja erhebliche Änderungen an verschiedenen, durchaus zentralen Bereichen; insofern halte ich es nicht für besonders schlimm, wenn dann eben in kürzerer Folge Patch-Releases erscheinen, die die Fehler beheben.

Stimmt schon. Allerdings haben wir im neuen master direkt auch die experimentelleren Features angepackt bzw anpacken wollen. Da müssten wir die Patches wieder herausziehen, wenn wir ein schnelleres Patch-Release mahcen wollen.

Beim Cache ist besonders, dass das ja explizit getestet wurde, auch in Praxis. Aber da hat der eine Bug den anderen verdeckt, schien ja alles zu laufen .