I’ve installed the WordPress AMP plugin for AMP-enabled posts. There are a few drawbacks though, most of which are cosmetic and I’ll try to sort myself. However, there is also a problem with the viewcounter. When an AMP-version of a post is viewed, the viewcounter doesn’t go up. This is a pretty big issue for me. Is there some sort of script I can input in AMP-enabled posts or some other solution in order to make the viewcounter go up with 1 when the AMP-version is viewed?
Thanks in advance for your answer!
Hello Torasko,
Please refer to the following topic here -> https://forum.tagdiv.com/topic/how-to-hook-hit-counter-into-amp-header/ and try to make all the steps which were presented there.
Thanks for your understanding!
I’ve added the following code to my functions.php, like Lucien described in his reply very clearly. Yet the view counter still doesn’t seem to work. It has been over a year since that reply was posted and new versions of Newsmag have been released. Perhaps the code is outdated? Thanks in advance!
add_action( 'amp_post_template_head', 'process_AMP_counter' );
function process_AMP_counter() {
global $post;
if (class_exists( 'td_page_views' )) {
if (td_util::get_option('tds_p_show_views') != 'hide') {
td_page_views::update_page_views($post->ID);
}
}
}
That old code still works with 3x, since we moved to Newsmag 3.x a year ago (Aug 2016) from 1.7. I have not yet upgraded anything to 4x as I’ve been building my own ‘in-house-only’ theme for our main business “corporate” portal (since we don’t need page builders, or news blocks, etc. — needs to be super lean, using bootstrap 3x).
However, ironically as of Aug 1 we disabled the hit counter entirely on our CANW website. But it *was* working the past 11 months on 3x just fine with the Automattic AMP plugin.
π
Remember to check the views in the custom field, not on the page, when you do a view increment, as the web page version is cached – that is how I wasn’t seeing the views on our site originally (I think I did a facepalm post about that way back when).
Of course – we didn’t use a caching plugin since we have dedicated server, so any caching plugin you’d probably need to make an exception for the /amp/ endpoint, since caching is done on the Google CDN for most purposes, and so local caching serves no purpose for the /amp/ version. My two cents anyway.
The amp_post_template_head() function still seems to exist. I can’t find the process_AMP_counter() in the PHP-code for the plugin, though. So I assume that this indeed causes the problem. I found something that resembles it, which is the is_amp_endpoint() function. However, this broke the website instantly:
[Thu Aug 31 09:27:22.368144 2017] [php7:error] [pid 22419] [client redacted:53621] PHP Fatal error: Cannot redeclare is_amp_endpoint() (previously declared in redacted/wp-content/plugins/amp/includes/amp-helper-functions.php:43) in redacted/wp-content/themes/Newsmag/functions.php on line 88
I’ve tried looking for functions in all of the files with the word ‘view’ or ‘count’ in them, yet come up empty. I’m afraid this is where my programming skills come to an end. The official readme also doesn’t include any information for as far as I can see.
Edit: I’ve used this documentation, where I also found the is_amp_endpoint() function: https://github.com/Automattic/amp-wp/blob/master/readme.md#handling-media.
I think the amp endpoint function is related to changing the ‘endpoint’ — such as if you wanted /ac/ vs /amp/ or /mobile/ or whatever.
Sorry I don’t have perfect answer.
On another site, with a custom lean theme, we have it added to the /amp/ endpoints, but we’re using the venerable WP-Postviews plugin.
in this context, the function we have is this:
do_action( 'amp_post_template_head', 'process_postviews' );
I haven’t been able to track the function down. Nothing in the code shows up with either ‘view’ or ‘count’ in it. I’m wondering if anybody has the solution for this, there must also be others that are using the AMP-plugin, right? Especially since Google is specifically targeting editorial-websites, which the Tagdiv themes are also for.
Any information would be greatly appreciated! π
Since amp ‘forbids’ client side scripting, it may be they are blocking anything being ‘run’ — or it may be that it runs first time, but then when cached on Google’s CDN for edge loading, the element script can’t run, as it’s not actually on the CDN.
There are folks doing stuff with Ajax with AMP for refreshing origin content; which is a bit like expiring the bucket on a CDN to refresh the local copy of content.
Personally, I’m of a mind, that AMP is an interim solution while wifi speed and phones play catchup. For instance, a new iPad PRO is more powerful than a 10 year old PC that HTML5 was built for.
In theory, one could argue that simply building your own print template with lean code, your desired custom elements like forms, or related post, or video, or whatever, could be ‘dressed down’ to lowest form like a print template, serve that for mobile and not even use AMP. Speed would be the same, especially if you’re already using CDN — and having a lightning bolt in SERPS doesn’t mean your page is better than everybody else’s page, just that it’s compatible, and might not even show up in SERPS, with all other things being equal with relevance, site age, content, etc.
Does the user experience suffer with AMP? Then why use it?
Questions for another time and place probably, but after nearly 2 years since the BETA, we’re kind of re-evaluating this for 2018, frankly.
Just more ramblings … π
Hey Chris, you bring up some very good points and for most parts I agree with you. I would be way happier without any form of AMP, especially since it could hurt SEO (double content). Since my website is targeting Netherlands and Belgium (written language is Dutch), the speed of the internet doesn’t really matter since we have both very good cable- as mobile connections. See the following:
https://www.iamexpat.nl/expat-info/dutch-expat-news/netherlands-has-fastest-internet-europe
The one major problem is when you’re content marketing products, which in return should deliver good DA-ratings (Domain Authority). The mobile pages that NewsMag delivers are working perfectly fine (with a few tweaks here and there). However, when trying to get content up in Google News, it’s more likely to happen with AMP-posts, simply because of the speed and simplicity they deliver. A normal page with cache gets loaded up in like 1.5 to 2.5 seconds, yet the AMP-version takes half a second or less, most of the time even lower than 200 milliseconds locally.
So to answer your question: No, the user experience doesn’t suffer when throwing AMP-pages out to just use the mobile version. Content marketing, on the other side, does in my current opinion. It also brings more maintenance and more chains in the line that could break.
Wellll…. all our news is in Google News, and has been since 2005, without AMP π
And luckily AMP doesn’t create duplicate content issues, since the canonical link is designed just for that purpose and the AMP version links back to the real version to solve that (same way a print template does). With our old CMS on our big site, not using WP, and generating static shtml pages), we has static print and AMP pages, and both had canonical links, and the AMP template was built off the print template since there were not AMP plugins when we got started on that (and the main site didn’t use WP at that time, but now does).
For our news pages now (not using TD theme, but custom thing), we can load up the full news story with 2 images, logos, content, queries for related stories, etc., in 1.3 sec fully loaded. AMP version is quicker. But a scaled back print version would be just as quick.
All about the payload.
And with move to PHP7 + http/2 the speed will be even faster.
I guess we’re thinking over here that http/2 with a lean template would be better than AMP for user speed on mobile in the coming year. We’re playing with this anyway.
Doesn’t solve the page count issue — but of course Google wants you to run GA on AMP, and so that might even be the only truly workable solution for metrics on AMP pages.
Anyway — back to work before Labor Day holiday here …. cheers π
Hey Chris, I’ve made my mind and stept off of AMP for now. Will optimize my pages further to make the speed go up and deliver a better user experience. Already upgraded to PHP 7.1, moved some non-essential JS-code to the bottom of the header, minified CSS + JS including above the fold optimization. It really works wonders so far. Have tried multiple times on a test-VPS to get http2 to run, but Custombuild 2.0 (DirectAdmin) doesn’t natively support it yet. The following tutorial for example:
https://www.vultr.com/docs/how-to-activate-http2-support-on-directadmin-centos
Everything goes well, until cURL comes around the corner. Online checks don’t show my websites using http2, and the following command is not being recognized: ‘curl –http2 example.org’. Can’t get it set up right, but might have to do something with the ISO that my provider uses for CentOS 7 + DirectAdmin VPS’s.
Anyway, that’s not a story for this forum. π
Thanks for your information so far! It has been very helpful.
heh… yeah… we have CentOS on dedicated server also, and the funky thing is we run Apache, and http/2 under Plesk/Onyx has to run as part of NGINX … which sits in “front” of Apache … which is bizarre.
We’re still playing with this, since we are doing house cleaning to move fully from PHP 5.6 to 7.1x.
Too much fun! π
(( tested a page this morning normal page with photo + video, site branding graphics = 1.6 sec; AMP version of page, no video, no branding graphics 1.5 sec )) ….
Any specific reason that you went for a NGINX reverse proxy? I read reports that it gives incompatibilities with WordPress sometimes, although I must be honest and say I haven’t really looked into it that much. Apache as the main webserver works just fine at the moment. π
Well, we aren’t using that for normal stuff.
It’s the way http/2 works on Plesk/Onyx — so, that is the minor hiccup we’re still sorting out. I think it has to do with the way that NGINX can run the code faster without the Apache layer, and yet grabs and compresses the code running on Apache to serve the cached copy in compressed format.
What’s funny is that I bugged Plesk/ONYX about adding some kind of security setup panel to navigate the complexity, and they added a ‘security advisor’ plugin/extension to do a one click setup. Nice. Have not yet tried it, though.
It may be with new version we don’t have to deal with the NGINX stuff anymore, but that was how it was done initially. I’ve been kinda waiting for improvements on that, with intention of making it the baseline for January 1, 2018. December will be the test month. Right now, it’s house cleaning for php 7 as we have a lot of old creaky shtml stuff to retire!