Relative image URIs are getting broken in symlinking scenarios

[lkraav]

"images/bigback_inner.jpg" becomes "nt/themes/my-theme/images/bigback_inner.jpg".

it's pretty clear "^nt" is a cut off version of "wp-content".

probably something to do with

795                     $contents = Minify_CSS_UriRewriter::rewrite( $contents, ABSPATH . $src_dir_path );

[lkraav]

Could anyone tell me what a working image URL is suppose to look like? Is it still served behind /_minify/ or not?

[lkraav]

I think I have a way to reproduce the URL rewrite issue: symlink your active theme's directory from somewhere else. This should confuse the rewriter.

[lkraav]

And last but not least, my symlink basename is different from realpath's basename. So there :)

[westonruter]

A working image URL shouldn't be served under /_minify/, but rather from from a theme or plugin subdirectory.

The code in question is this:

// Rewrite relative paths in CSS
$src_dir_path = dirname( parse_url( $src, PHP_URL_PATH ) );
if ( 'styles' === $type && is_dir( ABSPATH . $src_dir_path ) ) {
    $contents = Minify_CSS_UriRewriter::rewrite( $contents, ABSPATH . $src_dir_path );
}

However, if the $src originally registered is a valid URL to to a dependency, then I don't see how this would cause problems with symlinked themes. The problems I've encountered with symlinks were caused specifically by plugin_dir_url().

If you turn off dependency minification, what is the normal stylesheet src URL that gets enqueued? Where is the symlink pointing?

[lkraav]

I'm not sure why you're asking about the stylsheet src url. It is built normally with get_stylesheet_directory_uri() . "/style.css". DM is able to correctly minify and enqueue the stylesheet and it loads correctly.

Problem is with relative image css rules inside the stylesheet:

background: url(images/bigback_inner.jpg);

becomes

background: url(nt/themes/mytheme/images/bigback_inner.jpg);

The symlink structure is:

$ pwd
~/public_html/customer/wp-content/themes
$ ls -l mytheme
lrwxrwxrwx 1 markitek markitek 60 Nov 29  2012 mytheme -> /home/markitek/www/wp-content/themes/mytheme-branch

It's a bit of an edge case indeed. I don't usually do this, it's this long running project coming from a legacy situation.

[westonruter]

The stylesheet URL is used as the base URL for relative URLs inside of the stylesheet, per the snippet shown above. Perhaps it's a problem inside of the Minify_CSS_UriRewriter::rewrite() method itself, probably something to do with realpath resolving the symlinks when they should be left symbolic?

[lkraav]

You are correct. $debugText has:

docRoot    : /home/markitek/public_html/loghouse
currentDir : /home/markitek/public_html/anna-maria/loghouse-theme-anna-maria

This is symlinking the user's homedir branch into themes catalog. If currentDir is used in determining the rewrite, it should definitely be left as a symlink.

[lkraav]

Maybe this https://gist.github.com/Tarendai/2971872 is of help for brainstorming and https://core.trac.wordpress.org/ticket/16953

[lkraav]

There's another issue: plugins dir, that I also have symlinked for a few WP instances, causes docroot stripping to give a bad result.

docRoot    : /home/markitek/public_html/loghouse
currentDir : /home/markitek/public_html/wp-content/plugins/wordpress-seo/css

[lkraav]

Everything works with this simple patch:

- 49         self::$_currentDir = self::_realpath($currentDir);
+ 49         self::$_currentDir = str_replace( '//', '/', $currentDir );

_realpath() looks very complicated hoopla to me and I'm not familiar with the reasoning behind it, so I'm doing this as a workaround for now. '//' needs to be handled because adding ABS_PATH . $src_dir_path creates '^//' and if you leave it in, it will be interpreted as a protocol-agnostic URI.