[wp-trac] [WordPress Trac] #33704: Deprecate wp_is_mobile()
WordPress Trac
noreply at wordpress.org
Fri Aug 26 15:33:41 UTC 2016
#33704: Deprecate wp_is_mobile()
--------------------------------------+------------------------------
Reporter: johnbillion | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: 3.4
Severity: normal | Resolution:
Keywords: needs-patch dev-feedback | Focuses: ui
--------------------------------------+------------------------------
Comment (by akibjorklund):
I went through all the instances of calls to `wp_is_mobile`. It is called
34 times in 23 different files. I've roughly categorized the instances.
'''1. To determine if a JavaScript that automatically sets focus to a
field should be written: 5 instances
Not sure if this is a good idea in general, but could be based on the
viewport width just as well. At least makes sense to disable the feature
on smaller screens as the virtual keyboard will take up valuable space.
'''2. To print out a `mobile` or `ios` CSS class: 5 instances
In `/wp-admin/css` there are 19 matches for `.mobile` and 13 for `.ios`. I
did not look at those in detail, but probably most of them can be
converted to use media queries. Adding `mobile` class to body might be
required for backwards compatibility reasons, but this could be done with
JavaScript just as well, we just need to determine what would be the
features to test against. Plugins could have used the class for anything,
at least in theory, so this could be hard.
'''3. To print out meta viewport tags: 2 instances
These are probably entirely unnecessary checks, those tags won't harm non-
mobile browsers.
'''4. Related to upload capabilities: 4 instances
Some of these might be not relevant anymore, since they refer to old
versions of iOS.
'''5. Related to which editor features are enabled: 5 instances
Editor's expandability, distraction free writing and help buttons are set
based on is_wp_mobile. Also used to detect whether rich editing should be
enabled.
'''6. To load jQuery UI Touch Punch: 6 instances
jQuery UI Touch Punch is a library that makes jQuery UI components to
react to touch events. It is used to make meta boxes and other elements
draggable, maybe something else. There are ways to detect touch
capabilities on the client, but nothing 100% reliable. Probably better
than user agent based though.
'''7. For video on the about page: 2 instances
This is for the streamlined updates animation in 4.6, not for the 4.6 main
video. Probably used because there is no autoplay on iOS for video and
that animation is not something you want to press play for and watch
fullscreen. iOS 10 will allow silent autoplay and inline video, so that
would work in the future without mobile detection if there are similar
needs in the future. Not sure about Android though.
'''8. Customizer: 4 instances
`class-wp-customize-manager.php` and `theme.php` set some variables for
mobile and ios to pass them to JavaScript. I found only one instance that
uses those: customizer widgets do similar autofocus that category #1
instances do. There could be more uses for these and themes could use
these variables as well.
'''9. Login shake: 1 instance
Need to investigate why this is not enabled for mobile devices. Maybe the
animation was not smooth enough back then?
#
All of those might require a different approach. Should there be a ticket
for each of those categories with individual patches or should there be
one giant patch within this ticket?
Related: browser globals (`$is_lynx`, `$is_edge`, `$is_chrome`, etc.) are
also determined from the `USER_AGENT` header and are just as evil. I hope
no-one is using them to detect Netscape 4 anymore for example. This
definitely is a topic for another ticket though.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/33704#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list