[Solved] Problem beim Cache mit der Pagination

Hier können Probleme und alles andere in Deutscher Sprache gelöst werden.
moonchild
Regular
Posts: 201
Joined: Mon Nov 21, 2005 11:23 pm
Location: Esslingen
Contact:

Re: Problem beim Cache mit der Pagination

Post by moonchild »

Hallo Onli,
ok, Danke nochmal für die Erläuterung. Nach dem Leeren des Browsercaches tauchten die Textteile nicht mehr auf, daher ist das auch erledigt, auch tauchen die gelöschten Beiträge in der Artikelübersicht (Einträge bearbeiten) nicht mehr auf. 8)

Das Backend ist jedoch immer noch langsamer im Vergleich zum Frontend. Grob mit der Uhr gemessen 6 Sekunden vom Anklicken eines Buttons (Statische Seiten) im Backend bis zum Aufbau der Seite. Bei der Pluginübersicht ist das bspw. ebenso, wobei das Umschalten zwischen den Event- zu den Seitenleistenplugins augenblicklich passiert. Komisch. So lange dauert der Aufbau des Frontends ohne Cache auch, deshalb hatte ich gefragt. Aber ich kann damit leben. Wenn dazu nichts mehr kommt würde ich den Thread dann als SOLVED markieren und mich den Plugins zuwenden, die getestet werden sollen.
onli wrote:
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 .
thh
Regular
Posts: 419
Joined: Thu Oct 26, 2006 2:38 pm
Location: Stuttgart, Germany
Contact:

Re: Problem beim Cache mit der Pagination

Post by thh »

onli wrote:
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 machen wollen.
Machen wir das nicht sowieso so? Falls nicht, wäre das eigentlich eine gute Idee, damit Bugfixes (oder minimale neue Features) nicht erst viele, viele Monate später bei der nächsten Minor- oder gar Major-Version released werden.
onli
Regular
Posts: 2825
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [Solved] Problem beim Cache mit der Pagination

Post by onli »

Nein, eigentlich backporten wir nur sicherheitsrelevante Änderungen. 2.0, das lief im eigenen Branch und etwas parallel, weil absehbar war das es lange dauern würde (und Github war ja auch neu für uns). Wäre eigentlich auch ideal wenn wir stattdessen die echte neue Version schneller stabil kriegen.
thh
Regular
Posts: 419
Joined: Thu Oct 26, 2006 2:38 pm
Location: Stuttgart, Germany
Contact:

Re: [Solved] Problem beim Cache mit der Pagination

Post by thh »

onli wrote:Nein, eigentlich backporten wir nur sicherheitsrelevante Änderungen. 2.0, das lief im eigenen Branch und etwas parallel, weil absehbar war das es lange dauern würde (und Github war ja auch neu für uns). Wäre eigentlich auch ideal wenn wir stattdessen die echte neue Version schneller stabil kriegen.
Naja, bei 2.1 war das ähnlich: die 2.0.x-Versionen haben viele kleine Änderungen nicht mitbekommen, obwohl die "non-breaking" waren und teilweise seit vielen Monaten eingecheckt waren. Von 2.0.0 bis 2.1 waren es auch zweieinviertel Jahre ... :-)

Ich will das auch gar nicht kritisieren, sondern nur diskutieren.

Aus meiner Sicht wäre es sinnvoll, auch die Entwicklung mehrgleisig zu fahren. Wir haben ja die Issues ebenfalls in patch/minor/major geordnet. Dementsprechend sollten Bugfixes - durchaus zeitnah, jedenfalls regelmäßig - für 2.1.x releast werden; wenn man will, durchaus auch kleine, isolierte, unproblematische Features. Daneben kann die Entwicklung für 2.2 laufen, ggf. auch von 2.3, und ggf. die von 3.x (in der Theorie, jedenfalls).

Wir haben ja auch verschiedene Branches, nutzen die aber nicht konsequent: im Branch 2.1 (das wäre eigentlich der Maintenance-Branch für 2.1.x) haben wir (nochmal in einem gesonderten Branch) "Experimental utf8mb4 migration preparations", was wenig Sinn macht, denn das ist ja ganz sicher (mindestens) 2.2. Dafür landen Bugfixes im Master-Branch.

Ich hielte es für sinnvoll, Bugfixes und unproblematische kleine Changes nach 2.1 zu backporten; das ist in der einfachsten Variante ja nicht mehr als ein "cherry-pick" der entsprechenden Commits. Wir könnten dann - auch in kürzeren Abständen als bisher - Patch-Releases machen, wenn sich einige störende Fehler eingefunden haben oder sobald etwas Sicherheitsrelevantes vorbeikommt.

Kandidaten für Bugfixes wären bspw. der Fix für Akismet, der für die Kommentarvorschau oder auch der geänderte Spartacus-Default. Das ist alles kein Beinbruch, aber möglicherweise noch ein Viertel-, halbes oder auch ganzes Jahr ein Release auszuliefern, bei dem u.a. der Default für das Plugin-Management nicht tut, ist potentiell frustrierend für Nutzer. Noch blöder ist's, wenn zwischendurch sicherheitsrelevante Fehler behoben werden und daher möglicherweise zwei oder drei Patch-Releases später diese Bugs immer noch drin sind.

Klar - wenn 2.1 im Mai oder Juni erscheint, ist das egal, aber das ist ja nicht sicher (kleiner Entwicklerkreis mit engem Zeitbudget), und warum sollten wir uns für die größeren Änderungen unnötig unter Druck setzen lassen? Wenn 2.1 erst zum Jahresende oder in 2018 kommt, wäre es halt einfach unschön, wenn wir 9, 12 oder 15 Monate unnötig ein Release mit kleinen, aber störenden Bugs ausliefern oder ständig auf "da muss man nur eine Zeile ändern, schau Dir ... an" verweisen.

Just my 2 cents. :)
onli
Regular
Posts: 2825
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [Solved] Problem beim Cache mit der Pagination

Post by onli »

Spartacus muss auf jeden Fall auch in der 2.1 gefixt werden. Da ist aber, glaube ich, gerade Garvin auch hinterher, netmirror und s9y.org wieder zum Laufen zu kriegen.
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: [Solved] Problem beim Cache mit der Pagination

Post by yellowled »

thh wrote:Aus meiner Sicht wäre es sinnvoll, auch die Entwicklung mehrgleisig zu fahren.
„Sinnvoll“ ist (leider) nicht unbedingt „manageable“. Garvin als „Releasemanager“ müsste dazu selbst etwas sagen, aber soweit ich es erinnere ist diese Vorgehensweise auch der Verwaltbarkeit (stabiler, produktiv nutzbarer) Releases geschuldet. So können neue Features besser und länger getestet werden.

Auch ich möchte das gar nicht werten, aber ich bin über diese Philosophie auch schon ein paar Mal gestolpert und habe Dinge in den „Minor-Branch“ geholt, die gar keine echten Bugfixes waren, weil ich es anders gewöhnt bin.

Das soll aber wirklich weder ein pro noch ein contra sein – ich kann das Argument „Wir müssen jederzeit in der Lage sein, mit wenig Aufwand einen Patchrelease zu machen“ nachvollziehen. Zumal niemand Garvin beim Release wohl auch nur Teile abnehmen kann.
thh wrote:Dementsprechend sollten Bugfixes - durchaus zeitnah, jedenfalls regelmäßig - für 2.1.x releast werden; wenn man will, durchaus auch kleine, isolierte, unproblematische Features.
Ganz streng formuliert sind Features keine Bugfixes. :wink:

YL
Post Reply