Christoph Nahr

I don’t work for WordPress so I don’t really know, but generally the theme developers are supposed to monitor this forum. I expect them to take note of this thread within a few days.

The changelog for Twenty Twelve 2.3 includes one item, “Improve styles for 4.8 widgets,” which probably was intended to fix this issue:
https://codex.www.ads-software.com/Twenty_Twelve_Theme_Changelog#Version_2.3

The changelog link leads to some diffs for style.css in Twenty Twelve and many other themes, concerning the Text widget. (I think that’s what you’re looking at in your screenshots.) Here’s the topmost one:
https://core.trac.www.ads-software.com/attachment/ticket/40745/40745.diff

This one defines new style classes for .widget_text which are *missing* from the Twenty Twelve 2.3 that I just downloaded from www.ads-software.com. I checked one other diff with some more .widget_text classes that are also missing.

So evidently someone forgot to actually apply the style diffs to the download version. This needs to be corrected at the WordPress site. Checking all other themes mentioned in the diffs is probably a good idea, too.

Yes, it was indeed Preload mode. Preload must be entirely disabled, or pages won’t update to reflect comments. That’s a pretty absurd limitation that makes Preload essentially useless unless you disable comments (or don’t use Jetpack?). Disappointing that this is entirely undocumented, and also that nobody saw fit to answer this simple question.

Problem persists today. Now I’m trying to disable Preload mode which I had enabled. The description sounds as if it might prevent automatic refresh of pages when comments are made.

Yes, the problem is with Google+. It randomly refuses to load images, or indeed any site preview at all. That was already the case before the Jetpack 3 update, and it’s still the case now when I just rechecked. The OpenGraph image tags are there, Google+ just won’t load (some of) the images.

Another update from my end. I figured out why I had not previously seen OpenGraph tags in Jetpack: You must enable Publicize to generate meta tags. You don’t have to actually use publicize or establish any connections, but the Publicize module must be enabled for Jetpack to insert OpenGraph and Twitter Card tags.

If you were to deactivate your Open Graph plugin, you’d see that the Jetpack Open Graph meta tags and Twitter Cards will be added to your site again.

That’s indeed the plugin I was using and you’re right, the OpenGraph and Twitter Card tags do appear on the site once I deactivated it! Strange, I added the other plugin because I didn’t see OG tags even though I had Jetpack. At any rate it works now, thanks.

Funny, after the regularly scheduled refresh of the preloaded cache the “feed” directory has now disappeared. And cache stats show that the feed actually gets cached as legacy WP-Cache, not preloaded Super Cache.

So it got rebuilt according to the cache timeout which I had left at the fairly short default value. I identified the actual feed cache file (wp-cache-GUID) and I’ve increased the timeout to the suggested 86400 seconds (= 1 day). Hopefully that should end the constant feed recaching.

edit: After I edited a recent post the “feed” directory actually got recreated with two subdirectories, “atom” and “rdf”, but all of them are empty. The actual cache files (one uncompressed, three compressed) instead got recreated in “wp-content/cache”, again with GUID names. Confusing but it seems to work now.

You’re confusing the theoretical maximum (which indeed is unlimited) with the maximum that the code as written was intended to allow (up to ten).

Well, I had just patched out that limit so I wasn’t sure what Jeremy was referring to.

The number is hard-coded as ten for performance reasons to allow the stats_get_csv() function here:

Thanks for the explanation. As for why I want exactly ten items, that’s just for symmetry with the ten recent posts and because it’s a nice round number! So no, I don’t have a strong reason for more items.

But here’s why I considered this hard-coded limit a bug: The widget itself allows entering numbers up to 20, not 10. That’s a very confusing discrepancy, and if you say the hardcoded limit should remain at 10 for caching then IMO you should definitely fix the UI code so that its limit is the same as the internal one, i.e. 10.

This line allows the plugin to get a list of posts, and we always query for 10 posts (the maximum that can be displayed in the Top Posts and Pages widget.

I hate to correct you, but that is not true. With my fixed PHP file, I just entered 12 as the desired number of Top Posts & Pages, and the resulting blog page showed 11 entries. (The usual front page was missing.)

Moreover, before fixing the PHP file as described, I could not achieve more than 9 entries regardless of the number I entered. Now I can get 10 displayed entries by requesting 11, again due to the silently omitted front page.

The particular post that has been added or modified should be (re-)cached automatically, regardless of settings. I haven’t seen an automatic refresh of any other posts after adding or modifying one, though.

Hmm, now that you mention it I just noticed that my blog (modified Twenty Twelve) does have one display issue on IE8: there’s the Menu button for the mobile version of the responsive theme, showing up on the desktop. Tested with IE10 developer tools. Quirks mode seems to fix that.

However, I get the same error regardless of whether I’m seeing the cached or the regularly generated page. Are you sure this happens only with caching? Responsive themes should produce the same HTML/CSS regardless, so I’m not sure where a CSS error specific to caching would come in.

All right, thanks for the clarification.

Something else occurred to me, aside from outright XSS blocking. Privacy tools like DoNotTrackMe and Ghostery are fairly popular, and both advertise selective blocking of services such as Google Analytics and WordPress Stats. Widespread use of such tools seems the most plausible explanation at this point, especially given my rather technical audience.

I’ll keep watching Google Analytics for a bit; so far it seems to match Jetpack stats. If nothing else comes up I’ll write a follow-up post and put those missed views down to (global or selective) blocking of cross-site scripting. Thanks for your time!

Google Analytics is up and running and collecting data. I’ll wait a few days and see what happens.

Meanwhile, I examined how Jetpack gathers statistics and noticed the following: When a user who isn’t logged into WordPress.com visits a blog that uses Jetpack statistics, the generated HTML contains a call to a JavaScript stats tracker that’s loaded from the WordPress.com server.

Now if I’m correct this means Jetpack won’t track any views by visitors who are (a) not logged into WordPress.com and (b) use either NoScript or any form of ad blocker that blocks remote script execution. Moreover, Jetpack also won’t see any views from China which blocks WordPress.com altogether.

Googe Analytics also uses remotely loaded JavaScript so it should produce stats fairly close to Jetpack, but it will also miss anyone who isn’t logged into WordPress.com and blocks remote script execution. (Voluntarily or not, in the case of China!)

Thanks for checking it out. Yes, I’m seeing your four views in my stats panel. Very curious… I’ll try installing Google Analytics and see how the numbers match up between Jetpack and my logs.