Suddenly, I found that the article browsing count function failed. It took several months for the article to reach hundreds of views. I thought it was because the recent articles were unpopular and unpopular. However, it has been released for several months, and the number of visitors is less than 200, which is unreasonable.
1、 Find problems
So I took time to analyze it, and found that none of the requests for browsing count were found in the website log...
Because the website has opened Static cache (nginx fastcgi_cache), so the counting method of wp postviews will automatically change to the ajax submission method. Normally, the following request records will appear in the Nginx log:
/wp-admin/admin-ajax.php? postviews_id=xxxx&action=postviews&_=xxxxxxxxxx
However, I read Nginx logs in the last half month and found only a few entries, which seems to be true.
2、 Problem solving
First of all, I opened an article, pressed F12, and then refreshed the page. I searched for the familiar admin ajax in the NetWork content, and found that there was no record, even no request record when searching for php keywords. Searching for keywords directly in the page source code also yielded nothing. It seems that there is really no browse count code.
I thought that the PostViews plug-in did not work because of the WP update, so I opened the WP PostViews source code and found the following logic code:
if($should_count) { if(defined('WP_CACHE') && WP_CACHE) { echo "\n".'<!-- Start Of Script Generated By WP-PostViews -->'. "\n"; echo '<script type="text/javascript">'. "\n"; echo '/* <! [CDATA[ */'."\n"; echo "jQuery.ajax({type:'GET',url:'".admin_url('admin-ajax.php')."',data:'postviews_id=".$id."&action=postviews',cache:false});"; echo '/* ]]> */'. "\n"; echo '</script>'. "\n"; echo '<!-- End Of Script Generated By WP-PostViews -->'. "\n"; } else { if(!update_post_meta($id, 'views', ($post_views+1))) { add_post_meta($id, 'views', 1, true); } } }
Found the necessary condition to enable ajax counting: enable WP_CACHE cache!!!!!
In view of my familiarity with WP, I directly opened the wp-config.php file and found that I commented the following code:
//define("WP_CACHE", true);
It is estimated that it was commented out when debugging the website.
Then, after uncommenting, reloading php fpm, and clearing the Nginx static cache, the Ajax code familiar to the foreground comes back:
<!-- Start Of Script Generated By WP-PostViews --> <script type="text/javascript"> /* <! [CDATA[ */ jQuery.ajax({ type:'GET', url:' https://zhang.ge/wp-admin/admin-ajax.php ', data:'postviews_id=5832&action=postviews', cache:false }); /* ]]> */ </script> <!-- End Of Script Generated By WP-PostViews -->
Take a look at the Nginx log, admin-ajax.php? The request of xxx has also returned. It seems that the browsing count function has returned to normal.
3、 Conclusion analysis
① Why is it not that we do not count at all or only count once?
After tracing back to the next process, it is obvious that there are still counts after the article is published, but the count is very small. Why? In fact, the reason is very simple. When the article is cached for the first time, WP PostViews actually works once, using the php count in a non cached environment. After the count, the article will be cached, and the count will not be updated when it is accessed again. The browse count will not be initiated again until someone makes a comment or the cache expires, causing the cache to be refreshed! This is why we do not count or only count once.
② Counting conditions in the WP PostViews cache environment
This problem is very common. I just searched it and found that there are many similar situations. That is to say, the PostViews plug-in will judge whether WP has enabled caching (WP_CACHE). If it is enabled, it will use the ajax counting method. Otherwise, it will use the php counting method.
Therefore, if you use a non PHP caching mechanism, such as Nginx's fastcgi_cache or proxy_cahe, you must enable WP_CACHE in wp-config.php:
define("WP_CACHE", true);
Let the plug-in know that your website has a caching mechanism. Otherwise, you have to modify the plug-in to remove this judgment and force the plug-in to insert Ajax counting code into the page.
