Incorrect relative paths in CSS when using symlinks

[AlanWarren]

Hello, I am currently configuring a wordpress site that uses symlinks for the uploads folder and it's theme.

With BWP minify's default configuration, I get an HTTP 400 error due to these folders being symlinks. To solve this, I've edited $min_symlinks inside config.php according to the documentation. This is where something unexpected happens. The CSS contained within symlink directories now loads (HTTP 200), but the other CSS contained in normal directories now returns HTTP 400. Essentially, it's the reverse situation.

For example, my site will enqueue css from "uploads", "plugins", "wp-include" and "themes" directories. With "uploads" and "themes" added to config.php as symlinks, I'm now getting HTTP 400 for any css contained within "plugins" and "wp-include", which are regular directories.

To solve this, I have to add entries for all directories we enqueue css from to $min_symlinks array, even though they're not symlinks. This results in HTTP 200 for all CSS resources, but now another issue is manifest.

Here's an example that outlines the issue.

We are using the visual composer plugin, which loads fontawesome webfonts. Paths to .eot, .woff, and .svg files use relative paths within their CSS. For example, the file located at - plugins/js_composer/assets/lib/bower/font-awesome/css/font-awesome.min.css references fonts like so:

@font-tace{ font-family:FontAwesome; src:url(../fonts/fontawesome-webfont.eot) }

After BWP Minify, using the config.php outlined above with symlinks specified, relative paths are incorrectly output like so:

@font-face{ font-family:FontAwesome; src:url(lib/bower/font-awesome/css/fontawesome-webfont.eot); }

If I use regular directories instead of symlinks, and a default config.php everything works, and this is what is output. (this is correct)

@font-face{ font-family:FontAwesome; src:url(/webvox/wp-content/plugins/js_composer/assets/lib/bower/font-awesome/fonts/fontawesome-webfont.eot); }

Is there anything I can do to get this working?

Thanks

edit: I was able to get everything working by editing $min_serveOptions['minApp']['allowDirs'];

[kminh]

Thank you for such a detailed report. What you were doing is correct and is actually the recommended way. However, something isn't right because you should not need to add "plugins" and "wp-include" to $min_symlinks.

I will check and let you know if I can find anything.

[AlanWarren]

Sorry, I wasn't editing $min_symlink correctly. I used the name of the symlink folder as the key with it's full path as the value. I realize now that I have to use the docroot syntax and reference my symlinks from the root. That awkward behavior above was a result of this mistake.

allowDirs was the answer. Both my sites share the same path up to an extent, so it's easy enough to just reference the folder above both sites.

Hope I didn't waste your time.

Cheers

[kminh]

If I'm not wrong, you're modifying the min/config.php file inside plugin directory directly?

[AlanWarren]

Yeah, I'm modifying min/config.php, and making it unwritable to the server so it doesn't get overriden in WP.

[mpeshev]

Hey folks, this is still a problem with symlinks. Any particular workaround expected?

[AlanWarren]

It's been a while, but if I recall you need to edit bwp-minify/min/config.php. $min_symlinks is an array where you will provide a mapping of your symlinked directories. Read config.doc.php for reference.

Then, add the following. I had to pass it the directory above my symlinked dirs. (read usage in config.doc.php) //$min_serveOptions['minApp']['allowDirs'] = array('//js', '//css');

The caveat here, is that config.php is overwritten anytime a user edits bwp_minify's config inside of wordpress. You'll need to make sure config.php is not writable by the web server.

[mpeshev]

I definitely don't think that this is optimal. A filter can go a long way here, preventing the need from defending this one specific file from upgrades.