Modul Update und css

[FrankH]

• Man installiert ein Modul und passt z.B. die frontend.css an die Website an
• Man installiert ein Update für das Modul und überschreibt dabei die angepasste frontend.css

Sieht da jemand Handlungsbedarf für zukünftige WB-Versionen?

Außerdem finde ich es ganz nützlich zur Fehlersuche, wenn ich bei der Installation eine Meldung erhalte, die einen Hinweis darauf gibt, warum etwas nicht funktioniert.
Deswegen wundere ich mich über den mit WB 2.8 neu eingeführten Code in
/admin/modules/install.php:

Code:

// do not display notices and warnings during installation
error_reporting(E_ALL ^ E_NOTICE ^ E_WARNING);

Es werden also Notizen und Warnungen ausgeschaltet, aber die könnten ja vielleicht einen wichtigen Hinweis enthalten, oder hab ich da was übersehen?

[dbs]

   
* Man installiert ein Update für das Modul und überschreibt dabei die angepasste frontend.css

Sieht da jemand Handlungsbedarf für zukünftige WB-Versionen?

aber ganz sicher besteht da bedarf. wundere mich eh schon wo überall css zu finden ist, welches ruck zuck wieder überschrieben wird.
war der grundgedanke nicht mal die trennung solcher dinge. also nicht trennung im modul, sondern noch getrennter. teilweise kopiere ich mir teile der vielen frontend.css-en in meine template.css wo alles eigentlich hingehören sollte.

gruß dbs

[thorn]

Hallo,

• Man installiert ein Modul und passt z.B. die frontend.css an die Website an
• Man installiert ein Update für das Modul und überschreibt dabei die angepasste frontend.css

Vorschlag:
Ein System, ähnlich wie bei den Config-Files bei Debian.

- Bei der Erstinstallation des Modules wird eine MD5-Checksumme über die backend..., frontend...-Files gebildet und gespeichert (frontend.css -> frontend.css.md5).

- Bei einem Update wird geprüft ob die Checksumme noch übereinstimmt
  - stimmt sie noch überein, werden die Dateien überschrieben
  - stimmt die Checksumme nicht mehr überein (->Datei verändert) bleibt die alte Datei bestehen, und die neue wird als z.B. frontend.css.dist, und frontend.css.dist.m d5 gespeichert. Hinweis an den Benutzer.

Will man den "originalen" Zustand wieder herstellen, kopiert man
frontend.css.dist -> frontend.css
frontend.css.dist.m d5 -> frontend.css.md5

So mal als erste Idee.

------------------

Alternativ:

Die CSS-Dateien (frontend/backend) bekommen per default ein @import(frontend_local.css) ...

So hat man Modul-Einstellungen in der frontend.css, und die Änderungen vom Benutzer in der frontend_local.css


thorn.

Edit: Ergänzungen

[chio]

Ich mache das immer so:

Das Modul.zip enthält KEIN frontend.css oder frontend.js

in add.php bzw upgrade.php steht dann:

Code:

$mpath = WB_PATH.'/modules/members/';
if (!file_exists($mpath.'frontend.css')) { copy($mpath.'frontend.default.css', $mpath.'frontend.css') ; }
if (!file_exists($mpath.'frontend.js')) { copy($mpath.'frontend.default.js', $mpath.'frontend.js') ; }

Solange es keine gravierenden Änderungen gibt, wird auch das alte css/js herhalten.
Ansonsten kann man ja in der modify.php nach bestimmten Strings suchen und ggf auf wichtige Änderungen hinweisen.

[dbs]

ja, klingt sehr gut die idee von thorn.

[doc]

Hi,

ich mache von einem Modul mit dem Addon File Editor ein Backup, oder benenne einfach die frontend/backend.css Datei in frontend/backend_backup.css um, wenn ich am CSS des jeweiligen Moduls Veränderungen vorgenommen habe. Erst dann spiele ich das Update eines Moduls ein. So kann ich die CSS Dateien bei Bedarf umbenennen, oder meine manuellen Anpasungen wieder übernehmen.

Ist aber ein manueller Prozess. Eine etwas automatisiertere Lösung wie im Vorschlag von Thorn wäre wohl nicht das dümmste  

Doc

[thorn]

Hallo,

mal als Frage an die CSS-Experten hier. Ist dieser Vorschlag praktikabel, oder geht das nicht?
Wäre ja die einfachste Möglichkeit.

Die CSS-Dateien (frontend/backend) bekommen per default ein @import(frontend_local.css) ...
So hat man Modul-Einstellungen in der frontend.css, und die Änderungen vom Benutzer in der frontend_local.css

thorn.

[FrankH]

Hallo,

mal als Frage an die CSS-Experten hier. Ist dieser Vorschlag praktikabel, oder geht das nicht?
Wäre ja die einfachste Möglichkeit.

Die CSS-Dateien (frontend/backend) bekommen per default ein @import(frontend_local.css) ...
So hat man Modul-Einstellungen in der frontend.css, und die Änderungen vom Benutzer in der frontend_local.css

thorn.

Bin zwar bei weitem kein css-Experte, denke aber das müsste technisch gehen, wenn der Import am Ende der Datei steht?
Ist aber bei der Anpassung umständlicher zu handeln: Bisher kann man im Backend direkt die css-Datei anspringen und editieren. Bei einer zweiten css-Datei müsste man erst mal in die mitgelieferte schauen, was dort definiert ist, und die Bezeichner dann in die eigene Datei übernehmen und dort ändern.

[thorn]

Hallo,

Ist aber bei der Anpassung umständlicher zu handeln: Bisher kann man im Backend direkt die css-Datei anspringen und editieren. Bei einer zweiten css-Datei müsste man erst mal in die mitgelieferte schauen, was dort definiert ist, und die Bezeichner dann in die eigene Datei übernehmen und dort ändern.

Ah, daran hab ich nicht gedacht.

Spräche dann ja mehr für die erste Variante.


thorn.

[Ralf (Berlin)]

Das Problem betrifft nicht nur CSS Dateien von Modulen sondern auch Anpassungen in den jeweiligen Templates und Sprachdateien.

Ich habe mich deshalb schon gefragt, ob es nicht grundsätzlich besser wäre diese Daten in einer Tabelle abzulegen, dadurch würden Sie bei einem Update nicht zwangsläufig überschrieben. Ein Reset wäre genauso einfach möglich...

Einziger Knackpunkt ist, dass die CSS Datei dynamisch erzeugt werden müsste. Um zu verhindern, dass die CSS Datei bei jedem Aufruf neu geschrieben/geprüft wird könnte man die Erzeugung der CSS an Änderungen in der Tabelle knüpfen - manuelle Änderungen wären in diesem Fall auch noch möglich.

Was meint ihr dazu?

Gruß
Ralf

[chio]

So mal grundsätzlich:
Die Vorschläge laufen alle darauf hinaus, zu erkennen, DASS die Files geändert wurden. Aber was hilft das? Was macht man dann? Parsen und neu zusammenstoppeln? Sehr aufwändig und gefährlich.

Man muss den Leuten klar sagen: Das sind Systemdateien, wer darin herumbastelt, tut das auf eigenes Risiko. Ich greife ja auch meine Windows- DLLs nicht an.

zb frontend.css
Da sollen Styles drin sein, die das Modul braucht. Farbe / feste Breite hat da nichts verloren, außer es geht nicht anders.
Wer die Styles an sein Template anpassen will, der soll das in seiner template.css machen - da ist unten noch viel Platz dran.
Nicht umsonst empfehle ich dringend, das template.css im Template NACH den frontend.css aufzurufen. Dann kann man sehr leicht die Styles mit Copy-Paste rüberkopieren, später geladene identische Klassen überschreiben sich ja einfach.

[FrankH]

Ich habe mich deshalb schon gefragt, ob es nicht grundsätzlich besser wäre diese Daten in einer Tabelle abzulegen, dadurch würden Sie bei einem Update nicht zwangsläufig überschrieben.

Ja aber was bringt das? Falls das Update in die DB schreibt, werden die Daten ebenfalls überschrieben, falls nicht, wie nutzt das Modul dann die neuen Daten?