Andrew Miguelez

Considering you’re busy, I think it’s totally reasonable to leave this alone until you know it’s affecting a larger userbase. I would assume that it’s affecting a large portion of people who simply aren’t checking the plugin for the failure messages though. So my suggestion would be NOT to update Closure again unless you absolutely have to. That way this issue doesn’t surface again in the future.

I’m really not sure. As much as I hate adding weight to any project (and the closure jar file is very big) this is a big issue that is probably affecting a huge percentage of your users right now.

I’m guessing the best option objectively is to default to an older, stable version and never update it. Then offer the newest version as an option with a note about checking to see if it falls.

Unless you can automatically switch between versions after checking the installed Java version. Then you should totally do that and never give the user a choice.

I was just looking into this issue on my websites with this plugin. I’m on a VPS on Dreamhost (but realistically, it’s just a shared server so I have no control). This error seems to be referring to the version of Java on the server. So it would appear that Closure Compiler is requiring a newer version of Java than is available.

Since this error is new and I wasn’t getting it last time I checked (months ago), I checked the Changelog for MMR.

Update Closure to latest is listed for both 1.8.8 and 1.8.7 versions. I went to the 1.8.7 version of the trunk first and grabbed that version of closure-compiler.jar and replaced it in my plugin on the server. All fixed!

Obviously, this isn’t an ideal, future-proof solution. And you may need to go back to an even older version of the compiler file for your server configuration. But at least we know what the error is and what can be done for a temporary fix.

I’m sure my server will get updated eventually, but that could easily be in years, not months. So I guess it’s something to consider when pushing updates to the plugin for WordPress sites which are very frequently hosted on shared servers. Big props to the developer of this plugin for allowing a graceful fallback if this happens to occur (though the red error text was a little alarming, haha).

Both issues are resolved with 1.8.4. Thanks!

I saw the diff with the accidental double dequeue. Oops! ??

Thanks for the info. 24 hour cache time makes no sense for small sites with low traffic. Most hits wouldn’t be cached in that scenario. So if you’re trying to improve performance on a slow, shared server, you have no other option than to run a long cache expiry.

FOR OTHERS DEALING WITH THE SAME:
The Jetpack plugin uses JS to track views to pages/posts. This is basically the same thing that WPP is doing. However, Jetpack is able to maintain view count tracking throughout the entire cache cycle (regardless of timeframe). For those in the same boat, you may consider switching to Jetpack.

Keep in mind that Jetpack does not give you the customization controls that WPP does. So if you want to style the popular posts, you’ll have to do a lot of digging and live-environment testing to get the look you want.

If that sounds terrible (and it is) then stick with WPP and just ignore the fact that some of your views aren’t being tracked. The popular posts will still display and they will more or less be relatively accurate.

Yes. You’ll notice in the original post I mention clearing my cache files manually.

A site that doesn’t get updated more than a couple times a month gains nothing from a short cache expiry time. So is there a workaround for someone using caching longer than a day?

@riyazhyder,

Again, if you deactivate MMR, it’s no longer affecting your site. If you still see MMR assets in your source code (which there are not as of right now) then you need to bust any caches you may have from other caching plugins.

As for your flash of “random shapes and images”… These are your normal page assets being loaded and styled poorly due to the way you’re loading your stylesheets. You have a ton of inline CSS loading in the <head> of your page – way more than is probably advised for performance. Then you load all the rest of your CSS files at the end of your document with a JS asset loader. This means your page is loading with some styling and showing you incomplete styling for some of these “random shapes” and then it can’t finish loading styles until the rest of the page loads. That’s why there is a slight delay between the “random shapes” and finished styling.

By the way, the “random shapes”, as I said, are just your normal assets with incomplete styling. The big down arrow is just styled to fill its container but the container isn’t styled in your inline styling. It’s the down arrow you have displayed at the top of the page on mobile screen sizes.

I’d recommend undoing whatever changes you made after you activated MMR, as this plugin won’t have any lasting effects once it’s gone and your cache is cleared.

Same issue with v2.86
Making any progress on this?

Debug info:
URL: https://local.example.com
PHP Version: 5.5.12
Version: 4.6.1
Active Theme:
CUSTOM 1.0.0
URLOpen Method: curl
Plugin Version: 2.86
Settings:
dsq_is_installed: \n_disqus_sync_lock: \n_disqus_sync_post_ids: \ndisqus_active: 0\ndisqus_forum_url: \ndisqus_api_key: \ndisqus_user_api_key: \ndisqus_replace: \ndisqus_cc_fix: \ndsq_external_js: \ndisqus_partner_key: \ndisqus_public_key: \ndisqus_secret_key: \ndisqus_sso_button: \ndisqus_manual_sync: \ndisqus_disable_ssr: \ndisqus_last_comment_id: \ndisqus_version: 2.86\n
Plugins:
Disqus Comment System 2.86 (active)\n

I’m sure you’re busy, no worries. I’m going to have to go a different route and try some other plugins. However, I would be happy to revisit if I get any suggestions or support on this topic.

Aside from this issue I’m experiencing, I think you have a great plugin and I hope I can get it to work in the future.

I don’t believe this is possible through the plugin settings. However, you could easily decide what to display and hide with CSS. If you include all of the data as you show in your example for the first post, then you can target certain elements or classes in your CSS.

Like so:

.popular-posts li .thumb,
.popular-posts li .summary,
.popular-posts li .wpp-read-more {
    display: none;
}
.popular-posts li:first-child .thumb,
.popular-posts li:first-child .summary,
.popular-posts li:first-child .wpp-read-more {
    display: block;
}

Sorry if I’m beating a dead horse, but the documentation around this seems to leave a lot up to assumption.

Am I to understand that if I don’t have a “Cache Everything” rule enabled, then the Automatic Cache Management setting is basically unnecessary to me?

I enabled it because all it says on the plugin settings page is: Purge Cloudflare cache automatically when you update the appearance of your site. That made it seem to me like if I didn’t enable that setting, parts of my site would be outdated due to caching when I post something new. I think a little more context would be very helpful, especially for users like me who are new, and less technically savvy users too.

Thanks for you help.

• This reply was modified 8 years ago by Andrew Miguelez.

I can confirm that the plugin’s logic is sound and the expected output is accurate. MMR does exactly what it states in its description. It follows your themes directives for stylesheets and scripts and doesn’t reorder them to force any minification. That would potentially break many sites. The UI is simple and gives you the ability to exclude certain scripts. For all that, I find it worthy of 5 stars. I do hope you’ll consider looking into the documentation further and testing your site. It’s more than likely that MMR was following your theme’s functions.php file correctly.

Thanks, Marc.

I can confirm that the plugin update fixes the issue. I really appreciate the time you spent with me, diagnosing and correcting the error I was experiencing. Merge + Minify + Refresh is a very good plugin and backed by a great developer. I will definitely be using it in more projects moving forward.

For those following along…
The issue I was having was most likely due to my combination of Apache & PHP (older PHP version specifically). My WP install didn’t like when MMR tried to use data about enqueued styles that didn’t exist. The developer’s fix was to invoke wp_styles() and wp_scripts() before attempting to use their data. This alleviated my issue because WP then created the necessary objects relating to enqueued styles even though none existed. No more errors!

Personally, I’d prefer if MMR simply followed the applied defer & async attributes by way of script_loader_tag. This, instead of a UI change, would mean the plugin could maintain its simplicity.

I can see how configuration in the plugin settings would be helpful, however I’d argue that since we’re not adding stylesheets/scripts in the plugin, but through functions.php, we should manage the attributes in the same way. This way, the desired behavior for those files is constant whether the plugin is in use or not.

• This reply was modified 8 years ago by Andrew Miguelez. Reason: added tags

I just sent you the test theme in a ZIP.

I have pinpointed the cause of the error. MMR is unable to overlook a lack of enqueued stylesheets. You need to call wp_enqueue_style() at least once in order to avoid the Fatal Error.

My custom theme has a hard-coded stylesheet in header.php so I have not enqueued any stylesheets yet. I was planning on transitioning that over once I got a minification plugin working. Hopefully you’ll be able to identify and fix the areas in your plugin that are causing this so weirdos like me won’t see errors anymore.