Stephen Cronin

I tweeted you this morning, but have now had a little more time to look into this. I was going to suggest you use the empty all caches button in W3TC because when I looked at this post:

https://eastasiastudent.net/china/putonghua/wang-ruolin-dinner-three/

the W3TC cached time was 2012-08-05 22:31:41, which is a few days ago. W3TC has an option to not show the cached version to logged in users, so I wondered if logged out users were seeing and older version of the page, cached before Digg Digg was installed.

However, I’ve since seen another post with a date of today and Digg Digg wasn’t showing.

I added Digg Digg to my own site (now removed) and had no problems at all. I was using WordPress 3.4.1, Digg Digg 5.2.9 and W3TC 0.9.2.4. My Digg Digg setting were straight out of the box. W3TC settings are pretty complex, so it’s hard to explain them!

I did notice that your HTML seems to be minified, so I turned on Minification in W3TC, but I couldn’t get it to work for some reason.

I can tell you that my source has the following for Digg Digg: a call to a CSS file, a call to a JavaScript file and some markup. Your site has the markup, but not the call to the CSS file or the JavaScript file. They’ve been combined with other scripts / stylesheets as part of the W3TC minification.

Some JavaScript files don’t play well with minification / combination, so it may be worth turning off the minification. That’d be my main suggestion at the moment.

Hi cky2250.

It’s working for me on WordPress 3.4.1. Which version of WordPress are you using?

There are a couple of possible reasons that would prevent this from working:

1. A conflict with another plugin. It may be possible that another plugin is filtering the widget title before (or after) Remove Widget Titles. Are you running any other widget related plugins?

2. An incompatible widget. If the widget you are trying to use this with isn’t written in the standard way, it may not be possible to filter the widget title. Which widget are you trying to use? What happens with a standard text widget? If the title is removed on a standard text widget, but not on the widget you are trying to use, this indicates that the problem is with that particular widget type.

If you give me some further info, I’ll look into this.

Cheers,
Stephen

I have the same problem.

Every so often my category pages 404 and I need to go and turn the Strip category base option off (and save), then on again (and save) to fix it.

I used to use WP No Category Base – WPML compatible with no problem, so I have returned to using that until this is fixed.

Hi bitbusters,

The syntax you show above is correct – it seems there is a problem with this appearing on www.ads-software.com that I will have to look into. Thanks for highlighting this.

I’m not sure why it’s not working and will have to look into it. In theory it should be the same result as if you use the Yahoo Converter, eg:
https://au.finance.yahoo.com/currencies/converter/

You could try moving the ” PLN” outside the closing tag – that my help. Apart from that I’ll have to look into it.

Hi Michael,

Would it be possible to add an option to disable the MySQL backup?

I use a separate plugin to email that more frequently and my MySQL instance has about 12 schemas (for 12 sites) and it’s taking forever to backup (hasn’t actually succeeded yet). Ideally I want to turn the SQL backup off.

Hi Guys,

I missed all this, but I’ll have a look into whether I can include Yoav’s changes into ajax_the_views. The plugin works for me on my site as is and I haven’t been able to work out why it’s happening for other people.

A big thanks to you Yoav.

Cheers,
Stephen

Not sure if Joost ever saw this, but he has fixed this in the latest version, as announced on the following post:

https://yoast.com/site-speed-tracking-in-google-analytics/

Hi Luciano,

I’m pretty sure Joost will add it to the plugin in the near future.

In the meantime, I’ve written a post (How To Set Up Site Speed For Google Analytics In WordPress) adding how to do it through the custom code setting.

Be warned however, that this involves hacking the plugin (because it adds slashes to the custom code, which I think is a bug and I’ll report separately) – so it should only be used if you are truly desperate! It would be better to wait for an official fix.

The filter may be a much better solution – but not sure if I have time to work out how to do it.

Hi All,

Regarding Ajax_the_views:

Another user looked into this and came back to me with the following:

Actually nothing wrong with your plugin issue is with Apache reverse proxy and the Proxyhtmlurlmap feature

But he didn’t explain what the exact problem is or how it may be able to be fixed. I’ve asked him for more information, but I don’t know when or if I’ll hear back from him (it’s not looking likely!).

Delving into Apache is a large stretch for me – I only have basic skills so troubleshooting this will be a big task. At the moment, I’m behind in both my day job and in paid client work, so I’m unlikely to be able to get far in the near future.

So for now, I’d recommend not using Ajax_the_views. You can still use W3 Total Cache as described above (with the DB stem etc), and it will record all the views – it just won’t show them all instantly (which is what Ajax_the_views was supposed to solve).

@leo Plaw

That’s nothing to do with Ajax_the_views, it’s just a step you need to follow to get WP_Postviews to count properly.

This is on top of the solution that Lester built into WP_Postviews and is talking about above. What he is talking about will work with most caching plugins and with W3 Total Cache with database caching turned off.

However, if W3 Total Cache has database caching turned on, it will only update the database once every 180 seconds (or whatever this is set to in W3 Total Cache). I found that during this time, it won’t record page views, presumably because W3 Total Cache is catching database calls and serving up whatever was returned last time (but not actually updating the database).

This can be solved by either turning W3 Total Cache’s database caching off OR by telling W3 Total Cache to ignore the table that the post view count is stored in (wp_postmeta). To tell W3 Total Cache to ignore wp_postmeta, you need to add an ignored query stem of wp_postmeta. From memory, this is done on the Database Caching page of W3 Total Cache, but I don’t have the screen in front of me.

Hope that helps…

Actually, that fix has been in WP_Postviews for more than 2 years.

It only fixes the counting of page views, not the display of them (which is what my Ajax_the_views resolves, although it has a problem at the moment that I’m working on).

Also, as I mentioned above, if you have database caching turned on then you to add an ignored query stem of wp_postmeta for the counting of page views to work. Otherwise it will only be updated every 180 seconds.

Hi All,

Yeap as long as WP_CACHE is set to true in wp-config.php, WP-PostViews will update the count using AJAX upon loading the page but if the cache of the page does not expire, the count will still be the older one.

Ajax_the_views was written to specifically address this issue (bold mine). It only “ajaxifies” the display of the count.

It doesn’t do anything to increment the count, because as Lester points out, WP_Postviews already does this. Note however, there is one trick in the setup of the W3 Total Cache:

If database caching is turned on, then although WP-Postviews receives the Ajax request, the call to update the DB only works once every 180 seconds (or whatever interval you have set for database caching). To get around this, you need add an ignored query stem of wp_postmeta, as WP-PostViews stores the views as a Custom Field for each post.

Ajax_the_views should work on any page where the number of posts is displayed. This includes both individual posts and the home page.

However, as Leoplaw mentions, there is a known problem at the moment. I ‘m planning to look into this shortly, but am pretty busy and have had to prioritise both the day job and paid client work over this issue. I’ll try to bump it up the priority list and post back here when it’s fixed.

I’ll have a look into the problem with minifying the script as mentioned above (this is the first I’ve heard of it).

Cheers,
Stephen

The plugin is called Ajax_the_views and is now available on my web development blog or the WordPress Plugin Directory.

I hope that helps someone – it’s certainly fixed the problem for me.

Okay, I’ve now written a plugin to resolve the problem with displaying the count. It’s testing fine and I’ve applied to add it to the plugin directory. It should be up early next week and I’ll link to it from here.

Note, this only fixes the problem with displaying the count. You’ll still need to add the database stem of wp_postmeta as mentioned above.

For anyone interested, here’s what the plugin does:

Lester was nice enough to add a filter into WP-PostViews the_views function. The plugin uses that to wrap the count with span tags with a certain class and id (containing the post ID).

The plugin then adds some jQuery to the footer. This finds all the counts (there may be more than one the page) and gets the post ID from each. It then sends an Ajax request to the server, which looks up the counts and sends them back to the page, which updates the appropriate count field.

Obviously, doing this is going to take up more server resources. The server script will run once for each page load and will look up the DB to get the count (on pages with more than one post, such as the home page, it will have to look up each one). In the bigger scheme of things, you are only losing a small bit of what you’ve gained by using a caching plugin, but nonetheless you need to be aware it will have some impact on performance.

WP-PostViews does work when the disk enhanced page cache is enabled. It sends an Ajax request to the wp-postviews.php file. If that detects that WordPress isn’t loaded, then it loads WordPress, negating the problem Frederick mentioned above.

However, it does have a problem with the database caching. If database caching is turned on, then although WP-Postviews receives the Ajax request, it’s call to update the DB does not seem to work. Well actually it does work once every 180 seconds (or whatever interval you have set for database caching).

To get around this, you need add an ignored query stem of wp_postmeta, as WP-PostViews stores the views as a Custom Field for each post.

Once you’ve done this it should be happily counting the page views you get – but…

If the page is cached, although it will be counting views behind the scenes, it won’t be able to display them. Each time the page is cleared from the cache (for example when a comment is made, or it’s been cached too long), the post view count will be updates, but then the page will get cached again and it will freeze until it’s next cleared.