Plugin calendar_xh und PHP 8 - fataler Fehler

[cmb]

ob_start , exit... in php gelöst worden ist, habe ich auch nur deinen Kalender in meiner Ausgabe statt die ganze html Seite.
Ich habe nach einer Lösung gesucht, doch ich habe noch keine gefunden. Denn beim Plugin News habe ich das gleiche Problem und andere Plugins oder Erweiterungen vielleicht auch.
Hast Du auf die schnelle eine Lösung? - geht mir nicht darum das man 2 verschiedene Kalender auf einer Seite haben muss, das wäre Blödsinn, nee mehr ums Prinzip. (bei OnePage sind dann alle auf einer Seite - da wird's dann kriminell)

Bei Antworten auf Ajax-Anfragen, ist das Zurücksetzen vorhandener Ausgabepuffer wichtig (zumindest falls das Plugin im Template aufgerufen wird). Allerdings sollte mein Calender hier nicht den Chef markieren, und grundsätzlich alle HTTP_X_REQUESTED_WITH beantworten; da müsste ich nachbessern (vermutlich einen zusätzlichen GET-Parameter mitgeben, und auf diesen, statt auf HTTP_X_REQUESTED_WITH reagieren). Das betrifft vermutlich auch ein paar andere Plugins von mir. Ich schau mir das nachher mal genauer an.

[knollsen]

...Allerdings sollte mein Calender hier nicht den Chef markieren...

Ich hab auch im aktuellen Download die GET-Parameter auf deutsch geändert, so das gerade diese gebräuchlichen $month, $year nicht auch noch in die Quere spucken. "exit" ist halt auch nicht ohne ...
Trotzdem vielen Dank! - so hatte ich wieder was dazu gelernt.

[cmb]

Ich hab auch im aktuellen Download die GET-Parameter auf deutsch geändert, so das gerade diese gebräuchlichen $month, $year nicht auch noch in die Quere spucken.

Ja, diese Namen stören mich schon lange; kurz ist schön, aber es könnte Probleme geben, wenn ein anderes Plugin auch diese Namen verwendet (betrifft ja nicht unbedingt nur Calendar-Forks).

"exit" ist halt auch nicht ohne ...

Muss aber oft sein, denn sonst hängt CMSimple_XH noch die ganze aufgerufene Seite an die Antwort, und die müsste man dann Clientseitig wieder entfernen.

Trotzdem vielen Dank! - so hatte ich wieder was dazu gelernt.

Ich auch! Ich dachte damals wirklich es sei clever einfach HTTP_X_REQUESTED_WITH zu prüfen, weil ich mir so einen zusätzlichen GET-Parameter sparen kann. Dabei scheint sich der Aufwand in Grenzen zu halten. Kannst ja mal ausprobieren, wenn du magst (da hat sich einiges geändert im Vergleich zu 2.2, aber ich glaube nur wenig oder gar nichts im JS, und die andere Stelle findet sich leicht).

[knollsen]

PERFEKT!
So geht's doch, auch wenn calendar2.x nicht der Chef ist ... Danke!

[cmb]

Danke fürs Testen! Also gibt es nun Calendar_XH 2.3 wo dieser (und ein anderer) Fehler behoben sein sollten.

Bezüglich Calendar 2.3 gehts in einem anderen Thread weiter.

[cmb]

So, nun gibt es auch Calendar 1.4.11 mit weiteren Bugfixes.

[cmb]

Ich finde calendar 1.4 ist schon ein mächtiges Plugin. Wäre schön wenn es erhalten und weiterhin nutzbar wäre.

Ja, ich wäre auch froh, wenn das Plugin weiter erhalten bleibt.

Während der Umstellung auf PHP8 habe ich aus der Not heraus übergangsweise mit den beiden "Forks" (2.2 bzw 1.7) gespielt, aber ich bin froh nun wieder 1.4 nutzen zu können.

Wird aber langfristig gesehen schwierig. Der Code ist schon ziemlich in die Jahre gekommen, und meine Versuche statische Analyse anzuwenden, sind kläglich gescheitert (automatisierte Entwicklertests sind erst recht nicht machbar). Und da PHP immer strikter wird, wird es da früher oder später mächtige Probleme geben. Und die Zeit ist immer knapp; die investiere ich lieber in meinen Calendar_XH. Wenn ihr da konkrete Verbesserungsvorschläge habt, dann bitte raus damit.

Ich auch! Ich dachte damals wirklich es sei clever einfach HTTP_X_REQUESTED_WITH zu prüfen, weil ich mir so einen zusätzlichen GET-Parameter sparen kann. Dabei scheint sich der Aufwand in Grenzen zu halten. Kannst ja mal ausprobieren, wenn du magst (da hat sich einiges geändert im Vergleich zu 2.2, aber ich glaube nur wenig oder gar nichts im JS, und die andere Stelle findet sich leicht).

Ich habe mir das gerade noch mal im Kontext von Twocents_XH angeschaut, und die Lösung mit dem zusätzlichen GET Parameter gefällt mir gar nicht. Zum einen muss dieser serverseitig an den richtigen Stellen wieder entfernt werden, weil es sonst ellenlange Query-Strings gibt ("&calendar_ajax&calendar_ajax&calendar_ajax"), und grundsätzlich taucht der Parameter eben in der URL auf (wird mir sogar in der Addressleiste des Browsers angezeigt), was auch nicht wirklich schön ist (ein Crawler könnte so Duplicate Content feststellen).

Die saubere Lösung ist wahrscheinlich bei "X-Requested-With: XMLHttpRequest" zu bleiben, aber beim Senden eines XHR (sollte heutzutage wohl die Fetch API nutzen) werden dann "einfach" nicht erwünschte Parameter entfernt (ist im Backend vielleicht nicht so einfach). Bei Twocents_XH so. Wenn sich jeder daran hält, dann klappt's auch mit dem Nachbarn.

Ist halt doof, weil so andere Plugins angepasst werden müssten, aber über kurz oder lang sollten Plugins sowieso bestimmte Regeln befolgen, weil es sonst Durcheinander gibt. Ich schau mir News nachher mal an.

[cmb]

Ich schau mir News nachher mal an.

Nur mal kurz drüber geschaut. Könnte man wohl so lösen wie ich oben vorgeschlagen habe; dazu müsste man alle $.get() Aufrufe in index.php entsprechend anpassen. Ist natürlich ein bisschen aufwendig, aber das Plugin bräuchte vermutlich sowieso Updates bzgl. der jQuery Komponenten (die scheinen reichlich in die Tage gekommen zu sein).

Aber gut, ich sollte wohl nicht anderen meine bevorzugten Lösungen aufdrängen. Mal sehen, ob mir noch was besseres einfällt. Möglicherweise tut's ein eigener HTTP-Request-Header. Sollte der irgendwo entfernt werden (vielleicht von einem Proxy oder einer Firewall), dann wäre das allerdings doof.

[cmb]

Okay, ich probier's mal so: https://github.com/cmb69/twocents_xh/co ... d132641847.