Wrong URL for images in CSS on yarn dev

sage
,
1

I’m having this issue and my .setPublicPath() in bud.config.mjs file is pointing to the right path for the theme public directory:

/**
 * URI of the `public` directory
 */
 .setPublicPath("/app/themes/sage/public/")

When I run yarn build the URL to my background image in the resulting CSS is correct and it loads as expected:

// https://sitename-wp.lndo.site/app/themes/sage/public/css/app.d981f3.css

.bg-chevron {
    background-image: url(/app/themes/sage/public/images/chevron.ae0977.svg);
}

But, when I run yarn dev it doesn’t sets the background-image: url() value to the right path to this asset during the “dev session” mode. Resulting in a 404 when the file is loaded from CSS.

// webpack://./resources/styles/app.css

.bg-chevron {
    background-image: url(https://sitename-wp.lndo.site/images/chevron.svg);
}

What do we have missing here in order to have these image assets loaded correctly from CSS during yarn dev?

For greater context, I’m sharing here down below the current contents of my bud.config.mjs file and tailwind.config.cjs file where this background image class is being defined using the custom values approach.

bud.config.mjs


// @ts-check

/**
 * Build configuration
 *
 * @see {@link https://bud.js.org/guides/configure}
 * @param {import('@roots/bud').Bud} app
 */
export default async (app) => {
  app
    /**
     * Application entrypoints
     */
    .entry({
      app: ["@scripts/app", "@styles/app"],
      editor: ["@scripts/editor", "@styles/editor"],
    })

    /**
     * Directory contents to be included in the compilation
     */
    .assets(["images"])

    /**
     * Matched files trigger a page reload when modified
     */
    .watch(["resources/views/**/*", "app/**/*"])

    /**
     * Proxy origin (`WP_HOME`)
     */
    .proxy("http://example.test")

    /**
     * Development origin
     */
    .serve("http://0.0.0.0:3000")

    /**
     * URI of the `public` directory
     */
    .setPublicPath("/app/themes/sage/public/")

    /**
     * Generate WordPress `theme.json`
     *
     * @note This overwrites `theme.json` on every build.
     */
    .wpjson
      .settings({
        color: {
          custom: false,
          customGradient: false,
          defaultPalette: false,
          defaultGradients: false,
        },
        custom: {
          spacing: {},
          typography: {
            'font-size': {},
            'line-height': {},
          },
        },
        spacing: {
          padding: true,
          units: ['px', '%', 'em', 'rem', 'vw', 'vh'],
        },
        typography: {
          customFontSize: false,
        },
      })
      .useTailwindColors()
      .useTailwindFontFamily()
      .useTailwindFontSize()
      .enable()
};

tailwind.config.cjs

// https://tailwindcss.com/docs/configuration
module.exports = {
  content: ["./index.php", "./app/**/*.php", "./resources/**/*.{php,vue,js}"],
  theme: {
    extend: {
      colors: {}, // Extend Tailwind's default colors
      backgroundImage: {
        chevron: "url('../images/chevron.svg')",
      },
    },
    container: {
      center: true,
    },
    screens: {
      sm: "540px",
      md: "720px",
      lg: "980px",
      xl: "1200px",
      "2xl": "1296px",
    },
  },
  plugins: [],
};
2

Images work fine:

body {
  background: url(@images/Blurred-Background-01.jpg);
}

This resolves the image at:

  • http://localhost:3000/images/Blurred-Background-01.jpg when using bud dev, and;
  • http://example.test/app/themes/sage/public/images/Blurred-Background-01.jpg when using bud build.

The title is kind of misleading. You are trying to resolve your image from a tailwind.config.cjs file; that’s not a stylesheet. It’s JS. It’s not fully surprising you can’t use a relative path in that context (what is it even relative to? I honestly don’t know for certain).

But, again, this works:

// https://tailwindcss.com/docs/configuration
module.exports = {
  theme: {
    extend: {
      backgroundImage: {
        chevron: "url('@images/Blurred-Background-01.jpg')",
      },
    },
  },
};

There might be some more general confusion than this. I can’t tell for certain. But things just don’t add up fully.

When you look at webpack://./resources/styles/app.css in devtools you are seeing your unmodified source file, thanks to source-maps. So, when you say this is what you see in devtools:

// webpack://./resources/styles/app.css

.bg-chevron {
    background-image: url(https://sitename-wp.lndo.site/images/chevron.svg);
}

I know that you have hardcoded https://sitename-wp.lndo.site/images/chevron.svg into your css file. That’s not going to work.

And, if you were loading the site over your dev connection (http://0.0.0.0:3000), I would expect that you’d see an error like this one:

image
image1920×913 41.2 KB

All of this leads me to believe you may not be requesting the site from the dev server. And so my general advice is to do that, and to use aliases; especially for things like loading image assets from a tailwind file.

3 Likes
3

@kellymears Thanks for the explanation, this was very helpful!

I’m new to using Sage and I’m learning the ways around it as I build a new WP theme on an existing project.

What I had missing was definitely using the alias @images/chevron.svg to load my assets defined in tailwind.config.cjs.

Wasn’t aware this was possible and was the right way to put it! During my research trough this forum examples I found were using the ../images/chevron.svg path and since it worked with yarn build but didn’t with yarn dev I was a bit lost what else was going on in my setup, even how to ask about it.

Also, I wasn’t loading the site from the dev connection http://0.0.0.0:3000. Now I see it is important to use it, specially while on yarn dev so it can resolve these assets correctly. Before I was just using the URL that Lando gives me https://sitename-wp.lndo.site.

3 Likes
4

There are ways to map the lando URL so that it does resolve. But, I don’t use lando so I’m not entirely sure what that looks like.

One day I’d like to include a lando extension as an offering because I wouldn’t think it would be more than a few lines of code to get it to work over https://sitename-wp.lndo.site:3000 with SSL and all that.

I’m glad you’re sorted out!

2 Likes