New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
isaumya opened this Issue Apr 19, 2015 · 27 comments

Comments

Projects
None yet
6 participants
@isaumya

isaumya commented Apr 19, 2015

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..

@isaumya isaumya changed the title from Bug Report: Mobile Specific function does not work with ZenCache Pro to Bug Report: Mobile Specific function does not work Apr 19, 2015

@jaswrks

This comment has been minimized.

Member

jaswrks commented Apr 19, 2015

@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

This comment has been minimized.

isaumya commented Apr 19, 2015

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.
2015-04-19_14-07-30

@jaswrks

This comment has been minimized.

Member

jaswrks commented Apr 19, 2015

@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 jaswrks referenced this issue Apr 19, 2015

Closed

Building an AC (Advanced Cache) Plugin #63

0 of 6 tasks complete
@jaswrks

This comment has been minimized.

Member

jaswrks commented Apr 19, 2015

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

This comment has been minimized.

Member

jaswrks commented Apr 19, 2015

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

This comment has been minimized.

Member

jaswrks commented Apr 19, 2015

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

@raamdev

This comment has been minimized.

Contributor

raamdev commented Apr 21, 2015

@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

@raamdev raamdev changed the title from Bug Report: Mobile Specific function does not work to Feature Request: Mobile Mode (mobile device support, incld. 3rd party plugin compat.) Apr 21, 2015

@isaumya

This comment has been minimized.

isaumya commented Apr 21, 2015

@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

This comment has been minimized.

Contributor

raamdev commented Apr 21, 2015

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

@isaumya

This comment has been minimized.

isaumya commented Apr 28, 2015

Any update on this?

@raamdev

This comment has been minimized.

Contributor

raamdev commented Apr 28, 2015

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

@raamdev raamdev added this to the Future Release milestone May 2, 2015

@codesman

This comment has been minimized.

codesman commented May 15, 2015

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

This comment has been minimized.

lkraav commented May 15, 2015

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

@codesman

This comment has been minimized.

codesman commented May 15, 2015

@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

This comment has been minimized.

isaumya commented May 15, 2015

@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

This comment has been minimized.

codesman commented May 15, 2015

@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

This comment has been minimized.

isaumya commented May 16, 2015

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

This comment has been minimized.

codesman commented May 16, 2015

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

@isaumya

This comment has been minimized.

isaumya commented May 16, 2015

@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

This comment has been minimized.

Contributor

raamdev commented Jun 11, 2015

@raamdev raamdev modified the milestones: Next Release (Pro), Future Release Jul 10, 2015

@raamdev

This comment has been minimized.

@raamdev raamdev modified the milestones: Next Release, Future Release Aug 24, 2016

@raamdev

This comment has been minimized.

@raamdev

This comment has been minimized.

Contributor

raamdev commented Oct 7, 2016

@jaswrks

This comment has been minimized.

Member

jaswrks commented Oct 11, 2016

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.

@raamdev raamdev modified the milestones: Future Release, Next Release Oct 11, 2016

@jaswrks jaswrks referenced this issue Dec 9, 2016

Closed

PR: feature/471 #303

jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Dec 9, 2016

jaswsinc

jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Dec 10, 2016

jaswsinc

jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Dec 10, 2016

jaswsinc

jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Dec 10, 2016

jaswsinc

jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Dec 10, 2016

jaswsinc
- **New Pro Feature (Mobile-Adaptive Mode):** This release adds a new…
… feature that is designed to improve compatibility with Adaptive themes for mobile devices. To learn more, please see: **Dashboard → Comet Cache Pro → Plugin Options → Mobile-Adaptive Mode**. See also: [Issue #471](websharks/comet-cache#471) and the screenshots [here](#303 (comment)).

jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Dec 14, 2016

jaswsinc

raamdev added a commit to websharks/comet-cache-pro that referenced this issue Dec 14, 2016

@renzms

This comment has been minimized.

renzms commented Dec 16, 2016

@raamdev @jaswsinc

Confirmed Working

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

Using this configuration:

screen shot 2016-12-16 at 8 20 29 pm

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

screen shot 2016-12-16 at 8 20 56 pm

Using this configuration:

screen shot 2016-12-16 at 8 23 11 pm

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

screen shot 2016-12-16 at 8 24 20 pm

screen shot 2016-12-16 at 8 27 38 pm

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?

jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Dec 16, 2016

jaswsinc

jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Dec 17, 2016

jaswsinc

raamdev added a commit to websharks/comet-cache-pro that referenced this issue Dec 17, 2016

raamdev added a commit that referenced this issue Dec 21, 2016

Phing release of v161221 with the following changes:
- **Bug Fix:** Improving PHP OPcache detection. Now considering the INI option `opcache.restrict_api`. Comet Cache is now smart enough to avoid generating the PHP Warning: _PHP Warning: Zend OPcache API is restricted by "restrict_api" configuration directive_. See [Issue #733](#733).
- **New Feature (Pro): Mobile Mode.** This release adds a new feature that is designed to improve compatibility with Adaptive themes for mobile devices. To learn more, please see: **Dashboard → Comet Cache Pro → Plugin Options → Mobile Mode**. See also: [Issue #471](#471).
- **Enhancement: Auto-Clearing Author Page Cache.** This release makes Comet Cache smart enough to detect when a user is deleted (or removed from a child blog in a Network), at which time the Author page for that user will be cleared from the cache so it can be regenerated automatically. See [Issue #304](#304).
- **Enhancement: Multibyte Compatibility.** This release improves support for WordPress Permalinks that contain UTF-8 symbols (or emojis) in them. More specifically, this release adds the `/u` flag to all `preg_*()` calls in cache clearing routines that generate cache paths from Watered-Down Regex patterns entered by a site owner. See: [Issue #611](#611).
- **Enhancement: Widget Change Detection.** Comet Cache can now detect when **Appearance → Widgets** are added/edited/removed, and Comet Cache will automatically clear the cache so that your site remains up-to-date. See [Issue #411](#411).
- **Enhancement (Pro): Static CDN Filters and `srcset`.** This release enhances Static CDN Filters in Comet Cache Pro. Static CDN Filters are now smart enough to filter all image sources included in an `srcset=""` attribute that is generated by WordPress. See [Issue #660](#660). If you'd like to learn more about `srcset=""`, see [this article at WordPress.org](https://make.wordpress.org/core/2015/11/10/responsive-images-in-wordpress-4-4/).
- **Enhancement (Pro): Automatic Background Updates.** It is now possible to enable automatic background updates that occur quietly in the background whenever new features, bug fixes, or security issues are addressed by our developers. See: **Dashboard → Comet Cache Pro → Config. Options → Update Credentials**. See also: [Issue #827](#827).
- **Enhancement (Pro): HTML Compressor + Accelerated Mobile Pages (AMP).** Updated to the latest available release of the HTML Compressor (v161208) with improved support for [Accelerated Mobile Pages](https://www.ampproject.org/). See: [Issue #695](#695). See also: [HTML Compressor v161208 changelog](https://github.com/websharks/html-compressor/releases/tag/161208).
- **Enhancement (Pro): HTML Compressor / AMP Compatibility.** Improved compatibility with [Accelerated Mobile Pages](https://www.ampproject.org/). There is a new HTML Compressor option that is enabled by default and it makes Comet Cache smart enough to auto-detect and selectively disable portions of the HTML Compressor that are incompatible with the AMP spec; i.e., routines that are not necessary when serving APMd pages. In short, if the URI being compressed ends with `/amp/`, or the document contains a top-level `<html ⚡>` tag (`<html amp>` is accepted as well), then features which are incompatible with [Accelerated Mobile Pages](https://www.ampproject.org/) will be disabled accordingly.
- **Compatibility:** Avoid deprecated `wp_get_sites()` and use `get_sites()` instead. See [Issue #848](#848).
- **Documentation:** Added Watered-Down Regex documentation notes to the inline documentation (in the software) about the use of `^` and `$` in some places where these special characters are not fully supported. Also adding the same notes to the [Watered-Down Regex KB Article](https://cometcache.com/r/watered-down-regex-syntax/). See also: [Issue #611](#611).
@raamdev

This comment has been minimized.

Contributor

raamdev commented Dec 21, 2016

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).

@raamdev raamdev closed this Dec 21, 2016

@websharks websharks locked and limited conversation to collaborators Dec 21, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.