Plugin calendar_xh und PHP 8 - fataler Fehler

[olape]

Wie würdet ihr es machen?

Code: Select all

if (!defined("CMSIMPLE_XH_VERSION")) {
    header("HTTP/1.1 403 Forbidden");
    exit;
}

[frase]

Und da ist Calendar 1.4.10.

Ich habe jetzt mal nur den Patch getestet.

Na ja, es ist in dieser Form für mich immer noch nicht nutzbar: Access denied!
Das trifft übrigens auch auf Knollsens-Version zu.

Also habe ich mal den zweiten Vorschlag von hier in der index.php Zeile 6 eingefügt:

Code: Select all

if (!defined("CMSIMPLE_XH_VERSION")) {
    header("HTTP/1.1 403 Forbidden");
    exit;
}

Das Sprachproblem unter Bigcalendar besteht weiterhin – aber dafür gibt es ja jetzt ein Issue und ist deshalb nur noch halb so schlimm.
(Die Hilfedatei und die Seite „Autoren“ beachte ich mal nicht weiter.)

Der Aufruf der eigentlichen Kalender-Seite (egal, ob im Content oder unter Plugin) gibt folgende Debug-Meldung aus:

DEPRECATED: Using ${var} in strings is deprecated, use {$var} instead
… \plugins\calendar\includes\calendar.php:783
DEPRECATED: Using ${var} in strings is deprecated, use {$var} instead
… \plugins\calendar\includes\calendar.php:953
DEPRECATED: Using ${var} in strings is deprecated, use {$var} instead
… \plugins\calendar\includes\calendar.php:962

War das nicht schon irgendwo korrigiert?

[wolfgang_58]

Hallo CMS'ler,
nun bin ich am "Denken", was und welche Version ist nun die Richtige?
Es gibt die Version "Calendar_XH-2.1", die ich am 8.7.2021 installiert habe und auch funktioniert. Mir wurde auch schon für diese Plugin von Frank Seidel ein entsprechende stylesheet.css für ein template fhs-whitespace gesendet und funktioniert.
Nun wird hier ein neues Plugin "calendar_XH_1.4.10" vorgestellt und das schaut auch laut der Hilfe-Datei (englisch) ganz anders aus.
Frage:
Was ist nun das richtige Plugin?
Könnte man das Plugin, wenn man es installiert, nicht mit einem eindeutigen Namen versehen, denn es heißt ja immer "calendar"

Für mich zumindest etwas verwirrend, aber die IT'ler von cmsimple_xh werden sich schon Gedanken gemacht haben?
Ich installiere einfach mal über ein calendar_xh-2.1 ein calendar_xh_1.4.10. Bin gespannt.

Wolfgang

[olape]

Für mich zumindest etwas verwirrend, aber die IT'ler von cmsimple_xh werden sich schon Gedanken gemacht haben?

Nein, das glaube ich in diesem Fall tatsächlich nicht. Jedenfalls nicht bis ganz zu Ende gedacht?

https://www.cmsimple-xh.org/de/?Plugin- ... h_one=0067
Und dann gibt es noch von knollsen eine modifizierte 1.2.10 --> Version 1.7
Das ist in dem Fall schon sehr verwirrend.

Ich installiere einfach mal über ein calendar_xh-2.1 ein calendar_xh_1.4.10. Bin gespannt.

Das halte ich für keine gute Idee. Ich kenne die beiden Plugins nicht, aber möglicherweise gibt es Unterschiede beim Aufruf.
Ich denke, es ist besser alle alten Aufrufe zu entfernen (oder prüfen, inwieweit die Aufrufe konform sind), das alte Plugin zu deaktivieren und dann erst das neue installieren und die Aufrufe wieder entsprechend Hilfe einzufügen.

[cmb]

Für mich zumindest etwas verwirrend, aber die IT'ler von cmsimple_xh werden sich schon Gedanken gemacht haben?

Nein, das glaube ich in diesem Fall tatsächlich nicht. Jedenfalls nicht bis zu Ende gedacht.

Das hat sich einfach so entwickelt. Seit fast 20 Jahren gibt es ein Calendar-Plugin. svasti hat dann irgendwann Version 1.2 veröffentlicht, und dann umfangreiche Erweiterungen eingebaut, die schließlich Version 1.4 wurden. Diese Variante befindet sich in einem minimalen Wartungsmodus. Dann gibt es aber noch zwei Forks von Calendar 1.2, einmal von knollsen, und dann noch einmal von mir. Man kann nur eine der Varianten verwenden, und sie dürften alle inkompatibel sein. Daher ist es nicht zu empfehlen, diese wie auch immer gegeneinander auszutauschen. Im Zweifel in einer separaten Testinstallation von CMSimple_XH ausprobieren, falls denn überhaupt Bedarf besteht.

[olape]

Das hat sich einfach so entwickelt. Seit fast 20 Jahren gibt es ein Calendar-Plugin.

Ich weiß. Und es ist dann fast unmöglich, solche Änderungen einzufügen, wie bspw. einen abweichenden Namen.
Zumindest, wenn man den ersten Fork dann bereits veröffentlicht hat.
Aber für den Anwender macht es das nun tatsächlich unübersichtlich.

Diese Variante befindet sich in einem minimalen Wartungsmodus.

Würde es dann nicht Sinn machen, diese Variante auslaufen zu lassen?

[olape]

Ich weiß. Und es ist dann fast unmöglich, solche Änderungen einzufügen, wie bspw. einen abweichenden Namen.
Zumindest, wenn man den ersten Fork dann bereits veröffentlicht hat.
Aber für den Anwender macht es das nun tatsächlich unübersichtlich.

Das wäre mal ein Gedanke, dass wir uns einigen, dass Forks:
- einen abweichenden Namen,
- abweichende txt- und cf-Variablen und Foldername
- und auch abweichende Aufrufe
haben.
Auch wenn ich weiß, dass wir leider nicht die Macht haben, so etwas durchzusetzen.

[frase]

Ich weiß. Und es ist dann fast unmöglich, solche Änderungen einzufügen, wie bspw. einen abweichenden Namen.

Der Ur-Kalender wird sicher irgendeine Lizenz-Variante gehabt haben.
Wenn man davon forkt, kann man natürlich den Namen nicht einfach ändern.

Das ist sehr verwirrend! Mindestens 3 Plugin-Versionen mit gleichem Namen.

Vielleicht sollten wir ganz allgemein dazu übergehen, geprüfte und abgenickte Plugins auf GitHub zu haben.

Das trifft auch (und vor allem) auf die Standard-Plugins, die mit XH ausgeliefert werden, zu.
hi_updatecheck und jQuery4CMSimple wären solche speziellen Kandidaten.
Frage dabei: Wer ist/wird dann Maintainer?

[frase]

- einen abweichenden Namen,

Vielleicht das Kürzel des Autors als Pre- oder Suffix?

[wolfgang_58]

Hallo,
nun muss ich doch noch ein mal hier antworten.
Es wurde hier vielfach von "Wenn man davon forkt" geschrieben "fork", Ok, d.h. es wird herumgegabelt also, dass "Essen" schmeckt nicht!
Warum kann man das nicht auf einer Ebene ausserhalb von öffentlichen Zugängen = viewforum.php?f=16, denn hier logge sich ja alle ein und das sind NICHT nur Entwickler!

Warum kann man dann kein Plugin, auch wenn es ein anderer entwickelt hat, mit neuen Namen versehen? Das entspricht doch auch der DGSVO mit dem Hinweis im Plugin? Wahrscheinlich denke ich zu "einfach".

Der Vorschlag mit " Vielleicht sollten wir ganz allgemein dazu übergehen, geprüfte und abgenickte Plugins auf GitHub zu haben.
" wäre bestimmt einfacher und jeder User kann sich dort die neuesten Updates abholen. Nach meiner Erfahrung hier von vielen wäre das auch gut so, denn es wird ja auch von den Entwicklern hier erwartet, dass der User sich auskennt ;-((

ich möchte es einfach mal so ausdrücken, wenn man hier in diesem Forum nachliest und es ist leider nicht so übersichtlich, sondern mit Suchbegriffen arbeitet, findet man schnell eine Seite, aber aber aber ...

Eigentlich war und bin ich von cmsimple_xh schon überzeugt ...
... die Hilfe-Dateien sind nicht immer hilfreich, aber mit viel Versuch und Mühe klappt es oder das Plugin wird nicht genutzt. Es wird einfach NICHT für einen "Laien" oder "PHP-Laien" gedacht und setzt seine eigenen Kenntnisse voraus, dann ist so eine Hilfe schon akzeptabel.
Wolfgang