Feature Request: Mobile Mode (mobile device support, incld. 3rd party plugin compat.)

[isaumya]

As Google has announced that mobile friendliness is going to be a huge priority in their upcoming algorithm update, this bug is so crucial that it made me deactivate the plugin.

Issues Explained

You see wordpress comes with a by default function for detecting mobile and tablet devices, i.e. wp_is_mobile(), also there are plugins to enhance that feature like mobble; which will allow you to use various mobile specific function of mobile_detect.php inside your theme or plugin development. In fact now-a-days many marketplace themes comes by default with mobile_detect.php.
Now the problem is when zencache is activated it is just following the @media rules of css for showing the mobile specific design, but all the logical code you have made inside your theme's or plugin's php code is still throwing the desktop version of it.

Example Problem

For example lets say you have created a small php plugin which will generate a shortcode [something] and the work of this shortcode is to show adsense ads. Now you have coded it such a way that if it is a desktop device, it will show up 728x90 ad and if its a mobile or tablet, it will show 320x250.
With zencache installed no matter on which device you are on, you are always going to see the 728x90. This is a serious problem and might break many marketplace themes which does some mobile specific work at the PHP level..

[jaswrks]

@isaumya Thanks for the report.
Do you have any suggestions for how to deal with this?

---

Solutions That Come To Mind

• Not relying upon server-side routines (i.e., adapative web design) to deal with device detection. Instead, use Responsive WordPress themes that do not rely upon device detection. Responsive themes will use environment detection via CSS/JavaScript that are cacheable. Adaptive design techniques are much less compatible with any sort of caching algorithm, because they are going to require multiple variations of the cache for each device.
• JavaScript port of mobile-detect; https://github.com/hgoebl/mobile-detect.js
• Use a ZenCache AC plugin whenever adaptive web design is preferred. We discussed this in 2013 whenever the Advanced Cache plugin architecuture in ZenCache was first introduced. Example AC plugin file that deals with mobile flavors: https://github.com/websharks/zencache/blob/150409/zencache/includes/ac-plugin.example.php

See also: http://zencache.com/kb-article/why-isnt-my-dynamic-content-updating/

[isaumya]

Hi @jaswsinc I do not agree with your solution (1st point), as this is not just about themes. This is about plugins also. As the example I stated above, you cant achieve that without using server side coding. Mobile detection functions are very important in many different aspects.
Though I do not have any coding solution about how to fix this, but I can tell you that WP Super Cache (a free plugin) does have a inbuilt option for that.

[jaswrks]

@raamdev My feeling on this...

ZenCache is already equipped to deal with this. A Version Salt in ZenCache can be used to achieve this in any number of custom ways through the application of an AC plugin file. So it's not something that we need to add support for, it's already there.

That said, an AC plugin is going to be out of reach for most people. Whenever it comes to a common use case like mobile devices, we could just add a mode for this like others have done; e.g., WP Super Cache.

The mode being applied, simply adds a default list of mobile devices that will be tested against $_SERVER['HTTP_USER_AGENT'] and added to the salt. The default list could be made configurable also, so that it could be extended by a site owner.

---

@isaumya For now, using an AC plugin file would be the way to go. In fact, if you intend to use something more advanced for mobile detection, having an AC plugin file should make it far easier on a developer.

---

@raamdev Do we have a KB article that explains how to write an AC plugin?

We do have this example script:
https://github.com/websharks/zencache/blob/150409/zencache/includes/ac-plugin.example.php

[jaswrks]

I opened an issue for the KB article on AC plugins. I will try to publish more information about this soon.

---

@raamdev If we add a mobile "mode" so-to-speak, we could also compile a list of popular themes/plugins that would be dependent upon this mode in ZenCache. That way mobile mode could be enabled by default whenever it is absolutely necessary to do so.

I see that happening in two stages:

1. Simply enabling the mode and picking up changes in the device.
2. Doing a tighter integration with the most popular themes/plugins that deal with adapative design for mobile devices; i.e., taking the list of configured devices from the mobile plugin/theme itself, so that they run in perfect harmony with each other.

[jaswrks]

Referencing:

https://wordpress.org/plugins/wp-super-cache/faq/

How do I serve cached mobile pages to clients on small screens like phones and > tablets?
You'll have to use a separate mobile plugin to render a page formatted for those visitors. The following plugins have been tested but YMMV depending on mobile client.

Jetpack's Mobile Theme Module
WPTouch
WordPress Mobile Edition
WordPress Mobile Pack (can't have "Don't cache pages for known users." enabled)

[jaswrks]

Beginning of discussion w/ Scott Evans, for reference:
https://twitter.com/jaswsinc/status/589744554825228288

[raamdev]

@isaumya Thank you very much for the feedback. I agree this is an important issue and we'll work on improving ZenCache in this regard.

I'm not seeing a specific bug here--this is more like a feature request, to improve support for mobile themes and mobile-related plugins. To that effect, I'm updating the title of this GitHub Issue to reflect that and I'm tagging it appropriately.

@jaswsinc Thanks so much for the insight here too. :-) I meant to draft an AC-Plugin tutorial, but somehow it slipped through my todo list.

---

Related GitHub Issue: #72

[isaumya]

@raamdev Yah! you can say that. Actually when I posted it I got confused between bug and feature request as in this case the line is very thin :)

[raamdev]

Agreed! It is a fine line in this case. :-)

[isaumya]

Any update on this?

[raamdev]

@isaumya No update at this time. We'll update here when there is an update. :-)

[codesman]

Just an FYI, if you are concerned with SEO and Google, you will not want to use adaptive design. Google strongly discourages feeding different source to different devices.

[lkraav]

@codesman any specific document link you can point to for reference?

[codesman]

@lkraav yes, here's a good one. http://searchengineland.com/google-finally-takes-a-clear-stance-on-mobile-seo-practices-123543

I suppose I added a bit too much emphasis when I said strongly discourages, but they certainly prefer responsive design over adaptive even when/if you properly implement the rel attributes and content headers.

[isaumya]

@codesman I do not agree with you in this matter completely, but you are partly right. Let me give you an example for that. First of all Google goes not discourage different element for different device, Google prefers responsive design. But the thing is that if you consider a general website then you can do almost anything with responsive design and CSS3 media queries, but for certain aspects Google hates CSS media queries and infact ban you if you use media queries in certain cases.
Here is an very common example:
Almost all webmasters uses Adsense for monetizing their site. Now suppose you put an ad using in your sidebar of your blog. Now when you blog gets visited by mobile device or tablet, due to the responsive layer structure, your sidebar div get pushed into the bottom of the comment section, which is annoying to many users.
So, let's say you consider to disable the sidebar invoke for Mobile and Tablet devices. Now you can easily do this by putting a CSS3 media query in your style.css file and for that specific screen size and set display:none; for it. But the magical thing is as soon as you do that, you will see that your adsense account has been disabled by Google due to violating adsense policy. As per adsense policy

You cannot use any ad hiding approach with display:none or similar.
Source: https://support.google.com/adsense/answer/1354736?hl=en

because if you use display:none then the ad source code will still be there but won't show up. So the only option you have is to make sure that the sidebar div will never gets generated into the HTML if it is a mobile or tablet device, but you can only do it from the backend code, i.e. PHP because after PHP is executed, the source code is already generated and you can do nothing.

This is not the only scenario where device wise dynamic coding is really useful. There are multiple different reasons to use it. Let me give you another small example.

Let's say you use 728x90 ad using for your desktop users and ur site is fully responsive, now you know that 728x90 is not gonna work for mobile or tablet. So you want to show up 320x250 if the user is from mobile or tablet or else show up 728x90. Again for this you have to make sure that is conditional ad code gets included into the HTML from the backend PHP code, otherwise you will violate many adsense policies.

I hope now you get the idea.

[codesman]

@isaumya

Almost all webmasters uses Adsense for monetizing their site

Let's constrain that to those webmasters that monetize with 3rd party ads. Admittedly a large group, however none of my clients use or want to use adsense on any of their sites(nor any other 3rd party advertising) so this is not an issue for that demographic at least.

Google is primarily interested in (aside from making shit-tons of money from essentially scraping your content/data and selling ads) making sure that any request to a specific url returns the same content, regardless of user/device and that content is unique to that URL. They don't like "special treatment" and they definitely don't like duplicate content. If they are recommending a URL to be clicked on, they want to know that what the user is actually going to get(see) is what their bot sees and they want it to be essentially the same for every user that requests it, otherwise it should be accessed from a different URL.

As per adsense policy
because if you use display:none then the ad source code will still be there but won't show up.

Sounds like if you use adsense on a page(or entire site), you need to code it so that the adsense content displays properly on all of your target devices(responsive design).

If you choose to serve that page without the sidebar/ads to a mobile device only, you need to serve that "different" page from a different URL and use rel=alternate/canonical and content-vary headers. https://example.com/mypage could become https://m.example.com/mypage, or perhaps even https://example.com/mypage?sidebar=no. Would not matter what browser/device hits it, it will get a page without cloaked adsense markup that does not violate adsense policy.

Google is pretty clear about not wanting the same URL to return different content, unless it is for A/B or Multivariate testing and not for an extended amount of time. Here's the official downlow from the horses's mouth: http://googlewebmastercentral.blogspot.com/2012/08/website-testing-google-search.html

Dynamically serving different content to different users from the same URL is essentially equivalent to a long-term multivariate test. Which according to the article above, is a no-no. I personally believe it's not too much of a stretch to view it as a form of fraud although that is certainly debatable.

There is no one clearly superior, caveat-free workflow for any deployment, although IMO it seems like the only real reason to not use responsive design over adaptive(at least on the sites I manage) is the performance issue of multiple HTTP/1.x roundtrip connections on mobile devices, which has been solved, just a matter of time for widespread implementation.

So you want to show up 320x250 if the user is from mobile or tablet or else show up 728x90.

<picture>
 <source srcset="adsense-image-320x250.jpg" media="(handheld)">
 <img src="adsense-image-728x90.jpg" alt="Adsense Ad Image">
</picture>

Should do the trick...

[isaumya]

First of all I completely understand that you might not have good experience with AdSense. Anyways the code you provide at the last will never work with AdSense. Feel free to try it out, because AdSense doesn't provide you a jpeg file as link, they give you a JavaScript snippet which randomly calls add from their server.

Secondly, you have completely misinterpreted my comment, I never said that to provide different content for different device. Google is pretty smart and actually it do understand what part of a site is content and what part is not. Like for a blog the things on sidebar, Google never treats them a the "unique content" concept. Its more like an ornament to that site. I do agree with that rel canonical approach, bit for ornamental things it is completely waste of time as you are not providing duplicate content. So the PHP approach is much much smarter. Anyways, even if you do use your concept, you still have to use either PHP code to make that redirection for specific kind of service or have to use htaccess or nginx vhost code to do that. Now not everyone is familiar with htaccess or vhost so eventually they will prefer it via PHP.

I've attended baby webmaster conference but what you said about duplicate content above is wrong my friend. Hoge does hate duplicate content but the thing is:

1. If your url is same then it never gonna index more that 1 url for that.
2. For content, they focus on the main content of your page. Like if it is a blog post, does the post article and post content and comments remains intact on each device or not. Rest of the contents are ornaments mostly and that doesn't count for duplicate content. @codesman

[codesman]

@isaumya You da man. Sounds like you got it all figured out. Happy trails.

[isaumya]

@codesman Yes I did figured out how to work it around but didn't figured out the zencache issue. That's why this issue thread has been created on the first place and I'm pretty sure that zencache team is working on it.

[raamdev]

Also requested here: https://wordpress.org/support/topic/exclude-jetpack-mobile?replies=1

[raamdev]

+1 here: https://forums.wpsharks.com/t/integration-with-wp-mobile-pack-2-2-4/477

[raamdev]

+1 here: https://wordpress.org/support/topic/separate-caches-for-mobile-vs-desktop/

[raamdev]

+1 here: https://wordpress.org/support/topic/responsive-sites-mobile-cache/

[jaswrks]

Objective: As noted here...

Phase 1

• Comet Cache to have it's own built-in mobile device detection.
• Comet Cache to have a mobile mode that can be enabled.

Estimate for Phase 1 = 4 days.

[renzms]

@raamdev @jaswsinc

Confirmed Working

However, there were some inconsistencies, please correct me if I'm wrong.

Using this configuration:

I tested with:

• Laptop with Chrome
• Mobile Phone with Chrome
• Ipad with Chrome + Safari

It generated 3 different cache files, one for Laptop, one for Mobile Android, and one for Mobile iOS

Using this configuration:

I tested with:

• Laptop with Chrome
• Mobile Phone with Chrome
• Ipad with Chrome + Safari

It seemed to only generate 2 cache files, one for the Laptop and one for Mobile Chrome

The test was inconsistent as I wasn't able to reproduce more than 2 variations even with different permutations. Do I have the configurations wrong, or does having many common token variations (e.g; iOS, Android + Chrome being only counted as 1 variation) become a catch-all like Mobile Device?

[raamdev]

Comet Cache v161221 has been released and includes changes from this GitHub Issue. See the v161221 announcement for further details.

---

This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#471).