Kimberly

ALSO, you mentioned that the contents of the minified files (of the forum pages) are related to a plugin. Curious, are those same plugin files in those minified js/css also located on the homepage but are not being minified?

I ask because I am wondering if they dont exist on the homepage then wp-minify will have nothing to minify since all the other js and css files on the page you have chosen to intentionally not have minified (as is seen in the source of your forum pages).

Interesting stuff! Thanks for turning off CDN for now. Makes it easier to hunt.

Would you mind posting the contents of the error.log file that is found in the wp-minify plugin directory? If you dont see any then check the error.log file that is in root for any relevant errors assoc. with wp-minify and post them here. Apparently wp-minify is getting a fatal error from the homepage and abandoning the process.

Btw, its not a big deal but i just quickly spotted that you have “<script tipe=” instead of “<script type=” on line 93. It’s not what is causing the problem but just wanted to let you know. Even though you are using HTML5 its nice to see you are using the “type=” part still even though html5 doesnt need it (this plugin probably needs it).

Ok i think i know what your problem is….

When i check your source for homepage and forum i did notice one interesting thing….i actually think this plugin IS working for the homepage but found nothing to minify. Here is what’s going on:

All your js/css files on the homepage (and most on the forum) are files located on your CDN (and a few on Google). This plugin will only minify, by default, files that are on your local server at teatra.de. So you have to add any domains (partial matches are fine) that are not local (i.e., “teatradenetwork” and “googleapis”) into the config admin page (“External JS/CSS Files”) for this plugin — 1 partial domain per line. This should resolve your problem. You can then set up your cdn to pull the newly created single cache file (js and css) back to itself so as to host it from there instead of locally (assuming your cdn is advanced enough to do that).

Just be aware though that i did notice you have some inline js code and am not sure if it is placed in certain areas for a reason which require specific js files to be loaded at certain times….by caching them via this plugin in one area (by default, at the top) you might need to be careful and might need to relocate the inline code before the cache file loads in if the code requires it to be done so (eg., some times people like to initialize variables inline before loading the required js file done after it).

Hope that helps.

Also take note that when you use this plugin and make use of the css/js minify by not using the special <!– WP-MINIFY –> tags this plugin will by default place the minified css/js file at the first css/js file it found in the output page. Doing so can potentially break your page since you may be making javascript calls too early/late.

This plugin has some bugs which i and a few others here have fixed independently but they aren’t ones that prevent it from functioning.

I’d be happy to help considering how the plugin worked perfectly for me even after upgrading to the latest wp (3.4.1).

I checked your site but noticed the plugin isnt turned on.

Can you create a test page that disables W3 Total Cache and enables WP-Minify for that page only (don’t minify the HTML for that page)?

My guess is your page doesn’t w3 validate. I did a quick check and noticed 50+ errors.

I am starting to forget which fixes i made (working through a few other plugins) but i believe i too got the footer issue resolved (just saw your post — same as mine..cool!). Cache expiry — i didn’t actually fix it in his code but rather just updated the dbase file.

I dropped the “\n” silliness he had which made compressing of js and css files less efficient. I also did some extra tweaks to make compacting a bit more tighter — pretty much mirrors yui compression levels now (incl. an option to modify variables to smaller naming conventions for better compaction). Also fixed an issue with the “[[CDATA[” notation when presented as the more universal working: <!–/*–><![CDATA[/*><!–*/ instead of the more commonly implemented: /*[[CDATA[*/

I added a new checkbox to maintain static cache filenames (it sorts the files that are going to be compressed prior to md5’ing it and doesnt include the modified stamp — so technically it only chances the cache filename if you add/del a file into the mix) and an option to include/exclude the ?m=### postfix that are normally part of the “pretty urls” (for those who have little concern for remote caching). At least this resolves my bot issue of missing js/css files…granted its not a big deal for these files to go missing (because names changed) but i prefer these bots not to be confused why files keep disappearing so often (potentially raising red flags on their side). I also dont change my js/css files that often.

It’s a real shame this and other wp plugins dont have a code repository where users can dump their own fixes for the author to go over and consider adding — would make for quicker updates for others.

I was thinking the same thing (adding to robot.txt) but soon after i read (and viewed a clip) from Google that they highly prefer you NOT prevent their bots from looking at js and css files because they use them to verify that no spam is on a site. The person was saying by having it disallowed it makes their bots suspicious and could hurt ranking.

So just a clarification:

CDATA works fine in wp-minify. In fact it seems to not touch it when looking at my page source. But i am guessing it is the extra fluff you have around it that is confusing wp-minify. So i recommend you keep CDATA in but just clean it up to have the standard /* */ like my last comment shows.

That should solve your problem. My webpage has CDATA and works flawlessly in IE 6,7,8, and 9 with wp-minify’s minimize for JS,CSS, and HTML enabled.

I’ve seen a slightly different version to what you have there but if i recall its so as to support super old browsers that dont understand the <style> amd <script> tags. And if a browser doesnt understand script/style then they are WAY TOO OLD to handle anything you serve up. I personally dont see the point of having the extra mess around [CDATA and in my code i simply use:

/*<![CDATA[*/ …my code in here.. /*]]>*/

I could technically patch this plugin for this lazy plugin author to include that fix but for me i just have no use for it.

It’s likely because your html code is not properly formatted. In other words, you have errors in your code. So when this plugin goes to condense there are wackiness happening. My sites have html minify on with this plugin and work perfectly in IE.

I suggest you both use W3 validation to verify your non-minimifed site and correct the errors. And then see if wp minify works.

Decided to update this plugin myself by writing a new function to handle my about feature request. It works very well. It doesnt touch any of the functions but just adds a new one that simply makes the file names more consistent. So if the files to be combined are the same then the md5 that is used for the final name wont change (i sort the files “names” before applying the md5 function). It also doesnt use last modified date of a file when calculating the md5, which this plugin was doing (causing constantly changing names) since that will modify the final name too.

This helps tremendously since it now resolves many search engine spiders not finding missing css and js files like before which should help in seo ranking.

It should be noted though that the file names will change if the # of files it uses changes. Other than that the final name used is now static. In

Since this plugin strips all comments except for Conditional Comments (used by IE) you might try encoding them as a Conditional Comment.

Oh, and if you provide me with a link i’d be happy to check your site’s source for ya and confirm if that is the problem.

Hi again. Sorry to get all geeky on ya. Based on your problem though it sounds to me wp-minify stopped because it probably didnt find some of its js/css files.

Try this: Open up the Page source of the site you are having problems with. Now hunt for the “.js” (and .css) file to see if it is a cache file from wp-minify folder (you can tell based on the path name). Click to open this file. If you see something like “HTTP 404” inside then that is the problem.

You should be able to open up the error_log file that was generated on your site home dir and see the exact reason it failed.

Mine works fine. Using WP 3.4.1. In my case i had to pull back on my customization (revert it back to its original release) before it worked again).

Of course you can also try disabling and re-enabling the plugin (clear its cache) to see if that might help.

Use the special tags <!– WP-Minify CSS –> and <!– WP-Minify JS –> whereever you want. Right now i notice this plugin has an ongoing bug that prevents them being put into the footer.php. It’s as if this plugin forgets to check the footer for .js files and its own tags. Anywhere else seems to work fine.