sebastien.barre

Same issue here, my WordPress has its own dir, I’m getting the same errors.
Did you find a workaround?

More specifically, my install is:

wp-testing/wordpress
wp-testing/wp-content/plugins/nextgen-gallery

where wp-testing/wp-config.php starts with:

define('WP_HOME',    'https://' . $_SERVER['SERVER_NAME']);
define('WP_SITEURL', 'https://' . $_SERVER['SERVER_NAME'] . '/wordpress');
define('WP_CONTENT_DIR', realpath($_SERVER['DOCUMENT_ROOT'] . '/wp-content'));
define('WP_CONTENT_URL', 'https://' . $_SERVER['SERVER_NAME'] . '/wp-content');

Same here, my WordPress has its own dir, I’m getting the same errors.
Did you find a workaround?

More specifically, my install is:

wp-testing/wordpress
wp-testing/wp-content/plugins/nextgen-gallery

where wp-testing/wp-config.php starts with:

define('WP_HOME',    'https://' . $_SERVER['SERVER_NAME']);
define('WP_SITEURL', 'https://' . $_SERVER['SERVER_NAME'] . '/wordpress');
define('WP_CONTENT_DIR', realpath($_SERVER['DOCUMENT_ROOT'] . '/wp-content'));
define('WP_CONTENT_URL', 'https://' . $_SERVER['SERVER_NAME'] . '/wp-content');

Editing nextgen-gallery/products/photocrati_nextgen/modules/fs/class.fs.php fixes the MVC error:

class C_Fs extends C_Component {
[...]
	function initialize()
	{
		parent::initialize();
		$this->_document_root = $this->set_document_root(WP_CONTENT_DIR);
	}

but the path to all internal NextGen CSS/JS files is still incorrect, so there must be another location in NextGen where the plugin path is not computed from the WordPress constants. Actually it seems that ABSPATH is used in many many files, so this is going to be tricky ??

Unfortunately I don’t see such option in 0.9.2.3

Yup, same here with 0.9.2.1: Bad file format, even in manual mode.

The new update 0.9.2.1 released yesterday still has the same problem.
The minified files (.js or .css) only contains:
Bad file param format.
even in manual mode.

No, switching to manual mode won’t help either.
I tested from a non-authenticated browser, which is supposed to receive the fully-cached version of the page.
Disabling minify does the trick for now until a fix is committed.

Same here, minify part is broken (in manual mode, since I need CDN).
Getting a “Bad file param format.” when pulling the minified CSS file.
In the “CSS minify settings” I had to uncheck “Enable”.
The rest seems to be working fine.

Nope, no luck, I’m afraid I’m going to have to look at the PHP code.

Seems like a bug then. Can you file one from the admin W3TC UI in WP? At the bottom of the form you can enter the URL to this forum thread. I filed a different bug yesterday, I don’t want to push my luck ??

I’m using W3TC 0.9.1.3, WP 3.1 and Cloudfront and I *think* I have a similar problem.

I have “Host minified CSS and JS files” checked, I definitely hit the button to upload these files, I see them in my S3 bucket, but no dice, even after emptying all caches, my page still refers to the combined CSS file on my local disk, not the CDN:

<link rel="stylesheet" type="text/css" href="https://iko.wp_bm/wp-content/w3tc/min/b7912a/default.include.548125880.css" media="all" />

yet it was definitely uploaded by W3TC to the CDN:

https://s3.amazonaws.com/static-testing.barre.me/wp-content/w3tc/min/b7912a/default.include.548125880.css

or via my CNAME pointing on Cloudfront:

https://static-testing.barre.me/wp-content/w3tc/min/b7912a/default.include.548125880.css

Some other elements on that same page are using my CDN correction, for example:

<script type='text/javascript' src='https://static-testing.barre.me/wp-includes/js/l10n.js.gzip?ver=20101110'>

I’m using W3TC 0.9.1.3, WP 3.1 and Cloudfront and I *think* I have a similar problem.

I have “Host minified CSS and JS files” checked, I definitely hit the button to upload these files, I see them in my S3 bucket, but no dice, even after emptying all caches, my page still refers to the combined CSS file on my local disk, not the CDN:

<link rel=”stylesheet” type=”text/css” href=”https://iko.wp_bm/wp-content/w3tc/min/b7912a/default.include.548125880.css&#8221; media=”all” />

yet it was definitely uploaded by W3TC to the CDN:
https://s3.amazonaws.com/static-testing.barre.me/wp-content/w3tc/min/b7912a/default.include.548125880.css
or via my CNAME pointing on Cloudfront:
https://static-testing.barre.me/wp-content/w3tc/min/b7912a/default.include.548125880.css

Some other elements on that same page are using my CDN correction, for example:
<script type=’text/javascript’ src=’https://static-testing.barre.me/wp-includes/js/l10n.js.gzip?ver=20101110′&gt;

Same problem here, I’m using W3TC 0.9.1.3, WP 3.1 and Cloudfront