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

So, kurzer Zwischenstand: Inzwischen funktioniert das Modul ziemlich sauber. Allerdings bin ich auf eine kleine Hürde gestoßen:
Ich möchte in einem Template eine css-Datei einbinden:
<link rel="stylesheet" type="text/css" href="mein_modul.css">

Der Link der letztendlich zusammengebaut wird ist aber nicht localhost/oxid_6_2/source/… sondern
die-spätere-website.de/
in der confic.inc.php steht localhost drin. Woher bitte kommt die Referenz zur späteren Website?

Wie meinst Du das?

Die Referenz kommt bei der Community Edition aus der config.inc.php und wenn wie oben beschrieben mit getModuleUrl() arbeitest kümmert sich die Methode um Absoluten-Pfad bzw. Homepage Pfad.

Vielleicht hilft ein Blick ins Cheat OXID eShop cheat sheet • OXIDforge

1 Like

Also, damit das Modul später sauber aufgebaut und wartungsfreundlich ist, möchte ich alle verwendeten Styles in einer gesonderten css auslagern. Diese rufe ich aus einem Template des Moduls auf:
<link rel="stylesheet" type="text/css" href="mein_modul.css">

Wenn ich die Seite untersuche, referenziert er aber nicht auf localhost sondern auf die (spätere) Domain.
Gerade probiert: wenn ich
<link rel="stylesheet" type="text/css" href="http://localhost/...blabla.../mein_modul.css">
mache, funktioniert es. Ich hätte es aber gerne nicht absolut sondern relativ adressiert. Ich habe keine Erklärung dafür, woher hier die url der richtigen Domain kommt.

ggf ist da ein base tag im code?
https://www.w3schools.com/tags/tag_base.asp

2 Likes

Das wars. In der base.tpl stand tatsächlich die feste URL drin. Kann mich zwar nicht erinnern, die da mal reingeschrieben zu haben (oder wird die dynamisch erzeugt? Naja, ich werde es vermutlich da mal reingetippt haben). Egal, habe das jetzt mit [{$oViewConf->getBaseDir()}] ersetzt und siehe da - es funktioniert :slight_smile:
Aufruf sieht jetzt so aus:
<link rel="stylesheet" type="text/css" href="modules/[Pfad zur CSS-Datei]/log4price.css">

Nebenbei: ich hatte eigentlich erwartet, dass hier relativ zur aufrufenden Datei referenziert wird, aber es wird wirklich vom Wurzelverzeichnis referenziert.

Wenn alle Pfade relativ sein sollen, kannst in der config.inc.php versuchen, statt der URL einen Slash einzutragen.

Wäre eine Idee, wobei der Pfad zum Modul ja so bleibt, insofern bereitet es mir keine Kopfschmerzen, wenn ich den relativ zur URL setzte.