Possibly add support for dragging of meta boxes to touch-based interfaces

[georgestephanis]

In the desktop version of WordPress a user has the ability to move metaboxes around to customize their interface. However, touch-and-drag support is not as intuitive on a tablet. There are possible work-arounds that need to be explored. Alternately, there is the possibility of pre-determining the number of columns and not support drag-and-drop.

[thezman84]

Just making a note so that it doesn't get forgotten..

Drag and drop is not absolutely necessary for the rest of the admin, but it is key in at least 2 places:

• Appearance
  • Widgets
  • Menus

[georgestephanis]

Just for reference, ​http://stackoverflow.com/questions/3026915/how-can-i-make-a-jquery-ui-draggable-div-draggable-for-touchscreen seems to indicate that making it touch friendly is rather simple. No idea as to the accuracy.

[georgestephanis]

Pursuant to the discussion with Azaozz and Nacin on 2/18 in #wordpress-ui here's my quick draft on a cookie-based detection of touch interfaces ...

function wp_check_for_touch_ui(){
	if( isset( $_COOKIE['wp_ui_touch'] ) && ( 'true' == $_COOKIE['wp_ui_touch'] ) ) return;
	?>
	<script>
		document.ontouchstart = function(){
			var d = new Date();
			d.setTime( d.getTime() + ( 60 * 60 * 24 * 7 * 2 * 1000 ) );
			expires = d.toGMTString();
			document.cookie = "wp_ui_touch=true" +
				"; expires=" + expires +
				"; path=<?php echo SITECOOKIEPATH; ?>" +
				"; domain=<?php echo COOKIE_DOMAIN; ?>";
		}
	</script>
	<?php
}

add_action( 'login_footer', 'wp_check_for_touch_ui' );
// optionally, as it should always catch on the login page ... 
// this will catch future touch events if they somehow make it past the login page without touching ...
add_action( 'admin_footer', 'wp_check_for_touch_ui' );

It'll normally trigger on the login page, setting the cookie to be tested against either directly or via a function or whatever y'all think is best, for including the additional JS and such to make drag/drop and other features work on touch-based interfaces.

[georgestephanis]

First try, works perfectly on my iPad, document.ontouchstart doesn't even set the cookie on the Fire, and works-ish on my Android Phone, just the drag animation is a bit choppy.

[georgestephanis]

Please note that the JS I used as jquery.touch-mouse.js was taken directly from a stackoverflow posting, so we'll likely need to verify the source's licensing or just rewrite it before it's actually used.

[georgestephanis]

Also, a bit more information surfacing about the Kindle Fire's touch responsiveness in the stock browser ...

​http://www.mobileread.com/forums/showpost.php?s=b734ee7252e204ce2b069c052c56d446&p=1944703&postcount=10

[georgestephanis]

Minor tweak, added a toggle to the domain= parameter for the cookie so that it's not used if the cookiedomain is false. This seemed to be preventing the cookie from being stored on the Kindle Fire.

[azaozz]

20014-vars.php.patch updates the $is_iphone global to include (nearly?) all modern mobile devices that have web browsers. Really really wanted to rename it to $is_mobile but we agreed not to add any new globals :)

[azaozz]

Looking through 20014.domain-fixed.diff, jquery.touch-mouse.js has to be loaded after ui.mouse.js as it overloads some of the methods there. Also seems we can use the updated (in 20014-vars.php.patch) $is_iphone to output it as it won't affect anything if the browser doesn't support touch. Detecting touch support from JS and storing a cookie is clever but not sure we need the extra code (although it detects it more precisely).

[azaozz]

20014-touch-punch.patch adds the original jQuery UI Touch Punch plugin (with proper license, etc.) including the minified JS file.

If we are going with touch support detection from JS, perhaps we should use the same code as in the plugin, i.e. if ( 'ontouchend' in document ).

The JS from https://core.trac.wordpress.org/ticket/20014#comment:4 would run (and sets a cookie) on every touch everywhere, not needed. Also there's a wpCookies group of functions that can be used instead or repeating the same code.

[azaozz]

Related: #19673

[markoheijnen]

Understand that there shouldn't be more globals but its weird that $is_iphone does more then that.

Why not using $current_web_browser. And add the functionality to that. Sounds a way better solution to me.

[nacin]

I thought I commented here, but how about we introduce $is_mobile but force a reference, $is_iphone &= $is_mobile;.

I would rather us come up with a new way to handle this, but I am not a fan of any of the single variable, class, or function approaches proposed.

[markoheijnen]

That was my first thing what came up in my mind. But azaozz saying that there was agreed to not create new globals and I can fully understand that.

But why create new globals for it when there is $current_web_browser. I rather have one global that knows everything about the browser then several globals that knows something about the browser. I think we should create some kind of API how we really want it then create globals that plugin can use and can't be removed that easily.

[azaozz]

Replying to nacin:

I thought I commented here, but how about we introduce $is_mobile but force a reference, $is_iphone &= $is_mobile;.

Sounds good.

I would rather us come up with a new way to handle this, but I am not a fan of any of the single variable, class, or function approaches proposed.

Yes, agreed. Would need something "cleverer" :) Did some thinking/testing about this for 3.3 but not that happy with it #18893.

[azaozz]

Replying to markoheijnen:

I rather have one global that knows everything about the browser then several globals that knows something about the browser.

Right, instead of a global there can be a static inside a function, similar to how $current_user works at the moment:

function wp_current_browser() {
  static $current_browser = null;

  if ( $current_browser !== null )
    return $current_browser;

  $current_browser = array(...);

  $current_browser = apply_filters('wp_current_browser', $current_browser);
  return $current_browser;
}

Still not sure that's the best way to do it though.

[azaozz]

20014-wp_is_mobile.patch is same as 20014-vars.php.patch but wraps the test in a function and doesn't touch the existing globals.

[azaozz]

In [20417]:

Introduce wp_is_mobile() and use it instead of $is_iphone global, see #20014

[SergeyBiryukov]

Seeing an error after [20417]:

Fatal error: Call to undefined function wp_is_mobile() in wp-admin/media-new.php on line 9

The original check was added in [19335].

Seems the check can be removed, since that file is not included from anywhere, and nothing is included before those lines.

[azaozz]

In [20420]:

Move the wp_is_mobile() check after the admin bootstrap in media-new.php, props SergeyBiryukov, see #20014

[azaozz]

In [20433]:

Add the jQuery UI Touch Punch plugin to handle dragging on mobile devices, props georgestephanis, see #20014

[nacin]

In [20599]:

Remove touch-punch.dev.js, as .js is appropriate for an external, unmodified script. see #20014.

[azaozz]

Apparently Kindle Fire can have several different UA strings, and in "silk mode" it pretends to be "Macintosh; U; Intel Mac OS X 10_6_3...", not a mobile device. The tests in wp_is_mobile() need to catch that.

[nacin]

Replying to azaozz:

Apparently Kindle Fire can have several different UA strings, and in "silk mode" it pretends to be "Macintosh; U; Intel Mac OS X 10_6_3...", not a mobile device. The tests in wp_is_mobile() need to catch that.

Can we have the complete versions of the UA strings you have seen?

There should be unit tests here.

[georgestephanis]

Here's the UA string:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us; Silk/1.1.0-80) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16 Silk-Accelerated=true

found on ​http://www.labnol.org/software/kindle-user-agent-string/20378/

[georgestephanis]

Scratch that. ​http://munday.ws/2011/12/kindle-fire-useragent-wtf/ -- unless they turn on Desktop mode, it should always have Mobile in there.

[nacin]

Per IRC discussion with azaozz and georgestephanis, 20014.2.diff​ seems to be the route we want to take.

If Amazon releases a Silk browser for the desktop, we will need to come up with a way to avoid mixing it up with Silk mobile operating under desktop mode.

[azaozz]

20014.2.diff looks good, +1 to go in.

[ryan]

In [20990]:

Update Fire browser detection. Handle silke mode. Props azaozz, nacin, georgestephanis. fixes #20014

[johnbillion]

In 36813:

Uploads: Remove an unnecessary static var from wp_is_mobile() to allow its direct and indirect use within unit tests. The static `$is_m
obile var was only used to avoid a handful of calls to strpos()`, which are exceptionally fast and result in no measurable increase in
processing time on each call to wp_is_mobile().

See #35976, #20014