mozilo 3.0.5 beta 1

[bernhard_u]

Update zur FTP-Hypothese:

Ich konnte das Problem mit FileZilla 3.69.6 beim zweiten Versuch nicht reproduzieren - die Konfigurationsdaten blieben beim erneuten FTP-Upload korrekt erhalten. FileZilla löscht im Standard-Modus keine Remote-Verzeichnisse, die lokal nicht vorhanden sind - admin/conf/ und cms/conf/ bleiben also normalerweise unangetastet.

Die genaue Ursache des ursprünglichen Problems ist damit noch ungeklärt. Möglicherweise wurde beim ersten Test versehentlich eine andere Aktion ausgeführt.

Der beschriebene Code-Mechanismus in makeConfFiles() bleibt aber grundsätzlich ein Risiko: Wenn die conf-Verzeichnisse aus irgendeinem Grund fehlen, werden kommentarlos Default-Werte geschrieben - ohne Warnung, ohne Rückfrage. Eine Absicherung im Code oder zumindest ein expliziter Hinweis in der Update-Anleitung wäre daher weiterhin sinnvoll.

[marusti]

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

Die Lösung hat bei mir funktioniert. Kann das bitte noch jemand anderes bestätigen, dass es jetzt funktioniert?

[Fischi]

Ich hab´s nochmal getestet. Funktioniert bei mir auch.

Was anderes ist mir noch aufgefallen - ist wohl schon seit Einführung der 3.0.

Es gibt an jedem Bild den Schalter "Vorschaubilder auf diese Größe skalieren". Das Bildchen wird nicht angezeigt.
Da passiert was in der admin.css ab Zeile 1042 mit .mo-icons-img-scale

Es geht aber nur um das Bild; die Funktion ist gegeben. Also weniger wichtig.

Gruß

[Fischi]

Ich habe nochmal verschiedene Aktionen mit Galerien und Bildern durchgespielt. Da bin ich über einige Dinge gestoßen (mozilo 3.0.5b)
Lokal XAMPP
-----------
- wenn ich Bilder in Galerie lösche, mich auslogge und wieder anmelde ist Galerien ausgegraut; muß andere Benutzer abmelden
- das passiert auch in Dateien, wenn ich eine gelöscht habe
- beim Ändern der "Skalierungseinstellungen vorbelegen" in Galerien vorbelegen, z.B. Breite oder Höhe, kommt bei Abschluß der Eingabe mit ENTER "Fehler beim Speichern der Einstellung (Dateirechte prüfen)

Webspace
--------
- Skalierungseigenschaften vorbelegen geht nicht; Fehler beim Speichern der Einstellung (Dateirechte prüfen)
755 auf Ordner
644 auf einzelne Bilder

Ich hoffe mal, das ist nicht wieder nur bei mir so.

Gruß

[marusti]

Was anderes ist mir noch aufgefallen - ist wohl schon seit Einführung der 3.0.

Es gibt an jedem Bild den Schalter "Vorschaubilder auf diese Größe skalieren". Das Bildchen wird nicht angezeigt.
Da passiert was in der admin.css ab Zeile 1042 mit .mo-icons-img-scale

Es geht aber nur um das Bild; die Funktion ist gegeben. Also weniger wichtig.

Meinst du das? Welchen Browser nutzt du?

[Fischi]

Ja dieses Symbol.
Ich arbweite mit Firefox, aktuellste Version. hab´s aber auch mit Edge, Chrome und Opera probiert.

Hab auch nochmal 305b komplett neu unter XAMPP mit PHP 8.2.xx installiert. Da ist die Galerie moziloCMS.
Ohne irgendwelchen Eingaben oder Anpassungen. Gleiches Ergebnis.

Auch folgende Variante:
- in Galerie Bild gelöscht; Ausloggen, Einloggen; Galerie ausgegraut
- in Galerie Bild gelöscht; in Bereich Dateien gewechselt; Aus- und Eingeloggt; Dateien ausgegraut

Gruß

[marusti]

Mein Screenshot ist auch aus Firefox.
Alle anderen Icons werden aber korrekt angezeigt, zb der Mülleimer in dem Beispiel? Nur das eine Icon nicht?

[Fischi]

Genau so ist es.
STelle ich oben rechts neue Maße für das Vorschaubild ein und betätige das Icon, dann wird die Vorschau angepaßt. Funktioniert also.
Wenn ich alle markiere und nutze den Resize oben global, geht es nicht. Man muß also jedes Bild einzeln resizen.
Geht vielleicht in die gleiche Richtung wie Gruppenlöschen.

Priorität nicht wirklich hoch.

Mich würde mal interfessieren, ob die anderen Effekte nur bei mir auftreten, also:
- über den Galerien die Skalierungsoptionen global einstellen und Speichern geht dann nicht
- Bild aus Dateien ode Galerie löschen, Ausloggen. nach erneutem Login ist der Bereicch Dateien oder Galerien gesperrt.

Kann das mal Jemand probieren? Nach verschiedenen Effekten in der Vergangenheit zweifle ich nämlich immer sofort an meiner individuellen Umgebung.

Ich habe mal unter XAMPP folgende Konstellation getestet:
1. mozilo 2.0 Rev 55, PHP 7.4 --> geht alles
2. mozilo 2.0 Rev. 55 PHP 8.0 --> geht alles
3. mozilo 3.0.0 PHP 8.2 --> Icon da; da geht sogar Gruppenlöschen noch!; aber Skalierungsvoreinstellungen lassen sich nicht speichern

Gruß

[Fischi]

Ich habe mal weiter getestet:
Korrektur:  mozilo 3.0.0 PHP 8.2 Icon weg

4. mozilo 3.0.2 PHP 8.2 --> Icon weg, Gruppenlöschen geht; Skalierungseinstellungen vorbelegen Fehler bei Speichern
5. mozilo 3.0.3 PHP 8.2 --> icon weg; Gruppenlöschen geht; Gruppenskalieren geht; Vorbelegung ändern geht nicht
6. mozilo 3.0.4 PHP 8.2 --> Icon weg; Gruppenlöschen geht nicht; Gruppenskalieren geht nicht; Vorbelegung nicht speicherbar
7. mozilo 3.0.5b PHP 8.2 --> wie bei 3.0..4; Außerdem der Effekt, daß Galerien bzw. Dateien gesperrt sind, wenn ich dort Lösche, Auslogge, neu Einlogge

Ich habe das jetzt mal alles getestet, da ich irgendwie an mir gezweifelt habe. Da ich diese gesamte Funfktionalität in der Vergangenheit kaum genutzt habe, ist es eben nicht aufgefallen. Werde es auch in Zukunft wohl kaum brauchen. Priorität gering.

Da scheint Einiges im Modul Galerien zu sein. Ihr müßt abschätzen, ob der Aufwand lohnt. Das könnte einen ganzen Schwanz nach sich ziehen.

Gruß

[Fischi]

Zusatz: Nur mal eine Vermutung am Beispiel einer Stelle (Gruppenlöschen)
In der fileupload.template.js steht jetzt:

'<div class="delete flex">' +
    '<button ...></button>' +
    '<label for="">' +
        '<span class="sr-only">...</span>' +
        '<input id="" type="checkbox" name="delete" value="1" />' +
    '</label>' +
'</div>'

Hier taucht neu auf:
<span> mit der Klasse sr-only --> Anpassung für ScreenReader
Danach greifen Selektoren in´s Leere!


Kann es sein, daß bei der grundhaften Umstellung (z.B. JQuery -> reines JS) hier noch mehr Problemchen schlummern, die wir noch gar nicht aufgetan haben?

Das Verhalten in der 3.0.5b habe ich nochmals überprüft und damit meine Umgebung als Verursacher ausgeschlossen.
- obige Tests liefen nur unter XAMPP
- die gleiche Site auf dem Webspace verhält sich analog
- habe auch mal über Smartphone - Hotspot - Linux zugegriffen - gleicher Effekt

Gruß

[marusti]

• Gruppenlöschen
• Skalierungsvoreinstellungen
• Gruppenskalieren
• Bild aus Dateien ode Galerie löschen, Ausloggen. nach erneutem Login ist der Bereicch Dateien oder Galerien gesperrt.

Haben wir alles mit beta2 behoben.

Was ich weiterhin nicht nachstellen kann (egal mit welchem Browser oder welcher mozilo 3.x Version), ist das nicht angezeigte Icon zum skalieren https://www.mozilo.de/forum/index.php?msg=25473, vor allem da es nur das eine Icon ist.

Hat noch jemand das gleiche Problem?

[Fischi]

Danke für die Arbeit.
Das Problem mit dem Symbol für Resize ist wohl nun auch geklärt - ich habe mich narren lassen und Dich angesteckt.

Wenn man die URL im Browser anschaut, ergibt das ein logisches Symbol für Resize:

data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg'; viewBox='0 0 24 24' height='18' width='18'><path d='M3,8.1a1,1,0,0,0,1-1V6.91a1,1,0,0,0-2,0V7.1A1,1,0,0,0,3,8.1Zm0-4A1,1,0,0,0,3.42,4,1,1,0,0,0,3.1,2H3A1.09,1.09,0,0,0,2,3.1,1,1,0,0,0,3,4.05Zm17.39-.19A1,1,0,0,0,22,3a1,1,0,0,0-1-1h-.1a1,1,0,0,0-.51,1.86ZM11.89,4h.22a1,1,0,0,0,0-2h-.22a1,1,0,0,0,0,2ZM7.39,4H7.6a1,1,0,0,0,0-2H7.39a1,1,0,0,0,0,2ZM21,20a1,1,0,0,0-.42.1A1,1,0,0,0,20.9,22H21a1.09,1.09,0,0,0,1-1.1A1,1,0,0,0,21,20ZM14,11a1,1,0,0,0-1-1H3.27A1.08,1.08,0,0,0,3,10,1,1,0,0,0,2,11V21a1,1,0,0,0,1,1H13.1a1,1,0,0,0,.9-1.42Zm-2,9H5.52l3.91-3.9a.33.33,0,0,1,.47,0L12,18.19Zm0-4.63-.68-.69a2.35,2.35,0,0,0-3.31,0l-4,4V12h8Zm9,0a1,1,0,0,0-1,1v.21a1,1,0,0,0,2,0V16.4A1,1,0,0,0,21,15.4Zm0-9a1,1,0,0,0-1,1V7.6a1,1,0,1,0,2,0V7.39A1,1,0,0,0,21,6.39Zm0,4.5a1,1,0,0,0-1,1v.22a1,1,0,0,0,2,0v-.22A1,1,0,0,0,21,10.89ZM17.1,20h-.2a1,1,0,1,0,0,2h.2a1,1,0,0,0,0-2ZM16.61,4a1,1,0,0,0,0-2H16.4a1,1,0,1,0,0,2Z'></path></svg>

Das Symbol ist wohl nur ein wenig klein, um die Funktion erkennen zu lassen.
Angehängtes Bild.

Gruß

[marusti]

Der beschriebene Code-Mechanismus in makeConfFiles() bleibt aber grundsätzlich ein Risiko: Wenn die conf-Verzeichnisse aus irgendeinem Grund fehlen, werden kommentarlos Default-Werte geschrieben - ohne Warnung, ohne Rückfrage. Eine Absicherung im Code oder zumindest ein expliziter Hinweis in der Update-Anleitung wäre daher weiterhin sinnvoll.

Hallo Bernhard,

ist das ausreichend oder soll es an einer anderen Stelle noch deutlicher gemacht werden?

Wir möchten an dieser Stelle auch nochmal den Aufruf an Alle erneuern: Wenn jemand denkt, die Anleitung sollte/muss überarbeitet werden, da etwas nicht eindeutig ist oder etwas fehlt/falsch ist, schickt uns bitte die Vorschläge wie es geändert werden soll. Das hilft sicherlich auch anderen.

[bernhard_u]

Hallo Maik, danke für deine Rückmeldung. Der bestehende Backup-Hinweis ist auf jeden Fall ein guter erster Schritt. Ich hätte folgenden ergänzenden Vorschlag mit konkretem Hinweis speziell auf die conf-Verzeichnisse z.B.:

Hinweis: Die Verzeichnisse admin/conf/ und cms/conf/ enthalten alle individuellen Konfigurationseinstellungen und sind nicht im Update-ZIP enthalten. Beim FTP-Upload sollten diese Verzeichnisse erhalten bleiben. Fehlen sie nach dem Upload aus irgendeinem Grund, müssen sie vor dem Aufruf von install.php aus dem Backup zurückgespielt werden - andernfalls werden beim Installationsvorgang alle Einstellungen auf Standardwerte zurückgesetzt.

Optional und längerfristig wäre m.E. zudem eine Absicherung direkt im Code von makeConfFiles() sinnvoll: Wenn die conf-Verzeichnisse fehlen obwohl bereits Kategorien auf dem Server existieren, könnte der Wizard eine klare Fehlermeldung ausgeben statt kommentarlos Default-Werte zu schreiben.

Viele Grüße

Bernhard

[marusti]

Danke Bernhard! Habe den Hinweis mit aufgenommen.

Der Punkt ist auch auf der to-do Liste aufgenommen.