Pfad der Assets in CSS-Dateien in Symfony 2

Problem

Ich habe eine CSS- Datei mit einigen Pfaden (für Bilder, fonts, etc .. url(..) ).

Meine Pfadstruktur ist wie folgt:

 ... +-src/ | +-MyCompany/ | +-MyBundle/ | +-Resources/ | +-assets/ | +-css/ | +-stylesheets... +-web/ | +-images/ | +-images... ... 

Ich möchte auf meine Bilder im Stylesheet verweisen.

Erste Lösung

Ich habe alle Pfade in der CSS-Datei in absolute Pfade geändert. Dies ist keine Lösung, da die Anwendung auch in einem Unterverzeichnis arbeiten sollte (und muss!).

Zweite Lösung

Verwenden Sie Assetic mit filter="cssrewrite" .

Also habe ich alle meine Pfade in meiner CSS-Datei geändert

 url("../../../../../../web/images/myimage.png") 

um den tatsächlichen Pfad von meinem Ressourcenverzeichnis zum Verzeichnis /web/images darzustellen. Dies funktioniert nicht, da cssrewrite folgenden Code erzeugt:

 url("../../Resources/assets/") 

Das ist offensichtlich der falsche Weg.

Nach dem assetic:dump dieser Pfad erstellt, der immer noch falsch ist:

 url("../../../web/images/myimage.png") 

Der Zweigcode von Assetic:

 {% stylesheets '@MyCompanyMyBundle/Resources/assets/css/*.css' filter="cssrewrite" %}  {% endstylesheets %} 

Aktuelle (dritte) Lösung

Da alle CSS-Dateien in /web/css/stylexyz.css , habe ich alle Pfade in der CSS-Datei so geändert, dass sie relativ sind:

 url("../images/myimage.png") 

Diese (schlechte) Lösung funktioniert, außer in der dev Umgebung: Der CSS-Pfad ist /app_dev.php/css/stylexyz.css und der daraus resultierende Image-Pfad ist /app_dev.php/images/myimage.png , woraus resultiert eine NotFoundHttpException .

Gibt es eine bessere und funktionierende Lösung?

Solutions Collecting From Web of "Pfad der Assets in CSS-Dateien in Symfony 2"

Ich bin auf das sehr, sehr gleiche Problem gestoßen.

Zusamenfassend:

  • Bereit, das ursprüngliche CSS in einem “internen” Verzeichnis zu haben (Resources / assets / css / a.css)
  • Bereit, die Bilder im “public” -Dir zu haben (Resources / public / images / devil.png)
  • Möchte man diesen Zweig nutzen, wird er in web / css / a.css neu kompiliert und auf das Bild in /web/bundles/mynicebundle/images/devil.png gerichtet

Ich habe einen Test mit ALLEN möglichen (gesunden) Kombinationen der folgenden gemacht:

  • @notation, relative Notation
  • Parsen mit Cssrewrite, ohne es
  • CSS-Hintergrund im Vergleich zum direkten -Tag src = zum selben Bild als CSS
  • CSS-Analyse mit Assetic und auch ohne Analyse mit direkter Ausgabe von assetic
  • Und das alles multipliziert mit einem “public dir” (als Resources/public/css ) mit dem CSS und einem “privaten” Verzeichnis (als Resources/assets/css ).

Dies gab mir insgesamt 14 Kombinationen auf dem gleichen Zweig, und diese Route wurde von gestartet

  • “/app_dev.php/”
  • “/app.php/”
  • und “/”

Dies ergibt 14 x 3 = 42 Tests.

Darüber hinaus wurde alles in einem Unterverzeichnis getestet, so dass es keine Möglichkeit gibt, mit absoluten URLs zu täuschen, weil sie einfach nicht funktionieren würden.

Die Tests waren zwei unbenannte Bilder und dann divs mit dem Namen ‘a’ bis ‘f’ für das CSS, das aus dem öffentlichen Ordner erstellt wurde und für die aus dem internen Pfad erstellten ‘g’ bis ‘l’.

Ich habe folgendes beobachtet:

Nur 3 der 14 Tests wurden auf den drei URLs angemessen gezeigt. Und NONE stammt aus dem “internen” Ordner (Ressourcen / Assets). Es war eine Voraussetzung, um das freie CSS PUBLIC zu haben und dann mit assemt FROM dort zu bauen.

Dies sind die Ergebnisse:

  1. Ergebnis gestartet mit /app_dev.php/ Ergebnis gestartet mit /app_dev.php/

  2. Ergebnis gestartet mit /app.php/ Ergebnis gestartet mit /app.php/

  3. Ergebnis gestartet mit / Bildbeschreibung hier eingeben

Also … NUR – Das zweite Bild – Div B – Div C sind die erlaubten Syntaxen.

Hier ist der TWIG-Code:

   {% stylesheets 'bundles/commondirty/css_original/container.css' filter="cssrewrite" %}  {% endstylesheets %} {# First Row: ABCDEF #}   {% stylesheets 'bundles/commondirty/css_original/c.css' filter="cssrewrite" %}  {% endstylesheets %} {% stylesheets 'bundles/commondirty/css_original/d.css' %}  {% endstylesheets %} {% stylesheets '@CommonDirtyBundle/Resources/public/css_original/e.css' filter="cssrewrite" %}  {% endstylesheets %} {% stylesheets '@CommonDirtyBundle/Resources/public/css_original/f.css' %}  {% endstylesheets %} {# First Row: GHIJKL #}   {% stylesheets '../src/Common/DirtyBundle/Resources/assets/css/i.css' filter="cssrewrite" %}  {% endstylesheets %} {% stylesheets '../src/Common/DirtyBundle/Resources/assets/css/j.css' %}  {% endstylesheets %} {% stylesheets '@CommonDirtyBundle/Resources/assets/css/k.css' filter="cssrewrite" %}  {% endstylesheets %} {% stylesheets '@CommonDirtyBundle/Resources/assets/css/l.css' %}  {% endstylesheets %}   

Devil Devil

A
B
C
D
E
F

G
H
I
J
K
L

Die container.css:

 div.container { border: 1px solid red; padding: 0px; } div.container img, div.container div { border: 1px solid green; padding: 5px; margin: 5px; width: 64px; height: 64px; display: inline-block; vertical-align: top; } 

Und a.css, b.css, c.css, etc: alle identisch, nur die Farbe und den CSS-Selektor ändern.

 .a { background: red url('../images/devil.png'); } 

Die Struktur “Verzeichnisse” ist:

Verzeichnisse Verzeichnisse

All das kam, weil ich die einzelnen Originaldateien nicht der Öffentlichkeit zugänglich machen wollte, speziell wenn ich mit “weniger” Filter oder “sass” oder ähnlichem spielen wollte … Ich wollte nicht meine “Originale” veröffentlichen, nur die kompiliert.

Aber es gibt gute Nachrichten . Wenn Sie nicht das “Ersatz-CSS” in den öffentlichen Verzeichnissen haben wollen … installieren Sie sie nicht mit --symlink , sondern --symlink wirklich eine Kopie. Sobald “assetic” das zusammengesetzte CSS erstellt hat, können Sie das ursprüngliche CSS aus dem Dateisystem löschen und die Bilder belassen:

Zusammenstellungsprozess Zusammenstellungsprozess

Hinweis Ich tue dies für die Umgebung --env=prod .

Nur ein paar abschließende Gedanken:

  • Dieses gewünschte Verhalten kann erreicht werden, indem die Bilder im Verzeichnis “public” in Git oder Mercurial und “css” im Verzeichnis “assets” gespeichert werden. Das heißt, anstatt sie in “public” zu haben, wie in den Verzeichnissen gezeigt, stellen Sie sich vor, dass a, b, c … sich in den “Assets” statt in “public” befinden, als Ihr Installer / Deployer (wahrscheinlich ein Bash- Skript) Um das CSS vorübergehend in das “public” -Dir zu setzen, bevor assets:install ausgeführt wird, dann assets:install , dann assetic:dump und dann das Entfernen von CSS aus dem öffentlichen Verzeichnis automatisieren, nachdem assetic:dump ausgeführt wurde. Dies würde GENAU das gewünschte Verhalten in der Frage erreichen.

  • Eine andere (unbekannte wenn möglich) Lösung wäre es zu untersuchen, ob “assets: install” nur “public” als Quelle annehmen kann oder auch “assets” als Quelle für die Veröffentlichung übernehmen könnte. Das würde helfen, wenn es bei der Entwicklung mit der Option --symlink installiert wird.

  • Wenn wir die Entfernung aus dem Verzeichnis “public” skripten, verschwindet die Notwendigkeit, sie in einem separaten Verzeichnis (“Assets”) zu speichern. Sie können in unserem Versionskontrollsystem innerhalb von “öffentlich” leben, da sie bei der Bereitstellung in der Öffentlichkeit fallen gelassen werden. Dies ermöglicht auch die --symlink Nutzung.

ABER JEDERZEIT, ACHTUNG JETZT: Da jetzt die Originale nicht mehr da sind ( rm -Rf ), gibt es nur zwei Lösungen, nicht drei. Das Arbeitsdiv “B” funktioniert nicht mehr, da es sich um einen Aufruf von asset () handelte, unter der Annahme, dass das ursprüngliche Asset vorhanden war. Nur “C” (das kompilierte) wird funktionieren.

Also … es gibt NUR einen ENDGÜLTIGEN GEWINNER: Div “C” erlaubt GENAU, was in dem Thema gefragt wurde: Um kompiliert zu werden, respektiere den Pfad zu den Bildern und stelle die ursprüngliche Quelle der Öffentlichkeit nicht zur Verfügung.

Der Gewinner ist C

Der Gewinner ist C

Der cssrewrite-Filter ist vorerst nicht mit der @ bundle-Notation kompatibel. Sie haben also zwei Möglichkeiten:

  • Verweisen Sie auf die CSS-Dateien im console assets:install --symlink web (nach: console assets:install --symlink web )

     {% stylesheets '/bundles/myCompany/css/*." filter="cssrewrite" %} 
  • Verwenden Sie den cssembedded-Filter, um Bilder im CSS so einzubetten.

     {% stylesheets '@MyCompanyMyBundle/Resources/assets/css/*.css' filter="cssembed" %} 

Ich werde posten, was für mich funktioniert hat, dank @ xavi-montero.

Legen Sie Ihr CSS in das Resource/public/css Verzeichnis Ihres Bundles und Ihre Bilder in ” Resource/public/img .

Ändern Sie in Ihrem Layout die assetischen Pfade in das Formular 'bundles/mybundle/css/*.css' .

config.yml css_rewrite in config.yml die Regel css_rewrite zu assetic hinzu:

 assetic: filters: cssrewrite: apply_to: "\.css$" 

Installieren Sie nun Assets und kompilieren Sie mit assite:

 $ rm -r app/cache/* # just in case $ php app/console assets:install --symlink $ php app/console assetic:dump --env=prod 

Das ist gut genug für die Entwicklungsbox und --symlink ist nützlich, so dass Sie Ihre Assets nicht neu installieren müssen (zum Beispiel wenn Sie ein neues Image hinzufügen), wenn Sie über app_dev.php .

Für den Produktionsserver habe ich einfach die Option ‘–symlink’ (in meinem Bereitstellungsskript) entfernt und diesen Befehl am Ende hinzugefügt:

 $ rm -r web/bundles/*/css web/bundles/*/js # all this is already compiled, we don't need the originals 

Alles ist getan. Damit können Sie Pfade wie diese in Ihren .css-Dateien verwenden: ../img/picture.jpeg

Ich hatte das gleiche Problem und habe gerade versucht, das Folgende als Workaround zu verwenden. Scheint so weit zu arbeiten. Sie können sogar eine Dummy-Vorlage erstellen, die nur Verweise auf all diese statischen Assets enthält.

 {% stylesheets output='assets/fonts/glyphicons-halflings-regular.ttf' 'bundles/bootstrap/fonts/glyphicons-halflings-regular.ttf' %}{% endstylesheets %} 

Beachten Sie das Fehlen einer Ausgabe, was bedeutet, dass nichts in der Vorlage angezeigt wird. Wenn ich Assetic: Dump ausführen, werden die Dateien an den gewünschten Speicherort kopiert, und das CSS enthält Arbeit wie erwartet.

Wenn es jemandem helfen kann, haben wir viel mit Assetic gekämpft, und wir machen jetzt im Entwicklungsmodus folgendes:

  • config_dev.yml Sie sich wie in Dumping-Asset-Dateien in der Dev-Umgebung so in config_dev.yml , wir haben kommentiert:

     #assetic: # use_controller: true 

    Und in routing_dev.yml

     #_assetic: # resource: . # type: assetic 
  • Geben Sie die URL im Webstamm als absolut an. Beispiel: background-image: url("/bundles/core/dynatree/skins/skin/vline.gif"); Hinweis: Unser vhost-Webstamm verweist auf web/ .

  • Keine Verwendung von Cssrewrite-Filter

I offen css / js plugin mit Composer verwalten, die es unter Hersteller installieren. Ich verlinke diese auf das Web / Bundles-Verzeichnis, so dass Compiler-Update-Bundles nach Bedarf erstellt werden können.

Beispiel:

1 – symlink einmal überhaupt (benutze command fromweb / bundles /

 ln -sf vendor/select2/select2/dist/ select2 

2 – Verwenden Sie Asset, wo benötigt, in Zweig Vorlage:

 {{ asset('bundles/select2/css/fileinput.css) }} 

Grüße.