Asseticcssbundleimages Bundle Laravel Package

Getting Started

The problem it solves: Symfony's stock Assetic cssrewrite filter rewrites url(...) references only relative to real filesystem paths. When CSS lives inside a bundle (@AcmeBundle/Resources/public/css/app.css), the rewritten URLs point to the wrong location and images 404 in prod after assetic:dump. This bundle plugs that gap so image URLs inside bundle CSS resolve correctly.

Install

composer require smurfy/asseticcssbundleimages-bundle

Register the bundle in app/AppKernel.php:

public function registerBundles()
{
    $bundles = array(
        // ...
        new Smurfy\AsseticCssBundleImagesBundle\SmurfyAsseticCssBundleImagesBundle(),
    );
    // ...
}

Wire it into Assetic in app/config/config.yml — either as the cssrewrite filter itself or alongside it, depending on your Symfony version:

assetic:
    filters:
        cssrewrite: ~

You enable it by using the cssrewrite filter in your Twig stylesheets tag. Because the bundle swaps the filter implementation, image paths inside @Bundle CSS start being rewritten.

First use case — a bundle stylesheet that references images:

/* src/Acme/DemoBundle/Resources/public/css/main.css */
.logo { background: url('../images/logo.png') no-repeat; }

{% stylesheets filter='cssrewrite'
    '@AcmeDemoBundle/Resources/public/css/main.css' %}
    <link rel="stylesheet" href="{{ asset_url }}" />
{% endstylesheets %}

Before the bundle: /images/logo.png (wrong, no bundle prefix). After: the bundled, dumpable path under /bundles/acmedemo/....

Implementation Patterns

Pair with the cssrewrite filter, not in place of it. The intended pattern is filter='cssrewrite' on the stylesheets tag; the bundle hooks into that filter's behavior. If you're on an older Symfony where the bundle exposes its own filter name, register it explicitly:

assetic:
    filters:
        cssbundleimages:
            resource: '@SmurfyAsseticCssBundleImagesBundle/Resources/config/filters.yml'

and use filter='cssrewrite,cssbundleimages'.

Combine with less/sass/scss in the chain. Because the URL rewrite happens on the compiled CSS output, list the preprocessor filter first and cssrewrite after:

{% stylesheets filter='less,cssrewrite'
    '@AcmeDemoBundle/Resources/public/less/app.less' %}

Per-environment config. Standard Assetic advice applies — disable assetic.use_controller in prod, and let assetic:dump run against the rewritten paths. The bundle matters most precisely in the dump step; in dev, controller-served assets often mask the bug.

Multi-bundle layouts. Each @Bundle/Resources/public/css/*.css entry gets its own rewrite context. Keep the url() references relative to the CSS file as usual — the bundle just makes the base path resolve. Don't manually prefix with /bundles/...; that's what the filter is supposed to do.

Integrate with a base template. Centralize the include so all pages get rewritten URLs consistently:

{# base.html.twig #}
{% block head_styles %}{% endblock %}

{# page.html.twig #}
{% block head_styles %}
  {% stylesheets filter='cssrewrite' output='css/compiled/*.css'
      '@AcmeDemoBundle/Resources/public/css/main.css' %}
      <link rel="stylesheet" href="{{ asset_url }}">
  {% endstylesheets %}
{% endblock %}

The output= attribute matters: it pins the dumped filename and makes the rewrite deterministic.

Gotchas and Tips

Only handles @Bundle paths. This is a targeted fix for bundle-notation CSS sources. If your CSS is under web/css/ with plain relative URLs, stock cssrewrite already works — don't expect the bundle to do anything different there, and don't break your working setup by forcing it.

Symfony 2.x era. The bundle predates Symfony 3's Assetic decoupling and the Symfony 4+ replacement with Webpack Encore / AssetMapper. On a modern kernel you'll likely hit class-not-found errors on AsseticBundle internals. Verify the Symfony/Assetic bundle versions in composer.json before adopting; this is a legacy-stack tool.

Clear the cache after install. php app/console cache:clear (and cache:clear --env=prod) — Assetic caches compiled filter definitions. A stale cache is the most common reason the swap appears to do nothing.

Re-dump after CSS changes. Run php app/console assetic:dump --env=prod after any change to CSS or the filter config, and inspect web/css/*.css to confirm url(...) values now include the bundle prefix. If they don't, the filter isn't registered or isn't ordered correctly.

Watch url() forms. Data URIs, absolute http(s):// URLs, and url(/already/absolute.png) should be left untouched by any correct rewriter. If you see absolute URLs getting mangled, your filter chain is misordered (preprocessor emitting already-absolute paths).

Debug vs prod divergence. Assets served through the Assetic controller in dev can hide a broken rewrite because URLs still resolve against the app root. Always validate with assetic:dump + a fresh prod cache — that's the environment where 404s surface.

Low maintenance risk. With ~9 stars and no dependents, treat it as a small unmaintained shim. If you need it, consider vendoring the filter class into your project (or subclassing the Assetic CssRewriteFilter with a bundle-aware base-path resolver) so a Composer resolution failure on an old Symfony doesn't block you. The whole value is one filter — copy it if you can.

Extension point. If you must customize path resolution, the natural seam is replacing the filter registration with your own class extending the bundle's filter and overriding the base-path computation, wired via assetic.filters.<name>.class in config.yml.