Modul procalendar (v 1.8.2): Verbesserungen und Korrekturen

[masju]

Hallo zusammen,

ich habe gerade das Modul procalendar v.1.8.2 aus dem Addon-Verzeichnis am Wickel und würde hier gerne mal einige Änderungen (verbunden mit einem Pull-Request) mit Euch diskutieren:

1. Fehlerkorrektur
functions.php
Zeilen 452 und 453

Code: [Select]

    $IsMonthOverview = ($month != date("n"));
    $IsMonthOverview = (($dayview && ($day != date("d"))) ? $IsMonthOverview : !$dayview);
Die doppelte Initialisierung von $IsMonthOverview in ShowActionList() überschreibt den zuvor gesetzten Wert und verhindert zudem die Tagesansicht in Nicht-Systemmonaten. Beide Zeilen sind entfernen, um konsistente Anzeige mit dayview-Parameter sicherzustellen.

view.php
Zeile 105: Hier fehlt offensichtlich ein "NOT"-Ausrufezeichen

Code: [Select]

    $IsMonthOverview = $dayview;zu ändern in

Code: [Select]

    $IsMonthOverview = !$dayview;Entweder werden alle Termine des Monats oder alle des gewählten Tages im Frontend angezeigt. Siehe oben.

save.php
Die Zeilen 169 bis 171 machen eventuell Ärger (Warning), wenn kein Endedatum gesetzt ist

Code: [Select]

        $js_end_day     = substr($js_end_time, 0, 2);
        $js_end_month   = substr($js_end_time, 3, 2);
        $js_end_year    = substr($js_end_time, 6, 4);
ersetzen durch

Code: [Select]

        $js_end_day     = substr($js_end_time ?? '', 0, 2);
        $js_end_month   = substr($js_end_time ?? '', 3, 2);
        $js_end_year    = substr($js_end_time ?? '', 6, 4);
Auch Zeile 272 wird unter Umständen angemeckert (Warning):

Code: [Select]

        if (strlen($time_end) == 0) {$time_end = "00:00";}
ersetzen durch

Code: [Select]

        if (strlen($time_end ?? '') == 0) {$time_end = "00:00";}

2. Verbesserungen
save.php
Nach dem Ändern oder der Neueingabe von Events springt das Modul immer wieder in den aktuellen Monat zurück, anstatt im gewählten zu bleiben.
Das ist sehr unschön, weil mal in zukünftigen Monaten angelegte Events nur auf sehr umständliche Weise direkt wieder editieren kann.
Änderungsvorschläge: year, month und day per _get durchreichen.

Zeile 33

Code: [Select]

     $sAddonBackUrl = ADMIN_URL.'/pages/modify.php?page_id='.$page_id.$sec_anchor;ersetzen durch:

Code: [Select]

    $urlMonth = isset($_GET['month']) ? urlencode($_GET['month']) : '';
    $urlYear  = isset($_GET['year']) ? urlencode($_GET['year']) : '';

    $sAddonBackUrl = ADMIN_URL.'/pages/modify.php?';

    // Parameter anhängen, falls vorhanden

    $query = [];
    if ($urlMonth !== '') $query[] = "month=$urlMonth";
    if ($urlYear  !== '') $query[] = "year=$urlYear";
    $query[] = "page_id={$page_id}{$sec_anchor}";

    $sAddonBackUrl .= '&' . implode('&', $query);
Zeile 198

Code: [Select]

   $sBackendUrl  = ADMIN_URL . '/pages/modify.php?page_id='.$page_id.'&month='.date('m').'&year='.date('Y') . '';aus dem gleichen Grund ersetzen durch

Code: [Select]

    $sBackendUrl  = $sAddonBackUrl;

Die an vielen Stellen vorhandenen auskommentierten Codezeilen habe ich erst einmal drin gelassen, der Code scheint wohl nach einer Aktualisierung nicht bereinigt worden zu sein.
Ich habe das Modul gerade auf einer PHP-Version: 8.4.13-Installation laufen, es gibt bislang keine Fehlermeldungen.

Eure Meinung?

Viele Grüße
masju

(Anhang: Aktuelle Version 1.8.2 aus dem Addon-Verzeichnis)

[hgs]

Erst Mal Danke fürs drüberschauen und für die vorgechalgenen Verbesserungen.
Ich benutze den ProCalendar sehr aktive und habe immer mal wieder auch Änderungswünsche an der Funktion geäußert und dann auch bekommen.
(Daran waren u.a. marmot, Luisehane, sternchen8875.... beteiligt)
Die letzten Änderungen haben es scheinbat gar nicht ins addon geschaft, denn ich habe schon eine Version 1.8.3 und die ZN passen mit deinem Post nicht überein, sind aber zu finden.
Ich werde daraus mal eine Version 1.8.4 machen und dann durchtesten.
Einverstanden?

[masju]

Sehr gerne  !

[hgs]

OK, hier die geänderte Version 1.8.4.

Alle Änderungen sind wie folgt in den jeweiligen  Dateien gekennzeichnet worden.
Ist bestimmt nicht Codingstandard, aber zum nachvollziehen sollte es reichen.

// modify from https://forum.WebsiteBaker.org/index.php/topic,32440.new.html#new

Die Verbesserung konnte ich allerdings nicht nachvollziehen, Nach dem Speichern ist im BE wieder der aktuelle Monat sichtbar, oder mache ich einen Bedienfehler?

Viel Spaß beim testen, siehe weiterer Verlauf


Anhang gelöscht

[sternchen8875]

Besserwisser-Mode == on

Code: [Select]

$IsMonthOverview = ($month != date("n"));
    $IsMonthOverview = (($dayview && ($day != date("d"))) ? $IsMonthOverview : !$dayview);
Zeile 1 prüft, ist der im Funktionsaufruf übermittelte Monat $month gleich dem aktuellen Monat lt date-Funktion
Antwort ist true oder false - auf deutsch Ja oder Nein

Zeile 2 mußt du zerlegen in alle Einzelteile
$dayview und $day kommen aus dem Funktionsaufruf,
$dayview ist wieder true or false oder 0 bzw 1
$day ist der übermittelte Tag nach date-Funktion

also "auf deutsch": Ist dayview wahr UND der übermittelte Tag $day == dem ermittelten Tag aus der date-Funktion für heute, dann verwende den Wert von $IsMonthOverview. Ist das nicht der Fall, verwende den umgekehrten Wert von $dayview aus dem Funktionsaufruf

das Ganze ist also keine Initialisierung, es ist ein Schalter, der zwischen Tages- und Monatsansicht umschaltet und das unter verschiedenen Bedingungen

Nimmst du die Zeilen weg, wie vorgeschlagen, bekommst du in der Folge weitere Warnings, weil $IsMonthOverview nicht definiert wurde.

Zum Rest:
ich würde empfehlen, die Werte beim POST-Empfang schon zu validieren

also z.b. hier

Code: [Select]

$js_end_time = $admin->get_post('date2');
Wir wissen, es ist das Datum des End-Termins, es könnte in der Theorie aber alles sein (gilt für alles, was hier per POST in der save.php ankommt)

Setzt dir einen solchen dump in der save.php ganz oben

Code: [Select]

echo "<pre class='debug-dump'>DEBUG in " . basename(__FILE__) . " on line " . __LINE__ . ":<br>";
print_r($_POST);
echo "</pre>";
das macht es leichter

[masju]

Okay, das mit dem Schalter: einverstanden  meine Erklärung war falsch.

Aber die Auswertung von $dayview ist hier trotzdem nicht wie erwartet. Denn: lasse ich die beiden Zeilen drin, verhält es sich wie folgt:

Klicke ich im Frontend im aktuellen Monat einen Tag an, schaltet der Kalender auf die Anzeige der Termine des angeklickten Tages (korrekt). 
Wechsel ich auf irgendeinen anderen Monat und klicke einen Tag an, bleibt die Anzeige trotzdem auf "Monatsübersicht" (nicht korrekt)  .

Die Anzeige sollte nur von der Variable $dayview oder meinetwegen $IsMonthOverview abhängen.

[masju]

Die Verbesserung konnte ich allerdings nicht nachvollziehen, Nach dem Speichern ist im BE wieder der aktuelle Monat sichtbar, oder mache ich einen Bedienfehler?

Der Monat bleibt (derzeit) nur beim Edit eines Events erhalten (Bearbeite z. B. einen Eintrag im Dezember 2025 und die Anzeige springt nach dem Speichern wieder auf Dezember 2025).
Zu überlegen wäre, ob noch eingebaut wird, dass das Kalender-Backend beim Neueintrag eines Events auch gleich in den Monat des neu angelegten Events springt.

[hgs]

ok, Danke sternchen8875 für die Info.
@ [/size]masju
 baust du eine 1.8.4.1 aus den Infos? Dann können wir weiter sehen und das fertige Modul wird dann am Ende eine 1.8.5 oder 2.0 (wie auch immer)
gerne dann hier anhängen zum testen

[sternchen8875]

bevor ich mich hier ausklinke, versuch ich es noch einmal. Vielleicht verstehen wir uns ja nur falsch...

einer von uns scheint ein Zaubermodul zu haben oder es wurde schon soviel geändert, das es anders funktioniert. Kommentiere ich, wie vorgeschladen diese beiden Zeilen aus, fehlt mir in der Monatsübersicht des aktuellen Monats (Oktober 2025) die Auflistung der Termine

Code: [Select]

    $IsMonthOverview = ($month != date("n"));
    $IsMonthOverview = (($dayview && ($day != date("d"))) ? $IsMonthOverview : !$dayview);
Warum?

$IsMonthOverview ist per Initial == false

Nun Zeile 1

Code: [Select]

$IsMonthOverview = ($month != date("n"));Ist der Monat, der per Link kommt, ungleich dem von PHP ermittelten aktuellen Monat
Da Oktober 2025 mein Startmonat ist und wir Oktober 2025 haben, ist $IsMonthOverview immer noch false, weil die Bedingung nicht erfüllt wird

Möchte ich heute den Novemberkalender sehen, wäre die Bedingung wahr, der übermittelte Monat 11 ist nicht der PHP-Monat 10, $IsMonthOverview wäre dann true und heißt auf deutsch: zeige die Monatsanzeige (und nicht die Einzel-Tagesanzeige)

Nun Schalter 2

Code: [Select]

$IsMonthOverview = (($dayview && ($day != date("d"))) ? $IsMonthOverview : !$dayview);
Fall1: $IsMonthOverview ist false
übermittelt wird per Link nun entweder
page_id=18&day=18&month=10&year=2025&dayview=1
oder
page_id=18&month=11&year=2025

Uns interessiert vorallem $dayview in Link#1 und der day=18
da $dayview gesendet wurde und den Wert = 1 hat, wird es true. Bedingung 2 ist erfüllt, wenn der Link den day=18 übermittelt und PHP sagen würde, heute ist der Tag 18. Dann gilt also $IsMonthOverview. Und weil wir Oktober haben und PHP diesen Oktober als aktuellen Monat heute ermitteln würde, wäre $IsMonthOverview == false

Nun ist heute aber der 17 und nicht der 18. Bedingung 2 wird nun unwahr, es gilt also der letztere Teil hinter dem Doppelpunkt "!$dayview", also das Gegenteil vom Wert. $dayview war eine 1, das Gegenteil ist false oder 0. $IsMonthOverview ist also wieder false
Genau, was wir wollten, denn ich habe ja im Kalender angewählt, das die Tagesanzeige ausgegeben werden soll

Das funktioniert so auch hin und her, im Front- und Backend

Aber nach deiner Theorie muß ja die Version von hgs bei dir passen, also macht, wie ihr wollt, ist OpenSource