mozilo 3.0.5 beta 1

[marusti]

Wir freuen uns die Version 3.0.5 als erste beta Version zur Verfügung zu stellen.

Wir würden uns freuen, wenn so viele wie möglich die Version Testen können und zur Verbesserung beitragen, damit die Version demnächst als finale Version veröffentlicht werden kann.

Updateanleitung ist wie immer hier zu finden https://www.mozilo.de/Anleitung.html

[Fischi]

Hallo marusti,
ich habe einige Installationen probiert:
- reine Neuinstallation
- Update von 3.0.4
Beim Start des Admin erscheint immer angehängte Fehlermeldung.

Ich habe nur unter XAMPP lokal mit PHP 8.2 getestet.

Gruß

[harry60]

Hallo Fischi,

Das ist keine Fehlermeldung. Wenn die fertige Version von 3.0.5 erscheint, ändert sich das zum Guten!

Schöne Grüße

[bernhard_u]

Hallo marusti,

ich habe die 3.0.5 Beta in einem Testbereich installiert, hier mein Feedback:
Der Fehler ist behoben:
###CMS
Fehler bei CANONICAL_LINK behoben https://www.mozilo.de/forum/index.php/topic,4860

SEO_URL und indexnow Plug funktionieren mit 3.0.5 Beta.

Sonst ist mir bei einem ersten schnellen Tests nichts aufgefallen.
Falls ich noch was finde, poste ich es hier.

Viele Grüße

[bernhard_u]

bei den Einstellung fehlen die vor dem Update vorhanden Einträge (siehe Screenshot)
Kann man die vorher sichern?

[bernhard_u]

Dieser Fehler ist mit bei der Plugin-Versions Prüfung aufgefallen, das ist auch schon in der V3.0.4 so. Ist das schon bekannt?

moziloCMS prüft ob '2' im Info-String des Plugins enthalten ist. Fehlt die '2', deaktiviert der Admin das Plugin automatisch.   
Die Logik ist in admin/plugins.php Zeilen 246-255:
$pl_ver = 0;
$pos = strpos($needed_mozilo_version, '1.1');
if ($pos !== false) {
    $pl_ver = 1;
}
$pos = strpos($needed_mozilo_version, '2');
if ($pos !== false) {
    $pl_ver = 2;
}
if ($pl_ver < 2) {
    // Fehlermeldung + Plugin wird automatisch deaktiviert!
}

Das Ergebnis: Der Versionsstring muss die Ziffer '2' enthalten – sonst deaktiviert moziloCMS das Plugin automatisch. Es gibt keine Prüfung auf '3' alleine, also wenn das Plugin nicht 2.x kompatibel ist muss mann trotzdem *2.0 /3.0' in den Info String eintragen, sonst kommt eine Fehlermeldung.
Beispiel:
 $info = array(
            '<b>seo_urls</b> ' . self::VERSION,
            '2.0 / 3.0',  // Hinweis: moziloCMS prüft ob '2' im String enthalten ist.
            // Fehlt die '2', deaktiviert der Admin das Plugin automatisch.
            // Das Plugin unterstützt nur moziloCMS 3.0.x – siehe getInfo().
            $description,
            '',
            '',
            array('seo', 'url', 'rewrite', 'slug')
        );

[harry60]

Hallo Gerhard,

Ja, der Fehler ist bekannt.

An der Plugin-Versions Prüfung arbeiten wir aktuell noch. Kann noch ein bischen dauern.

Schöne Grüße

[marusti]

bei den Einstellung fehlen die vor dem Update vorhanden Einträge (siehe Screenshot)
Kann man die vorher sichern?

Hallo bernhard,
wie hast du das Update durchgeführt? So wie hier? https://www.mozilo.de/Anleitung/Los%20gehts.html

[bernhard_u]

Hallo Maik,
ja genau: "Die Anleitung gilt für Updates:
    von moziloCMS 3.x auf eine andere moziloCMS 3.x Version, Schritte 1 bis 6
Ich habe gerade noch gesehen, dass ein Eintrag für die Startkategorie übernommen wurde, alle anderen die in der Vorversion konfiguriert waren fehlen (Siehe Screenshot).

Viele Grüße
Bernhard

[Fischi]

Hallo marusti,
mir ist bei der Verwaltung der Dateien (Bilder) was aufgefallen.
Wenn ich mehrere Bilder löschen will, dann markiere ich diese ganz rechts mit Haken. Die Löschfunktion oben in der Symbolleiste betätigen (Papierkorb als rechtes Symbol), dann wird auch gefragt, ob die markierten Dateien gelöscht werden sollen. Nach Bestätigung sind die Dateien aber noch da. Auch Seite neu laden ändert das nicht.
Auch ein einzelnes Bild über diesen Weg läßt sich nicht löschen.

Wenn ich mich aus dem Admin auslogge und dann wieder anmelde, ist der Punkt Dateien ausgegraut. Ich muß Andere Benutzer abmelden!

Die Einzelbildlöschung über den Papierkorb redhts neben der Datei funktioniert. Aber eben nur Bild für Bild.

Das gleiche Verhalten zeigen auch Version 3.0.4 (auch Version 2.0 Rev55)

Hoffentlich habe ich da nicht was übersehen oder gar falsch gemacht.

Gruß

[Fischi]

Ich habe mich mal mit Unterstützung auf die Suche gemacht. Da ist tatsächlich ein Fehler, der schon länger zurückreicht. Irgendwann wurde an der HTML-Struktur was geändert.
In dialog.js gibt es die Funktion function dialog_delete_files().

Es wird angenommen, dass der Löschbutton ein direktes Geschwisterelement der Checkbox ist:
find('.delete input:checked').siblings('button')

Da scheint es in der Vergangenheit wohl eine Veränderung im HTML gegeben zu haben (habe nicht versucht, das zu finden):

In der Funktion dialog_delete_files()

diese Zeile:
del_item[0].find('.delete input:checked').siblings('button').addClass('js-nodialog').click();

ändern in:
del_item[0].find('.delete input:checked').each(function () {
    $(this).closest('.delete').find('button').addClass('js-nodialog').trigger('click');
});

hat bei mir das Problem behoben.

Ich hatte schon wieder Bedenken, daß da was in meiner persönlichen Umgebung hakt. Aber es ist ein echter Fehler. Jetzt funktioniert bei mir alles, wie es soll.

Zugegeben - Gruppenlöschen ist nun nicht gerade DIE wichtige Funktion. Wenige haben es bemerkt; man konnte sich ja auch behelfen, indem man 5 Mal Einzellöschung genutzt hat.

Ist vielleicht noch ein Punkt für die Version 3.0.5

Ihr werdet das prüfen.

Gruß

[Fischi]

Das geänderte HTML entsteht in der fileupload.template.js:
'<div class="delete flex">' +
    '<button ...></button>' +
    '<label for="">' +
        '<span class="sr-only">...</span>' +
        '<input id="" type="checkbox" name="delete" value="1" />' +
    '</label>' +
'</div>'

Damit ist der Button kein direktes Geschwisterelement der Checkbox mehr.
Direktes Geschwisterelement der Checkbox ist hier nur der vorherige <span> innerhalb des <label>, nicht der <button>.

Das alte .siblings('button') greift nicht mehr; Löschen greift in´s Leere.

Gruß

[harry60]

Hallo Fischi,

Mir ist das, glaube ich, auch mal aufgefallen, das man nicht alle Bilder auf einmal Löschen kann.

Deine Funktion geht. Hat einen kleinen Haken. Es bleiben mal ein Bild oder zwei Bilder stehen und werden nicht gelöscht. Ich habe mal weiter geforscht und habe das Ergebnis. Jetzt werden alle Bilder, etwas zeitversetzt, gelöscht.

Code Auswählen Erweitern

function dialog_delete_files() {
    var del_item = dialog_multi.data("del_object");

    dialog_multi.dialog({
        title: mozilo_lang["dialog_title_delete"],
        buttons: [{
            text: mozilo_lang["yes"],
            click: function() {

                // Alle Buttons sammeln
                var buttons = del_item[0].find('.delete input:checked')
                    .map(function () {
                        return $(this).closest('.delete').find('button')[0];
                    }).get();

                // Funktion, die einen Button löscht und Promise zurückgibt
                function deleteOne(btn) {
                    return new Promise(resolve => {

                        // Wenn moziloCMS nach dem Löschen ein Event feuert:
                        $(document).one("ajaxStop", function () {
                            resolve();
                        });

                        $(btn).addClass('js-nodialog').trigger('click');
                    });
                }

                // Seriell alle Buttons abarbeiten
                (async function run() {
                    for (const btn of buttons) {
                        await deleteOne(btn);
                    }

                    del_item[1].find('.toggle').prop('checked', false);
                    dialog_multi.dialog("close");
                })();
            }
        },{
            text: mozilo_lang["no"],
            click: function() {
                dialog_multi.dialog("close");
            }
        }]
    }).removeData("del_object");
}
Ich denke wir werden das mit einbauen. Danke noch mal.

Schöne Grüße

[Fischi]

Prima. Ich werde Deine Version auch nochmal testen.
Mit meinem Vorschlag wollte ich auch nur eine Prinziplösung schaffen. Das sollte nicht der Weisheit letzter Schluß sein. Für mich war es schon mal interessantund Ansporn, die betroffenen Stellen zu finden.

Noch ein Hinweis: Ich schrieb, daß bei mir nach einem fehlgeschlagenem Löschversuch der Bereich Dateien gesperrt war - das hängt leider mit meinem Problem IPv6 zusammen; ist nicht von allgemeiner Bedeutung.

Gruß

[bernhard_u]

Hallo,

ích habe das Problem der fehlenden Admin-Konfigurationen nach dem Update von 3.0.4 auf 3.0.5 beta näher analysiert - hier eine erste Einschätzung, die aber noch weiter verifiziert werden sollte.

Was vermutlich passiert:
Die Konfigurationsdateien in admin/conf/ und cms/conf/ sind bewusst nicht im Update-ZIP enthalten - sie sollen beim Upload erhalten bleiben. Eine mögliche Ursache für den Verlust könnte jedoch sein, dass ein FTP-Client im Sync-/Mirror-Modus diese Ordner löscht, weil er sie lokal nicht vorfindet und den Server mit dem lokalen Stand "angleicht" - das ist aber noch eine Hypothese und müsste gezielt geprüft werden.

Wenn danach install.php aufgerufen wird, legt die Funktion makeConfFiles() (install.php) die fehlenden Verzeichnisse neu an und schreibt automatisch Default-Werte - die individuellen Einstellungen sind damit überschrieben.

Der kritische Code-Pfad in der install.php:

Code Auswählen Erweitern

if(!is_dir(BASE_DIR_ADMIN.CONF_DIR_NAME))
    mkdir(BASE_DIR_ADMIN.CONF_DIR_NAME);  // leeres Verzeichnis angelegt
if(!is_dir(BASE_DIR_CMS.CONF_DIR_NAME))
    mkdir(BASE_DIR_CMS.CONF_DIR_NAME);   // leeres Verzeichnis angelegt

Danach greift dieser Zweig:

Code Auswählen Erweitern

elseif(is_file($dir))
    continue;          // Datei vorhanden -> überspringen (OK)
else
    $conf = makeDefaultConf($name, true);  // Datei fehlt -> Defaults werden geschrieben!

Warum wirkt die Startkategorie erhalten?
Auch sie wird auf den Default 'Willkommen' zurückgesetzt. Da diese Kategorie auf dem Testserver nicht existiert, zeigt das Dropdown einfach den ersten verfügbaren Eintrag - das erweckt nur den Eindruck, der Wert sei erhalten geblieben.

Sofortmaßnahme / Workaround:
Vor jedem Update die Ordner admin/conf/ und cms/conf/ separat per FTP sichern. Beim Upload keinen Sync-/Mirror-Modus verwenden. Nach dem Upload prüfen, ob beide Ordner noch vorhanden sind - erst dann install.php aufrufen.

Noch eine Ergänzung:

In der Online-Anleitung auf mozilo.de sowie im install.php-Wizard wird beim 1.12 -> 3.x Migrationspfad explizit darauf hingewiesen, alle .conf-Dateien aus admin/conf/ und cms/conf/ zu sichern. Für den 3.x -> 3.x Update fehlt ein solcher Hinweis jedoch - weder in der Update-Anleitung auf mozilo.de noch im Wizard wird erwähnt, dass diese Verzeichnisse beim FTP-Upload erhalten bleiben müssen. Eine ergänzende Warnung sowohl in der Online-Anleitung als auch im Wizard würde das Problem vermutlich verhindern.

Dies ist eine erste Code-Analyse ohne direktes Testen auf einem Live-System. Eine endgültige Bestätigung und ein sauberer Fix im Code oder in der Update-Anleitung sollten durch die Entwickler erfolgen.

Hoffe, das hilft als Hinweis weiter!
Viele Grüße

Bernhard