• Resolved dirkmittler

    (@dirkmittler)


    I have been using Post Views Counter with the Debian-packaged version of WordPress for many months, successfully. But after a recent update to plug-in version 1.2.6, PVC has suddenly stopped counting any new views.

    In the past I have always had to add these two lines to the file ‘/usr/share/wordpress/wp-blog-header.php’, in order to get any view-counters to work:

    
            echo do_shortcode( '[whohit]Header[/whohit]' );
            pvc_post_views( $wp_query->post->ID );
    }
    

    Maybe I have been doing this wrong all along, but never found out where-else I could add PHP-code to my header. Further, PVC was working and counting views, in PHP-mode.

    What could have gone wrong?

    Dirk

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author dFactory

    (@dfactory)

    Hi Drik,

    It is not the way how it should be used, but it’s ok as long as you know what you are doing and it works.

    But the pvc_post_views() is not the function that’s counting views – it handles the display. The correct function would be pvc_view_post( $post_id )

    Additionally, the 1.2.6 did not introduce any changes related to counting – it’s using the same methods. What has changed is the indexing of db data and the new optimized way of displaying the data in the chart.

    In other words it should continue to work as before the recent release, so maybe something other’s changed on your install?

    Regards,
    Bartosz Arendt
    dfactory team

    Thread Starter dirkmittler

    (@dirkmittler)

    Thank you for the tip, about the correct naming of the function.

    I suppose that in the past, your plug-in has been working, in spite of my piece of code. πŸ™‚

    I am seeing that the current problem does not seem to affect counting, but rather affects displaying the results in the dashboard widget.

    I use ‘memcached’. If I simply flush this cache once, the PVC dashboard widget is immediately updated with the views-count from the past two days – which were therefore counted correctly.

    What I am suspecting, is that an update to my WordPress version, that coincided with an update to your plug-in, may have caused the same-old ‘memcached is your friend’ caching plug-in, to cache more aggressively.

    Now that I have changed the code as you suggested, I will continue to observe for a few more days, before marking this thread as resolved. Because if it really just was a caching problem, then it was also not your responsibility. πŸ™‚

    Dirk

    Plugin Author dFactory

    (@dfactory)

    I think we’re close to a solution.

    1.2.6 introduced object cache support for it’s custom db queries (as yet another speed optimization step). So all this related to memcached sounds more understandable now.

    • This reply was modified 9 years, 1 month ago by dFactory.
    • This reply was modified 9 years, 1 month ago by dFactory.
    Thread Starter dirkmittler

    (@dirkmittler)

    I do not really know, whether the ‘memcached is your friend’ – WordPress plugin, specifically uses Object Cache.

    What I have observed again tonight though, in spite of my minor correction to code, which was never necessary from me – because your PVC plugin already counts views without my code – the plugin behavior has stayed the same. The number of hits logged today, February 3, remained frozen at 40. But, once I did restart my ‘memcached’ Linux daemon this evening, which that plugin interfaces with, the hits count instantly jumped to 209 for the same day. So 169 views were being counted but not indicated in the dashboard widget.

    At this point I do not think that you should be digging any deeper in your plugin code for this problem, because your plugin may not be the only add-on affected by this. I also have a Weather Widget, which has been extremely sluggish to update. And in general, I find that anything in my sidebar is sluggish to update – probably, due to ‘memcached’.

    But I Can Eat My Cake And Have It, Too. I have written a small cron-job, that just restarts ‘memcached’ on my machine, at regular intervals. Of course, this kind of contravenes how the daemon is supposed to work, which is, to stay loaded as long as possible. Debian Team has already made an exception in how it packages this service, in not performing any log-rotations, and therefore not restarting it.

    I have just decided it should restart every 6 hours.

    Also, my main reason for using this caching daemon may not be the same as other people’s reason. I am figuring, that if my server was ever swarmed by a very fast number of hits – which has not happened yet – I could ease the CPU load, via ‘memcached’, since the Apache server processes are already multi-tasked. I have multiple Apache sub-processes, that are all eagerly waiting to serve – maybe 1 hit every 5 minutes? πŸ™‚

    So I am satisfied by now.
    Dirk

    Thread Starter dirkmittler

    (@dirkmittler)

    I apologize for posting to this thread again, but after having analyzed this question, believe that there does after all exist some small amount of code-correction on your part, which will get your plug-in 100% compatible with the object-cache framework of WordPress, and with ”memcached’.

    If I understand what the object-cache support is supposed to do correctly, it has so far only been designed to send view counts there first, before flushing them to the database.

    But an aspect of how the object-cache works which you may not have taken into account, is the fact that it inserts itself between the browser that wants to view the dashboard widget, where view counts are graphed, and the actual widget-code, that wants to read the database to produce the graph, and the HTML.

    Presently, the HTML and/or graph are remaining cached, even though the database contains an up-to-date views count.

    I am uncertain as to what has caused this, since previously, the widget was being updated within the time-interval, in which the views count was being flushed to the database. Right now it is not. Also, the individual views widgets within each posting are not updating, until the cache is flushed by the blogger.

    Maybe, one reason it is not, could be some subtle change in policy, within the core package, which happened to receive an update on the same day your plug-in did. The core-package may now be using the object-cache framework on widgets, on which it was not using it before.

    Also, I doubt that the ‘Memcached Is Your Friend’ plug-in is so directly responsible, because what it is finally trying to do is provide a back-end to the object-cache framework, and to provide that back-end via the ‘memcached’ process, which the owners of their own servers get to run separately.

    And so what I would recommend the author of PVC do, is look for any possible way in which his widget may fail to delete itself from the cache, every time it is updated in fact (or, to change its time-stamp).

    I hope that this answer is not overbearing.

    Dirk

    Plugin Author dFactory

    (@dfactory)

    Dirk,

    We’ll provide a solution in the next release, no need to do changes in your caching.
    We’ll just set a cache expiration interval for each of the cached queries.

    Hope this fixes all the related issues.

    Thread Starter dirkmittler

    (@dirkmittler)

    Thank you so much!

    I have installed version 1.2.7, and everything works now!

    Dirk

Viewing 7 replies - 1 through 7 (of 7 total)

The topic ‘Plugin Has Stopped Working’ is closed to new replies.