Tag: mobile

Hat wp_is_mobile() noch irgendeinen Nutzen in Zeiten von responsivem Layout?

Heute möchte ich einen kurzen Blick auf eine Funktion in WordPress werfen, welche manche vielleicht für veraltet halten: wp_is_mobile() (zu finden in wp-includes/vars.php). Anhand des Browser User Agents stellt diese Funktion fest, ob die Seite von einem mobilen Endgerät abgerufen wird oder nicht. Was? Und das in Zeiten von responsivem Design? Fünf Jahre nach Ethan Marcottes legendärem Artikel über Responsives Webdesign?

Verwendung im WordPress Code

Und trotzdem, gibt es nicht Einsätze, bei welchen wir auf PHP Ebene wissen müssen, ob der Nutzer mobil unterwegs ist? Schauen wir uns zunächst an, wo wp_is_mobile() im WordPress Core Verwendung findet.

In der Adminbar

Wenn die Adminbar gerendert wird, wird mit Hilfe von wp_is_mobile() geprüft, ob das Endgerät mobil ist. Sollte dies der Fall sein, wird die Leiste um die Klasse .mobile erweitert (siehe wp-includes/class-wp-admin-bar.php), wobei, wenn ich das richtig sehe, es zu dieser Klasse keine weiteren Spezifikationen gibt. Auch der body-Tag wird des Admins um die Klasse .mobile erweitert, was Auswirkungen auf die Menünavigation hat.

Der Editor

Der WordPress Editor in der mobilen Ansicht
Der WordPress Editor in der mobilen Ansicht

Wenn man einen Blogpost verfasst, schreibt man diesen für gewöhnlich im WYSIWYG Modus. Zumindest hat man die Möglichkeit dazu. Jedoch nicht, wenn man mobil unterwegs ist. In diesem Fall wird die Funktion user_can_richedit() (wp-includes/general-template.php) false zurückgeben und nur noch der “Text”-Modus übrigbleiben. Der “Visual”-Tab, welchen man oben rechts findet verschwindet genauso wie der Vollbild-Knopf.

Weitere Einsätze

Desweiteren findet die Funktion noch Einsatz in Funktionen wir _device_can_upload(). Hier ist sie allerdings von keiner entscheidenden Funktion. WordPress nutzt den Boolean auch, um ihn beispielsweise an Javascript weiterzugeben. So beispielsweise im Customizer.

Wie funktioniert wp_is_mobile() genau?

Das Prinzip ist relativ simpel. Es wird geprüft ob der Useragent des Browsers einen der folgenden Textstrings enthält: “Mobile”, “Android”, “Silk/”, “Kindle”, “BlackBerry”, “Opera Mini” oder “Opera Mobi”. Sollte dem so sein wird true zurückgegeben, andernfalls false. Mit diesen sieben Teilstücken von Useragents sind alle wesentlichen mobilen Browser erfasst, was diese Funktion relativ treffsicher agieren lässt. Natürlich kann es immer sein, dass ein Nutzer seinen Useragent händisch ändert und damit durch das Raster fällt, doch übersieht man vereinzelte Grenzfälle ist diese Funktion relativ sicher im Aufspüren, ob das Endgerät mobil ist.

Weitere interessante Anwendungsfälle

Gerade mit dem letzten Mobile-Update von Google ist das Thema natürlich noch einmal in den Fokus gerückt. Mobile Geräte rendern Webseiten generell sehr viel langsamer als Desktopgeräte. Häufig haben sie auch eine schlechtere Internetverbindung. Das alles geht zu Lasten der User Experience. Wenn man nun vor allem für Desktop entwickelt, schwergewichtige Slider über die Webseite jagt und vieles mehr, so bedeutet dies für mobile Nutzer eine mittlere Katastrophe. Nicht nur sind Slider häufig dann doch nicht so mobil, wie man glaubt, es sind vor allem die Ladezeiten, welche hier häufig zu hohen Ausstiegsraten führen. Warum also nicht die Ausgabe von Slidern und anderen hochauflösenden aber vielleicht nebensächlichen Features mit wp_is_mobile() auf mobilen Geräten verhindern?

Oder man könnte eine schöne Zusatzfunktion einbauen, wenn der Benutzer mobil unterwegs ist. Häufig werden am Kopf der Seite ja Kontaktdaten wie Telefonnummer und dergleichen untergebracht. Wieso nicht im wp_is_mobile() prüfen, ob es sich um ein mobiles Gerät handelt und daraufhin einen SMS-Button unterbringen?

Fazit

Man sieht, wie selbst der WordPress Core aus einer Funktion, welche zunächst ein wenig veraltet wirkt, noch Nutzen zieht und auch die zwei kleinen Anwendungsbeispiele, welche ich präsentiere wären meines Erachtens besser schon bei der PHP Ausgabe ein- oder ausgeblendet, statt sie später mit CSS auf display:none; zu setzen.

Wenn Euch weitere Verwendungszwecke für die Funktion einfallen, oder wenn Ihr anderer Ansicht seit, ich freue mich immer über Kommentare. 🙂