@Ramon Lapenta did you try composer vendor-expose ? (edited)

No, but doesn’t it do the same when doing the initial install if the exposed paths are defined in the composer.json?

im not sure but try it, maybe it will solve your issue

then you need to define the folder into themes composer.json

  1. "expose": [
  2. "css",
  3. "images",
  4. "javascript",
  5. "webfonts",
  6. "fonts"
  7. ]

then after defining, run the composer vendor-expose

I can’t do it right now, but will check tomorrow if it makes any difference

👍 (1)

btw did you see the folders or file under public/resources/themes ?

because when running expose, it will copy the file to public folders

Thing is, after I commented the contents of that generated htaccess it all works fine

I know not a lot of people use this kind of cache busting, most people use query strings

because if im correct if you have issue on css file, just do ?flush so the file will be regenerate again

But again, the real file is fine, what didn’t work is the redirect

did you use <% require css("<my-module-dir>/css/some_file.css") %> or Requirements::css("<my-module-dir>/css/some_file.css"); ?

And it works now on SS after removing that extra htaccess

try the requirements approach maybe that solve your problem

i nver experience that issue before btw

I do it this way because my build system regenerates the number on every compile of sass

Do you use a redirect like mine? This issue is very specific to my case and the redirect

There you go, what didn’t work was the redirect, the expose works fine

Mostly curious about that generated htaccess that affects my case particularly

Spent a good two hours trying to find out why my styles were not showing 😓

Fun fact (not) When exposing public resources via composer, an .htaccess file is generated in /public/resources/, with the following content:

  1. # # Block 404s
  2. <IfModule mod_rewrite.c>
  3. # RewriteCond %{REQUEST_FILENAME} !-f
  4. # RewriteRule .* - [R=404,L]
  5. </IfModule>

Which effectively breaks a rule in the main .htaccess file used to redirect (cache busting) a file name such as style.2732837092370.css to style.css

> But people never really think it through Guilty

Yeah, on the surface it seems like a good idea. But people never really think it through. They think about applying properties/methods to their classes they're developing, not about the other powers DataExtensions hold.

yeah, i must admit i havnt looked into a heap ive jsut seen others wanting them thought id let null he wasnt alone 😉 but thats true they arent going to be replaced

Plus they don't compose, as with both examples @null has just pointed out.

they're similar, sure. But you can't apply a trait to a core class without modifying the source in the vendor folder ;)

@phyzical a trait is a very different use case to a DataExtension though.