You can ignore what’s shown in the option page, as it is automatically guessed based on your minify URL. It will not affect the plugin’s functionality, don’t worry :).
This issue is marked resolved, but there actually are serious problems associated with what ksemel reported when bwp-minify is used with various common server configurations. I have only spent a short time testing, reading the code, and identifying problems, but this is what I have found so far.
bwp-minify’s path-guessing fails under Windows, works with dedicated host serving under Linux, but fails with common virtual host serving configurations under Linux. Those problems are due in part to $_SERVER[‘SUBDOMAIN_DOCUMENT_ROOT’] containing a static path set in an Apache config file, rather than a valid path to an individual virtual host document root. There also is a malfunction associated with the use of @parse_url($minurl) that I haven’t fully-determined yet.
Additionally the default empty string setting of $min_documentRoot in the min config.php is not valid with virtual host web serving, because it causes $_SERVER[‘DOCUMENT_ROOT’] to be used, which isn’t reliable for the reason explained above. The solution is to set $min_documentRoot as shown below, which I have found works reliably with both dedicated and virtual hosting under both Windows and Linux:
$min_documentRoot = substr($_SERVER['SCRIPT_FILENAME'], 0, -strlen($_SERVER['SCRIPT_NAME']));
After making the post above I discovered that min also uses $_SERVER[‘DOCUMENT_ROOT’] in several other places. Because of that, it appears to me that min will fail to work correctly with a significant percentage of web servers unless its code is patched in several places.
I am running a webserver at port 8443 with SSL…
The Plugin does not work with this settings. When calling my WP installation (https://example.tld/) the plugin is trying to call https://example.tld/wp-content/plugins/bwp-minify/min/?f=:8443/wp-content/*
Also its trying to set the cachedir to <htdocs>/:8443/wp-content/plugins/bwp-minify/cache and fails to detect its own location in <htdocs>/wp-content/plugins/bwp-minify/cache
In other words – This plugin (as of now) is not working with our installation and the page gets messed up because no CSS and JS files are loaded.
@admintiger: The codes you found inside bwp-minify only try to guess the cache dir to *show* it to the user, with no intention of using it for min application to be exact, so it’s not important that it is guessed correctly :). Regarding DOCUMENT_ROOT, it is something that should be configured differently on each user’s web server, that’s why I provide an easy way to move the min folder to another place of choice, and then you can play with the config file without worrying about the plugin’s update. I will write a short tutorial soon on how to make the most our of the min URL feature of BWP Minify.
@coksnuss: that bug has been fixed in 1.2.0, which will be released this week.
