WBCE CMS Forum

WBCE CMS – Way Better Content Editing.

You are not logged in.

#1 04.03.2020 20:54:51

florian
Administrator

Frontend Final CSS

Ich habe da jetzt mal ein ganz rudimentäres Admintool zusammengestümpert*.
Das ist jetzt nur als Ideenskizze / Proof of concept zu betrachten.
Es möge sich bitte keiner nicht ernst genommen und/oder übergangen fühlen - es gibt immer mehrere Wege zum Ziel.

* Der Code stammt zu 90% aus der modules/edit_module_files.php (das ist die BE-Seite, die von manchen Modulen, die einen "Bearbeite CSS-Datei"-Button haben, noch verwendet wird). Im Tool wird die namensgebende CSS-Datei zum Bearbeiten im BE geöffnet (aber ohne Backup, Sprungmarken oder ähnliches). Ins Frontend wird sie mittels der I-Methode am Ende vom <head> eingefügt.

Last edited by florian (04.04.2020 15:17:46)


Sorgen sind wie Nudeln: man macht sich meist zu viele.

Offline

Liked by:

stefanek, boeseroeser

#2 04.03.2020 21:23:27

stefanek
Developer

Re: Frontend Final CSS

Sehr cool Florian.

Und damit demonstrierst Du auch gleichzeitig wie genial und überlegen WBCE gegenüber WB ist.

Hybride Module, in diesem Falle TOOL + SNIPPET.
Und die Verwendung der Insert Klasse.

Danke. Made my day.
Bin wirklich happy, dass Du das so gut verstanden hast.

Schöne Grüße,
Christian


“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale

Offline

Liked by:

florian

#3 05.03.2020 20:46:42

boeseroeser
Guest

Re: Frontend Final CSS

Florian, Held der Arbeit! - du hast dich wieder mal selbst übertroffen!

Das einzige, was ich anregen würde: Der Speicherort des CSS sollte NICHT im Modulordner sein, weil: wenn das Modul gelöscht wird, wird auch das css gelöscht. Und es könnte ja auch mehrere Module geben, die das gleiche CSS bearbeiten.
Vielleicht wäre das include-Verzeichnis besser?

#4 06.03.2020 11:58:31

florian
Administrator

Re: Frontend Final CSS

Danke für die Blumen. Tatsächlich war das in einer heldenhaften Stunde heruntergeklappert (bzw. zusammenkopiert).
Das Modul birgt einiges Sprengpotenzial, ein unbedarfter oder auch böswilliger Nutzer kann damit das gesamte Seitendesign zerstören.
Wenn dann das CSS vom Modul unabhängig verwaltet wird, könnte ein Troll das Modul installieren, alles in Comic Sans und pink auf grün formatieren, und dann flugs das Modul wieder deinstallieren - und der Seitenbetreiber müsste dann erstmal dahinter gekommen, wieso seine Seite auf einmal so verändert aussieht. Insofern halte ich es für besser, dass Admintool und CSS verbunden sind.


Sorgen sind wie Nudeln: man macht sich meist zu viele.

Offline

#5 06.03.2020 14:04:25

boeseroeser
Guest

Re: Frontend Final CSS

Ich liebe das Teil jetzt schon und habe es schon im Einsatz.

Eine Kundin möchte die Bilder in Wunderblock kleiner haben?:
.wub_aside_img .wub_inner img {width:80%; margin:28px 10% 0 10%;}
und fertig.
Element mit den Entwicklertools suchen, kopieren, ändern. Super!
Das wird auch den Support enorm erleichtern, weil man klare Angaben machen kann, ohne lange herum zu frickeln.

Ich denke: Ein unbedarfter Nutzer, der in den ellenlangen Modul/Template-Dateien herumfuhrwerkt, kann weit mehr Schaden anrichten als in diesem letztlich überschaubaren CSSchen.
Eine vergessene Klammer } im CSS kann oft fatale Auswirkungen haben - und bei JS ist sowieso der Teufel los. Aber: Das hier ist überschaubar, man kann es auch wieder löschen. Im CSS von zB Wunderblock ist ein Laie komplett verloren.

Hier bewirkt eine vergessene Klammer nur, dass das letzte Zipfelchen nicht mehr geht - verschmerzbar.

Man könnte machen: nur ein Admin darf da ran. Und Backup-Funktion,


Ich träume ja schon länger von einem "Custom-Center" (wie auch immer es heißt), wo man ein Logo hochladen kann, ein Headerbild (in mehreren Größen) - und mitgelieferten Templates, die das auch unterstützen. Das muss nicht die Welt kompliziert sein, nur für einfache Ansprüche.
Dieses Modul jetzt wäre eine tolle Ausgangsbasis dafür.
Alles was es noch braucht, wäre ein Konzept, einen Plan. Die Funktionen selbst kann man nachreichen.

und zu deiner Sorge:
Da gibt es VIELE Stellen, wo ein Troll etwas anstellen kann. CSS kann man schnell mal wo einfügen, JS auch.

Last edited by boeseroeser (06.03.2020 14:09:33)

#6 06.03.2020 14:19:37

stefanek
Developer

Re: Frontend Final CSS

boeseroeser wrote:

und zu deiner Sorge:
Da gibt es VIELE Stellen, wo ein Troll etwas anstellen kann. CSS kann man schnell mal wo einfügen, JS auch.

Ja, das sehe ich auch so.
Zudem lässt sich leicht herausfinden, aus welcher Datei Comic Sans oder pinkiebunti kommt.

Ich würde die Datei in den var Ordner speichern.
Oder ins Template (geht ja auch).


“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale

Offline

#7 06.03.2020 14:34:49

boeseroeser
Guest

Re: Frontend Final CSS

Wenn ich mal weiter schwärme (Logo, Header, JS...), wäre das Medien-Verzeichnis das beste, in einem definierten Ordner, /custom-files oder so.
Das Verzeichnis /var hat man glaube ich nicht so auf dem Radar.
Und ja: Auch /templates/custom-files oder so kann ich mir vorstellen.

Last edited by boeseroeser (06.03.2020 14:38:09)

#8 06.03.2020 14:55:25

stefanek
Developer

Re: Frontend Final CSS

Stimmt, der Ordner /var/ ist ansonsten vom Backend aus mit den Bordmitteln nicht zugänglich.


“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale

Offline

#9 06.03.2020 15:01:06

boeseroeser
Guest

Re: Frontend Final CSS

Sollen diese Daten mit Bordmitteln zugänglich sein?
/include ist auch nicht zugänglich. GIbt es eigentlich eine Definition, wofür /include und /var genau zuständig sind? bei den anderen ist es ja klar.

#10 06.03.2020 15:10:58

florian
Administrator

Re: Frontend Final CSS

Medienverzeichnis:
halte ich für nicht gut, da wird gerne mal "aufgeräumt" oder "umsortiert", und dann funktioniert der ganze Spaß nicht mehr. Ich weiß, dass in der Medienverwaltung Verzeichnisse mit Punkt davor nicht angezeigt werden, aber der CKE schert sich darum z.B. nicht (erlaubt allerdings auch nicht den Zugriff darauf).
Template-Verzeichnis:
auch nicht so richtig gut. Wird das Template geändert, sind alle Anpassungen weg.
var:
Beste Lösung, weil für genau solche Dinge gedacht. Idee des var-Ordners:

This is a new folder, it was made to offer a place to store settings, templates and more. The most important thing is that all things stored here normally are not affected by uninstall or upgrade in any way.

Wobei natürlich auch das Tool selbst dahin gehend erweitert werden könnte, dass Verzeichnis und/oder Dateiname der fraglichen CSS-Datei selbst und beliebig festgelegt werden können.


Sorgen sind wie Nudeln: man macht sich meist zu viele.

Offline

Liked by:

stefanek

#11 06.03.2020 15:19:46

stefanek
Developer

Re: Frontend Final CSS

Ordner /var/

Diese Geschichte mit dem Ordner /var/ kommt noch von WB.
Die Idee war damals, alles Moduldateien die Veränderungen unterliegen (also variabel sind) dort abzuspeichern.
Das könnten JS/CSS Dateien sein aber auch anderweitige Template Dateien etc. ppp.

Diese würden dann statt im Ordner modules/MeinModul
im Ordner var/modules/MeinModul liegen

Die Überlegung war die Logik der Module von den vom Seitenbetreiber gemachten Änderungen zu trennen, da es grade bei Updates öfter Schwierigkeiten verursacht.

Beim Upgrade könnte man so ein Modul dessen Variablen woanders liegen komplett löschen und neu installieren.

Hat sich aber nicht durchgesetzt. Obwohl ich habe mir WB seit über 3 Jahren nicht angeschaut und kann keine gut informierte Aussage treffen.

Ob ich es für sinnvoll halte? Jein.
Auf der anderen Seite ist es gut genau diese Trennung zu machen,
auf der anderen Seite ist das mit viel Arbeit verbunden die Module dafür anzupassen sodass alles wie vorgesehen läuft.
Bei WBCE verfolgen wir das also nicht weiter.

Es wird aber dieser Ordner von einigen Modulen verwendet. Eins davon ist Ruud's errorlogger AdminTool.
Wobei man könnte die Inhalte des Moduls auch in den /temp/ Ordner schreiben.

Ordner /include/

Hier kommen hauptsächlich Bibliotheken fremder Entwicklung rein.
Sowas wie Twig, phpLib, jQuery, PHPMailer.
Die Überlegung ist, dass hier kein Betreiber was zu suchen hat und dass es keinen Sinn gibt es als Modul bereitzustellen weil die jeweilige Version des CMS diese Bibliotheken in GENAU DIESEM ZUSTAND benötigt. Das sind also Bibliotheken ohne die der Core nicht wirklich gut auskommt.

Ja, es gibt auch Bibliotheken für die bestimmte Entwickler Module bauen damit sie dann übers Backend hochgeladen werden, aber hier handelt es sich dann um Bibliotheken ohne die das jeweilige Modul des Entwicklers nicht auskommt der Core aber schon.

In anderen Systemen heißt dieser Ordner /vendor/
Es handelt sich hauptsächlich um 3rd Party Bibliotheken, Scripte etc.

Gruß,
Christian


“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale

Offline

#12 06.03.2020 15:40:58

boeseroeser
Guest

Re: Frontend Final CSS

florian wrote:

Medienverzeichnis:
halte ich für nicht gut, da wird gerne mal "aufgeräumt" oder "umsortiert", und dann funktioniert der ganze Spaß nicht mehr. Ich weiß, dass in der Medienverwaltung Verzeichnisse mit Punkt davor nicht angezeigt werden, aber der CKE schert sich darum z.B. nicht (erlaubt allerdings auch nicht den Zugriff darauf).
Template-Verzeichnis:
auch nicht so richtig gut. Wird das Template geändert, sind alle Anpassungen weg.
var:
Beste Lösung, weil für genau solche Dinge gedacht. Idee des var-Ordners:

This is a new folder, it was made to offer a place to store settings, templates and more. The most important thing is that all things stored here normally are not affected by uninstall or upgrade in any way.

Wobei natürlich auch das Tool selbst dahin gehend erweitert werden könnte, dass Verzeichnis und/oder Dateiname der fraglichen CSS-Datei selbst und beliebig festgelegt werden können.

Du hast Kunden, die im Medien-Verzeichnis aufräumen? ;-)

Der Punkt vor einem Verzeichnis-Namen bewirkt - genauso wie bei .htaccess - dass die Datei/das Verzeichnis im Directory Listing nicht dargestellt wird und dass man nicht direkt daraus zugreifen kann. Das ist generell eine Linux-Sache. Per Script kann man diese Dateien natürlich schon lesen.

MIt "Template-Verzeichnis" haben Christian und ich wohl eher an /templates gedacht, also nicht ein Verzeichnis eines Templates. Das ginge ja auch gar nicht, weil: welches denn?

Aber gerne ein Verzeichnis /var/schoenername/ für all das, was wir noch vorhaben ;-)

#13 07.03.2020 12:30:00

florian
Administrator

Re: Frontend Final CSS

Im Anhang die Version 0.2.
In der module_settings.php kann angegeben werden, in welchem Verzeichnis und unter welchem Namen die CSS-Datei gespeichert werden soll.
Standardvorgabe ist /var/custom.css

Last edited by florian (04.04.2020 15:17:57)


Sorgen sind wie Nudeln: man macht sich meist zu viele.

Offline

Liked by:

stefanek, boeseroeser, jean

#14 09.03.2020 13:59:50

boeseroeser
Guest

Re: Frontend Final CSS

Danke!

Die neue Version zeigt ein unangenehmes Verhalten:
Leerzeile werden gelöscht und vor dem ersten Wort "staunen" sich Tabs, mit jedem Speichern mehr.

#15 09.03.2020 14:33:28

florian
Administrator

Re: Frontend Final CSS

Ja, ist mir auch aufgefallen. Das passiert, wenn die CSS-Datei vom Tool neu angelegt wird. Warum das so ist, weiß ich nicht.
Wenn man einmal einen Eintrag vorgenommen hat und dann die Tabs bzw. Leerzeile löscht, kommen die aber auch nicht wieder rein.

Edit: Lässt sich leicht beheben. In der tool.php alle Umbrüche, Tabs und Leerzeichen bei <textarea>...</textarea> entfernen, also so:

<textarea  id="code_area" name="css_data" cols="100" rows="25" wrap="VIRTUAL" style="margin:2px;width:100%;"><?php echo htmlspecialchars($css_content);?></textarea>

Last edited by florian (09.03.2020 14:47:18)


Sorgen sind wie Nudeln: man macht sich meist zu viele.

Offline

#16 09.03.2020 14:58:59

florian
Administrator

Re: Frontend Final CSS

Neue Version hängt an.
module_settings.php wird beim Update nicht überschrieben.

Edit: Anhang entfernt, Modul im AOR verfügbar

Last edited by florian (05.05.2020 07:44:12)


Sorgen sind wie Nudeln: man macht sich meist zu viele.

Offline

#17 09.03.2020 15:26:59

boeseroeser
Guest

Re: Frontend Final CSS

Leerzeilen sollen ja sein, um das etwas zu strukturieren.

#18 09.03.2020 15:44:16

mrbaseman
Developer

Re: Frontend Final CSS

Das ist im "remove system PH" Filter momentan fest verdrahtet. Du kannst dort aber im Quellcode die Zeile auskommentieren.
Wenn es gewünscht ist, können wir die beiden Schritte (Platzhalter rauslöschen und Leerzeilen löschen) auch in zwei separate Filter packen, die man dann nach eigenem Gusto an- und ausschalten kann.

Sorry, ich hatten den Kontext nicht gelesen. Ich hab nur auf den RSS Feed reagiert und dachte es ginge um die Ausgabe im Frontend.

Last edited by mrbaseman (09.03.2020 16:29:10)

Offline

#19 09.03.2020 15:50:19

florian
Administrator

Re: Frontend Final CSS

Nein, das gilt auch im Backend. Genau daran liegt es, d.h. wenn ich den Filter deaktiviere, bleiben die Leerzeilen drin, sonst nicht.
Danke für den Verweis auf den Filter. Ich bin eben schon fast kirre geworden, weil ich nicht dahinter gekommen bin, wo die Leerzeilen auf der Strecke bleiben.


Sorgen sind wie Nudeln: man macht sich meist zu viele.

Offline

#20 09.03.2020 16:43:01

mrbaseman
Developer

Re: Frontend Final CSS

na, dann ist ja doch gut, dass ich immer ein bisschen mitlese und dazuwischen funke, wenn bei mir im Hirn was klingelt  tongue

kommentier einfach diese Zeile aus und in einer künftigen Version können wir das entweder in einen separaten Filter ziehen oder vielleicht noch besser als konfigurierbare Einstellung innerhalb dieses Filters umsetzen

Offline

Liked by:

florian

#21 09.03.2020 17:55:53

boeseroeser
Guest

Re: Frontend Final CSS

In der ersten Version blieben die leerzeilen erhalten. Glaub ich

Last edited by boeseroeser (09.03.2020 17:56:53)

#22 09.03.2020 18:13:18

florian
Administrator

Re: Frontend Final CSS

nein.


Sorgen sind wie Nudeln: man macht sich meist zu viele.

Offline

#23 10.03.2020 18:42:40

Slugger
Member

Re: Frontend Final CSS

Wenn ich den Inhalt leere und ohne Code abspeichere, kommt folgende Meldung "Fehler beim öffnen der Datei"


Hoster: ALL-INKL *** Grundsätzliche WBCE Konfig ***
WBCE: 1.5.4 • BE: 2.1.0 • PHP: 8.1.16 * 1. Projekt: FE: Simple responsive • BE: Argos * 2. Projekt: FE: hortal • BE: Argos * 3. Projekt: FE: WBCEZon • BE: Argos * 4. Projekt: FE: WBCETik • BE: Argos
Status Projekt 1-4:  OK

Offline

#24 10.03.2020 18:45:28

florian
Administrator

Re: Frontend Final CSS

Ja, weil die Datei leer ist. Warum sollte man eine leere Datei speichern?

Edit: zum Wording: Ich war zu faul, extra Sprachvariablen anzulegen und habe das genommen, was am ehesten passte. (Ein zutreffenderes - und richtiger geschriebenes -"Fehler beim Speichern der Datei" gibt es in der DE.php leider nicht)

Last edited by florian (10.03.2020 18:51:36)


Sorgen sind wie Nudeln: man macht sich meist zu viele.

Offline

#25 10.03.2020 21:13:30

boeseroeser
Guest

Re: Frontend Final CSS

Mir persönlich wäre es schon lieber, wenn die Leerzeilen erhalten bleiben. Und zwar insgesamt.

Ich weiß schon: Ihr habt die Class "awsome_shit_you_gotta_have" entdeckt und unbedingt einbauen müssen (ohne recht zu wissen, was sie tut), und die Leerzeilen-Hackerbande ist _auch_ recht umtriebig, und überhaupt: Man muss diese User-Gfrastsackeln schon ein bissel erziehen...

Aber ich bin halt ein sturer alter Mann, der seinen Kram gerne ein wenig gruppiert.
big_smile

Board footer

up