- Willkommen im Forum „moziloCMS Supportforum“.
moziloCMS Supportforum
Neuigkeiten:
moziloCMS verwendet Cookies. Wenn Sie auf unserer Seite weitersurfen, stimmen Sie der Cookie-Nutzung zu Datenschutzerklärung
moziloCMS Layouts
moziloCMS Plugins
Neueste Beiträge
#1
Plugins / Antw:Automatische SEO-URLs in ...
Letzter Beitrag von bernhard_u - 05. Juni 2026, 09:29:55Hallo,
vielen Dank für die Klärung und den Vorschlag – das ist eine elegante Lösung!
Ich habe den Fix lokal getestet und kann bestätigen: er funktioniert wie beschrieben. Mit dem angepassten Versionscheck wird '3.0' korrekt als moziloCMS 3.x-Plugin erkannt und das Plugin wird nicht mehr automatisch deaktiviert.
Sobald der Fix in einer stabilen moziloCMS-Version landet, werde ich den Versionsstring in seo_urls von '2.0 / 3.0' auf das sauberere '3.0' umstellen. Kannst du mich kurz informieren wenn das der Fall ist?
Bis dahin bleibt '2.0 / 3.0' als Workaround drin – funktioniert ja zuverlässig mit beiden CMS-Versionen.
Viele Grüße
Bernhard
vielen Dank für die Klärung und den Vorschlag – das ist eine elegante Lösung!
Ich habe den Fix lokal getestet und kann bestätigen: er funktioniert wie beschrieben. Mit dem angepassten Versionscheck wird '3.0' korrekt als moziloCMS 3.x-Plugin erkannt und das Plugin wird nicht mehr automatisch deaktiviert.
Sobald der Fix in einer stabilen moziloCMS-Version landet, werde ich den Versionsstring in seo_urls von '2.0 / 3.0' auf das sauberere '3.0' umstellen. Kannst du mich kurz informieren wenn das der Fall ist?
Bis dahin bleibt '2.0 / 3.0' als Workaround drin – funktioniert ja zuverlässig mit beiden CMS-Versionen.
Viele Grüße
Bernhard
#2
Plugins / Antw:Automatische SEO-URLs in ...
Letzter Beitrag von harry60 - 04. Juni 2026, 20:34:53Hallo Bernhard,
Mein letzter Eintrag war leider falsch. Meine beta Version hatte sich schon bischen verändert. Das $info = [] ist schon richtig, ergibt keine Fehler. Auch deine neue Version v1.3.5 funktioniert auch.
Zum Problem mit dem Erkennen der Plugin-Version. Wie ich schon schrieb, sind wir dabei die Pluginerkennung komplett zu erneuern. Dauert noch.
Ich habe hier mal einen Vorschlag, als Zwischenlösung für Mozilo 3.0.5. Kannst du das mal testen?
Das sollte dann auch mit nur '3.0' bei $info funktionieren. Also deine Version nur für Mozilo 3.0.
Schöne Grüße
Mein letzter Eintrag war leider falsch. Meine beta Version hatte sich schon bischen verändert. Das $info = [] ist schon richtig, ergibt keine Fehler. Auch deine neue Version v1.3.5 funktioniert auch.
Zum Problem mit dem Erkennen der Plugin-Version. Wie ich schon schrieb, sind wir dabei die Pluginerkennung komplett zu erneuern. Dauert noch.
Ich habe hier mal einen Vorschlag, als Zwischenlösung für Mozilo 3.0.5. Kannst du das mal testen?
Code Auswählen
$needed_mozilo_version = $plugin_info[1] ?? '';
$pl_ver = 0;
if ($needed_mozilo_version === '') {
$pl_ver = 1;
}
$checks = [
'1.1' => 1,
'2' => 2,
'3' => 2, // bewusst so gewollt
];
foreach ($checks as $needle => $value) {
if (strpos($needed_mozilo_version, $needle) !== false) {
$pl_ver = $value;
}
}
Das sollte dann auch mit nur '3.0' bei $info funktionieren. Also deine Version nur für Mozilo 3.0.
Schöne Grüße
#3
Neue Versionen / Antw:mozilo 3.0.5 beta 1
Letzter Beitrag von bernhard_u - 04. Juni 2026, 14:41:13Update 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.
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.
#4
Neue Versionen / Antw:mozilo 3.0.5 beta 1
Letzter Beitrag von bernhard_u - 04. Juni 2026, 11:27:40Hallo,
í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:
Danach greift dieser Zweig:
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
í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
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
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
#5
Plugins / Antw:Automatische SEO-URLs in ...
Letzter Beitrag von bernhard_u - 03. Juni 2026, 22:54:53Hallo,
vielen Dank für dein Feedback – ich habe das jetzt genauer untersucht und kann die Ursache erklären.
Der moziloCMS Plugin-Loader von 3.0.5 beta prüft in admin/plugins.php (Z. 239–266) den Versionsstring aus getInfo() so:
$pl_ver = 0;
if (!empty($plugin_info[1])) {
$needed_mozilo_version = $plugin_info[1];
} else {
$pl_ver = 1;
}
$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) {
// Plugin wird als 1.x erkannt und automatisch deaktiviert
}
Der String wird also mit strpos() auf '2' geprüft – enthält er keine '2', wird das Plugin als moziloCMS 1.x-Version eingestuft und automatisch deaktiviert. Das erklärt warum '3.0' allein nicht funktioniert.
Der Versionsstring '2.0 / 3.0' ist in v1.3.4 und v1.3.5 des seo_url Plugins identisch und enthält die benötigte '2' – der einzige Unterschied zwischen den beiden Versionen in getInfo() ist die Array-Syntax (array() vs. []). Kannst du nochmal prüfen welche Version du ursprünglich installiert hattest? Falls du tatsächlich v1.3.5 verwendet hast und [] das Problem war, wäre das ein CMS-seitiger Bug den ich gerne weiterverfolgen würde.
Viele Grüße
Bernhard
vielen Dank für dein Feedback – ich habe das jetzt genauer untersucht und kann die Ursache erklären.
Der moziloCMS Plugin-Loader von 3.0.5 beta prüft in admin/plugins.php (Z. 239–266) den Versionsstring aus getInfo() so:
$pl_ver = 0;
if (!empty($plugin_info[1])) {
$needed_mozilo_version = $plugin_info[1];
} else {
$pl_ver = 1;
}
$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) {
// Plugin wird als 1.x erkannt und automatisch deaktiviert
}
Der String wird also mit strpos() auf '2' geprüft – enthält er keine '2', wird das Plugin als moziloCMS 1.x-Version eingestuft und automatisch deaktiviert. Das erklärt warum '3.0' allein nicht funktioniert.
Der Versionsstring '2.0 / 3.0' ist in v1.3.4 und v1.3.5 des seo_url Plugins identisch und enthält die benötigte '2' – der einzige Unterschied zwischen den beiden Versionen in getInfo() ist die Array-Syntax (array() vs. []). Kannst du nochmal prüfen welche Version du ursprünglich installiert hattest? Falls du tatsächlich v1.3.5 verwendet hast und [] das Problem war, wäre das ein CMS-seitiger Bug den ich gerne weiterverfolgen würde.
Viele Grüße
Bernhard
#6
Plugins / Antw:Automatische SEO-URLs in ...
Letzter Beitrag von harry60 - 03. Juni 2026, 20:49:12Muß noch ergänzen, das ich das Plugin, mit der Änderung, mit Version 3.0.5 beta1 getestet habe.
Schöne Grüße
Schöne Grüße
#7
Plugins / Antw:Automatische SEO-URLs in ...
Letzter Beitrag von harry60 - 03. Juni 2026, 19:56:03Hallo Bernhard,
Ich habe die $info wie bei den vorangegangenen Versionen geändert, dann funktioniert es. Das zip wird als Plugin eingelesen.
Ohne array() wird das Plugin nicht erkannt.
Schöne Grüße
Ich habe die $info wie bei den vorangegangenen Versionen geändert, dann funktioniert es. Das zip wird als Plugin eingelesen.
Ohne array() wird das Plugin nicht erkannt.
Code Auswählen
$info = array(
'<b>seo_urls</b> ' . self::VERSION,
'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')
);
return $info;Schöne Grüße
#8
Neue Versionen / Antw:mozilo 3.0.5 beta 1
Letzter Beitrag von Fischi - 02. Juni 2026, 21:07:24Prima. 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ß
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ß
#9
Neue Versionen / Antw:mozilo 3.0.5 beta 1
Letzter Beitrag von harry60 - 02. Juni 2026, 17:31:20Hallo 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.
Ich denke wir werden das mit einbauen. Danke noch mal.
Schöne Grüße
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
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
#10
Neue Versionen / Antw:mozilo 3.0.5 beta 1
Letzter Beitrag von Fischi - 02. Juni 2026, 08:27:56Das 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ß
'<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ß