WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: susigross on November 10, 2010, 01:41:03 PM
-
Hi,
mit der o.g. Funktion kann man z.B. die frontend.css eines Moduls laden lassen.
Die frontend.css liefert der Modulautor, der Besitzer der Website ändert sie aber wahrscheinlich.
Dann wird ein Update des Moduls eingespielt und... hoppla ... alle Änderungen weg?!?
Vorschlag:
Wenn Enduser die frontend.css anpasst, benennt er sie um in frontend.custom.css
Die Funktion register_frontend_m odfiles sieht dann nach, ob frontend.custom.css existiert.
Falls ja, wird der Link dazu eingebunden. Falls nein, wird der Link zu frontend.css eingebunden (sinnvollerweise auch nach einer Prüfung, ob die Datei existiert)
Meinungen zu diesem Vorschlag?
In welcher WB-Version wird er realisiert?
-
Hallo Frank,
die Idee ist sinnvoll und wurde vom user Chio bereits öfter realisiert.
Das sollte aber tatsächlich ins Core.
Ferner,da wir heute auch viel mehr mit JS Files arbeiten, wäreesgut,wenn man in den Backends der Module nicht nur die CSS Files, sondern auch die JS Files der Module bearbeiten könnte.
Außerdem finde ich schade, dass der Button zum CSS File hardgecodedes HTML mitbringt, welches sich über das Modul selbst nicht ändern läßt.
Gruß,
Stefek
-
Ah ja,
soweit ich mich erinnern kann, läuft es bei Chio aber anders rum.
Eine default.backend.css und eine backend.css
Müßte man notfaflls nachprüfen - aber das Konzept läuft auf das gleiche hinaus.
-
Meinungen zu diesem Vorschlag?
In welcher WB-Version wird er realisiert?
In der neuen Version( .dev ), die gerade in den Startlöchern steht, ist das bereits eingeplant. Ab der ( .dev1 ) wird dann auch eine zentrale Klasse zur Verwaltung dieser Files zur Verfügung stehen. Die reale Umsetzung der neuen Vorgaben liegt dann allerdings, logischerweise, bei den einzelnen Modulautoren.
Vorgesehen ist eine konsequente Trennung von Codefiles und Daten-/Einstellungsfiles. Als kleiner Nebeneffekt vereinfacht sich auch jedes automatische Backup, da veränderliche Daten nicht mehr überall zusammengesucht werden müssen, sondern zentral in einem Rutsch gesichert werden können.
-
Der Vorschlag mit der "custom" ist nicht nur gut sondern eigentlich ein "must have". Andere CMS verfahren in der Form schon länger.
Wenn Enduser die frontend.css anpasst, benennt er sie um in frontend.custom.css
Sollte es nicht möglich sein das die geänderte Datei beim Speichern automatisch als neue "custom" Datei gespeichert wird und die ursprüngliche Datei unangetastet liegen bleibt?
-
Hallo Werner,
Vorgesehen ist eine konsequente Trennung von Codefiles und Daten-/Einstellungsfiles.
Kannst Du bitte für mich die beiden Begriffe etwas ausführlicher definieren?
Codefiles und Daten-/Einstellungsfiles.
Du weißt ja, wie man manchmal auf Begriffe reagieren kann, die man nicht wirklich versteht.
(Alles andere hört sich gut an).
Gruß,
Stefek
-
Kannst Du bitte für mich die beiden Begriffe etwas ausführlicher definieren?
Codefiles und Daten-/Einstellungsfiles.
In der EDV... neuzeitlich auch IT genannt :wink:, gibt es die Trennung zwischen festen Daten(u.a. Code) und veränderlichen Daten (Bewegungsdaten) eigentlich schon immer.
Code:
der eigentliche PHP-Code eines Modules, der -normalerweise- nie geändert wird. (private Patches werden nicht berücksichtigt)
Variable Daten:
Alle Dateien, die dafür vorgesehen sind, zum Betrieb eines Modules in jeder Installation individuell angepasst zu werden. ( Templates, Stylesheets, irgendwelche Settings (die eigentlich in die DB gehören), Presets usw. usw.)
Vorteil beim Backup:
Es braucht kein einzelnes Modul mehr gesichert werden, sondern nur noch die DB sowie das Verzeichnis mit den var-Dateien. Bei einem Restore braucht einfach nur neu installiert zu werden (Core + alle Module) und danach die DB und das var-Verzeichnis wieder hochspielen... und fertig. Sind grob geschätzt so ca. 2.000 Dateien weniger, die gesichert werden müssen.
Vorteil beim Upgrade:
Es braucht keinerlei Rücksicht mehr auf individuell angepasste Dateien genommen werden. Einfach Upgrade hochspielen, aktivieren (upgrade-script) und fertig.
-
Sollte es nicht möglich sein das die geänderte Datei beim Speichern automatisch als neue "custom" Datei gespeichert wird und die ursprüngliche Datei unangetastet liegen bleibt?
Na ja, jeder ändert die Datei ja mit einem anderen Programm, der eine nimmt notepad, der andere das Backend...
Wenn eine custom da ist, wird ja die mitgelieferte nicht mehr gebraucht (außer um bei der nächsten Version durch Vergleich herauszubekommen, was sich geändert hat ;-) )
-
Hallo Werner.
Danke erstmal.
Das muss man sich dann anschauen, wenn es fertig ist.
Lese ich heraus, dass CSS teilweise in der DB gelagert wird? Ne, oder :roll:
Gruß,
Stefek
-
Lese ich heraus, dass CSS teilweise in der DB gelagert wird? Ne, oder
na, DAS ganz bestimmt nicht.
(jetzt habe ich ausnahmsweise mal Kommas in meinem Text gesetzt.. um die einzelnen Punkte auseinanderhalten zu können......... und jetzt interpretiert der die ned... :cry: )
-
Hallo Werner,
ja, ich finde den Satz in der Klammer etwas mißverständlich (wer verschachtelt denn auch Klammern :evil:).
Ok, aber zurück zu der Beschreibung:
"Variable Daten" => Daten-/Einstellungsfiles, alles was der Admin oder User macht, um das Programm anzupassen, einzustellen usw.
"Codefiles" => Die Moduldateien selbst. Also die PHP Files und ggf. einiges JS, was man braucht, um das Modul am laufen zu halten, bzw. die das Modul an sich ausmachen. (Die Files, die möglichst unangetastet bleiben sollten).
Variable Daten:
Alle Dateien, die dafür vorgesehen sind, zum Betrieb eines Modules in jeder Installation individuell angepasst zu werden. ( Templates, Stylesheets, irgendwelche Settings (die eigentlich in die DB gehören), Presets usw. usw.)
Also wundere ich mich, wie das sich für das Backup ändert.
Verschiedene Module haben tatsächlich verschiedene Zusatzfunktionalitä ten, um bestimmte "Customizations" (wie eben CSS, Presets, jQuery usw.) zu ermöglichen.
Ich will jetzt nicht davon anfangen, dass manche Module sogar einiges an Settings über PHP Files steuern, dass das Pfui ist, ist denen auch klar - aber manchmal auch zu verzeihen, vor allem, wenn es Einstellungen sind, die eh nur vom Admin zu setzen sind.)
Dann bin ich mal auf die neue Methode gespannt für das Backup.
Gruß,
Stefek