Module mit eigenem CSS

Kann ich irgendwie in der metadata.php angeben, dass eine zusätzliche CSS-Datei verwendet werden soll?

Hintergrund: Ich arbeite gerade an einem Modul, bei dem ich einzelne Blöcke austausche. Generell sollte man ja das im Modul benötigte CSS im Modulverzeichnis unter /out/src/css/ ablegen und kann es dann mit [{oxstyle include=$oViewConf->getModuleUrl(“modul_name”, “out/src/css/modul_css.css”)}] einbinden.

Da ich aber Blöcke ändere (die mehrfach aufgerufen werden), wäre das Einbinden an dieser Stelle nicht sonderlich sauber.

Nein, mir keine andere Möglichkeit bekannt.

Eine Idee wäre, wenn Du ein extra Block für die Einbindung Deiner CSS Datei nimmst. Dann kommst mit Deinen anderen Blöcken nicht in Konflikt.

Die Tage soll es anscheinend einen Blogpost zu OXID eShop Version 7 geben, dort ändert sich bei den Modulen wohl, dass diese im vendor Verzeichnis bleiben und z.B. CSS bzw. Assets nur noch ins Shop-Root Verzeichnis source kopiert werden bei Installation. Inwieweit sich dann Angaben in metadata.php ändern abwarten.

1 Like

ich kenne da noch eine Möglichkeit eigne CSS und JS über PHP einzubinden, das erfordert aber, dass deine PHP Funktion iregdnwann beim Rendern der Seite aufgerufen wird.

Hier mache ich das für JS Dateien, funktioneirt aber genau so für CSS, du musst nur gucken, in welche globale Varible die Stylesheets im oxstyle gepackt werden.

2 Likes

Ja, die Idee, ein anderes .tmp für den Zweck zu kapern hatte ich auch schon.
Kann ich irgendwie sagen “füge das soundso nach dem block blabla ein”? Das wäre dann auch halbwegs gegen spätere Änderungen am Original-Template sicher.

@vanilla_thunder wäre auch eine Idee, wäre dann auch nicht auf ein bestimmtes Theme angewiesen.

Naja, dafür ist doch die metadata da.
Block einfügen (ab metadata 2.1 kann das theme bestimmen) und Deinen Code unter [{$smarty.block.parent}]
Und in oxscript die priority nicht zu vergessen. Damit kannst sicher gehen, dass ein Skript später geladen wird, als andere.

Wenn ich es richtig verstanden habe, überschreibe ich damit aber den Block, oder?
Sorry, alles was ich bisher gesucht habe liefert mit veraltete Links, die ins leere führen :-/

Mit obigem (einzusetzen in der Datei, die den Block ersetzt) wird der “Original-Code” im zu überschreibenden Block geladen. Darunter (oder darüber) setzt einfach den Zusatz.

1 Like

So, kurzes Update. Ich habe für das CSS tatsächlich noch ein anderes Template gekapert, das ich - wie sich herausstellte - sowieso noch brauchte.

Das alles wäre natürlich leichter, wenn gemachte Änderungen auch gleich sichtbar wären und nicht erst nach löschen des tmp-Verzeichnisses. Und das Modul aus- und wieder einschalten. Oh, und die oe-console oe:module habe ich auch noch benutzt. Und den Browsercache geleert. Also irgendwas in dem Zusammenspiel lässt dann irgendwann die Änderungen sichtbar werden. Kaffe dazwischen trinken scheint auch nicht zu schaden…

ja, die Änderungen müssen erst aktiv installiert werden

That is the reason why nothing is going on here anymore. It’s only for technicians and people who have a lot of time. Shit composer.

Hab’ ich ja gemacht. Wobei es natürlich tatsächlich passieren kann, dass ich mal vergesse, das tmp zu leeren, oder der Browser hat noch was im Cache. Ich habe trotzdem das Gefühl, dass es manchmal etwas dauert, bis ich die Änderungen sehe. Das ist dann der berühmte Kaffee zwischendurch, nach dem dann alles auf einmal wie per Wunderhand funktioniert.

Benutzerfreundlich ist das allerdings nicht mehr, da muss ich leider @Gerome recht geben. Andere Systeme schaffen das ja auch, es schlank zu halten. Anderseits müssen dann die Kunden bei Änderungen immer zu mir kommen. Frage ist hier allerdings: möchte ich das überhaupt? Eigentlich kostet es mich mehr Zeit so Kleinkram zu machen, als dass es später tatsächlich als Gewinn in der Kasse landet. Naja, C’est la vie