Hi guys. Noticed a few people have marked this “Broken” for 3.4.1. I am curious what you guys are seeing. For me it works flawlessly. The only issue is unrelated feature issues which i have took on myself to resolve.
Hello. It still works (bugs aside) for me in 3.4.1 although I haven’t bothered to update to v1.2.0 of the plugin, given that the changelog shows no useful bug fixes.
I’m interested which issues you have resolved yourself, kellogg9. I have also spent quite a bit of time debugging this plugin. Some of the bugs I have either resolved or am currently working on are:
- Pretty urls returns 404 when WP installed in sub-directory.
- Have to manually set $min_cachePath after migrating WP elsewhere.
- Cache expiry time does not change from the settings page.
- No longer works on JS files registered to output in the footer.
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.
Its working for me, after fixing the dreaded 400 error by excluding pinit.js. (pinterest button). Its kinda trippy that its looking in the body for .js files also. Ah, and it wasnt trying to min fb.all.js or google.plusone.js or twitter.js, but the pinterest js is called much simplier: src=//assets.pinterest.com/js/pinit.js so maybe thats why it tries to min pinnit and not the others.
I’d like to see an option that worked on only wp_head js files (and maybe wp_footer also)
Oh, actually, now I see that its not concating, minning files in the footer. hrm.
Kellogg9, could you make your changes available to us somehow? I’d run it through a diff and find out what you did.
bah… and now i see that some of my scripts arent working unless I combine but not minify.
i’ve also noticed that wp minify doesn’t longer work after updating wp to 3.4.1
it doesn’t combine and minify my scripts that i load via wp_enqueue_script.
It work only for js from plugins
However it work well on css
it was a mistake from me : i loaded my script in footer…
SO know it work well, however i’ve a strange behavior
It’s like wp-minify have a limited number of js file for compression.
i load 5 script like this :
but i’ve a 404 error
if i remove any one of this list, it work well….
any suggestion ? thanks
Please ignore my previous comment, it’s not a WP 3.5 specific error, I got the problem on a WP 3.4 installation as well.
My host migrated the server recently and apparently something is not quite right there. I now get memory exhaustion (64M) errors all over, it doesn’t seem to adhere to the wp-config & php.ini overrides of 256M I’ve had in place anymore.
Both installations had wp-minify working fine before.
And to answer your question, the error I get from minify is
PHP Warning: filemtime() [<a href='function.filemtime'>function.filemtime</a>]: stat failed for /home/XYZ/public_html/wp-content/plugins/wp-minify/cache/9fc5294425effd4de4a7223f9931cef5.css in /home/XYZ/public_html/wp-content/plugins/wp-minify/wp-minify.php on line 625
I’m using WP 3.5 and am having an error minifying the /wp-includes/js/jquery/ui/jquery.ui.core.min.js?ver=1.9.2 file. I’m guessing, however, this isn’t limited to this WP version but the version of the jquery.ui.core.min.js file?
In the jquery.ui.core.min.js?ver=1.9.2 file the following code:
Is minified to:
Notice the missing space between the pluses. This completely breaks my entire minified file. When trying to exclude this file from minification I get an additional “TypeError: e.ui.plugin is undefined” error, so it must be included with the other minified files in order to work.
Any assistance here is greatly appreciated.
Hmmm..that is odd that it is removing that space…but more unusually is why the jquery fellas never bothered to parenthesize around “++n” e.g.
That is the proper way to code that situation since it is way too easy for problems like u describe. Not even sure i would have realized about that minifying case…now i know.
I am still using jquery-1.7.2.min.js so this would likely explain why i dont see the problem.
I guess your option is to modify the wp-minify file to check for that condition (shouldnt be too hard) or modify that jquery file to add parenthesis as i did above.
Thanks Kimberly, I was having the same problem. I parenthesized around “++n” and it’s all working back to normal.
I just hope that WordPress will correct this in the future… or we’ll have to correct it manually for all the future updates ^^
- The topic ‘[Plugin: WP Minify] Works for Me in 3.4.1 — Curious to know what is happening for you guys’ is closed to new replies.