Hei Opera!

Opera was the first web browser I truly loved. In the early days of the modern web, when we had 4 or 5 real legit competitors in the browser space, Opera was truly innovative. In the year 2000 it was the first browser to support tabbed browsing  (2 years before Mozilla, 3 years before Safari and 6 years before Internet Explorer!). It was also the first browser to implement a built-in pop-up blocker around the same time. Mouse gestures may have been my favourite feature of Opera back in the day. You could to navigate the web by drawing shapes with your mouse (“J” for back, “L” for forward). Might sounds a little silly in 2016, but in the early 2000s multi-button mice were not common-place and OS supported trackpad gestures were unheard of.

I can’t recall exactly how long I used Opera or when and why I left. I suspect it was around the time that Mozilla’s Phoenix became the shiny new Firefox.

Over the past few weeks Opera has been making some small ripples in the tech press. Opera is doing a few related interesting things. So I thought I’d give it a try again after all these years.

For the past two weeks, Opera has been my primary browser on desktop, I’ve also tried out their iOS browser and free VPN.

Briefly on the mobile experiences.

Opera Mini is fine. iOS browsers are somewhat limited by being forced to use Apple’s rendering engine, so I wasn’t really expecting much. Opera mini has a “turbo” boost feature. By routing media request through an Opera system, image and video file sizes and be optimizes, improving page load times. I can’t say that I noticed the feature. However I’m not a heavy mobile browser user.

Opera’s free mobile VPN (with build-in ad blocking) is a great step in the right direction, public wifi (especially in hotels) is sketchy AF! I had the prefect opportunity to test this out on a 5 day vacation last week. Unfortunately, it fell short, the internet was slower and my battery drained faster with the VPN enabled. I don’t know if Opera’s technology it to blame, if it’s just the nature of VPNs in general, or even if it might be my perception. I turned it off entirely after 1 day of usage.


My desktop experience on the other hand, has been great!

Opera dropped their own proprietary rendering engine in 2013, in favour of Google’s WebKit variant, Chorium. This means the developers tools, browser extension support and overall rendering is identical to Chrome. And this is a good thing!

Screen Shot 2016-05-22 at 8.08.28 PMUsing Chorium as a platform to build on allows Opera to focus on adding features. For now, their main feature is built-in ad block. It’s good, quite good. It’s not configurable like a dedicated ad block extension, but it get’s the job done.

Opera also plans to release their free VPN solution for the desktop browser. I’m not sure when I’d use this (my desktop sits behind a network I trust), but this is something you’re unlikely to ever see from Google, Microsoft or Apple.

Overall, Opera is great and I think I’ll continue to use it as my daily driver.

Give it a shot, if only for the nostalgia.

Modern Mobile Redirect Using .htaccess

The following set of rewrite rules will redirect all Android, Blackberry, iOS, Windows and WebOS devices to a specific mobile directory on your website. Additionally, it will redirect Google’s mobile crawler – according to Google search spam czar Matt Cutts this is perfectly acceptable and even somewhat encourage.

To implement these rules:

  1. Replace “mobiledirectoryhere” with the path to your mobile site. If your mobile site is located in a subdirectory, use the full URL (including “http://”) and you can omit the first RewriteCond.
  2. Then copy & paste the ruleset into the site’s .htaccess file or the main apache configuration.

Rationale

Since the last time I wrote about mobile browser detection and redirection in 2009 the mobile device landscape has changed once again. Smartphones dominate the mobile browsing landscape and feature phones are almost not existant in server logs.

The old redirection rules I posted attempt to redirect every mobile phone under the sun. At this point in 2011, it’s probably safe to completely ignore ancient phones and simplify your Apache rules in the process..

How To Detect Mobile Visitors Using .htaccess Rewrite Rules, Simplified

Since my original posts on mobile redirection in .htaccess files I’ve gotten some comments and emails asking for step-by-step guidance on exactly how to “install” these rules. I hope this post will answer some of those questions.

Before you continue reading, if you have php installed on your server, you may want to consider Andy Moore’s php based detection solution.

The Basics

First off, some basic requirements. You’ll need:

  • Apache/Linux Hosting. Microsoft’s IIS has a completely different method for handling this sort of thing.
  • FTP access.
  • Apache mod_rewrite enabled. Depending on the type of hosting you have, it may be difficult to determine if you have this module installed and it may be impossible to enable if you don’t. If the steps below simply don’t seem to work, there is a good chance you don’t have mod_rewrite installed. Ask your tech support.
  • Mobile site in a subdirectory, eg. www.yourdomain.com/m/. This set of rules I’ve posted will not work with a mobile subdomain.

The Steps

  1. Download mobilerules2.1.txt.
  2. Open the file in your favorite text editor, replace the 2 instances of “mobiledirectoryhere” (without quotes) with the directory name you are using for your mobile site. Save it.
  3. Open FTP client, enable ‘view hidden files’ – files beginning with a dot are hidden on linux. This option is typically buried in a “view” menu or something to that effect. Results may vary.
  4. Navigate to your site’s webroot (probably ‘htdocs’ or ‘www’).
    • If there is already a .htaccess file present in the directory. Download it, open it in your favorite text editor. Copy & paste the contents ofmobilerules2.1.txt into the file. Save it, upload it.
    • If there is no .htaccess file present. Upload mobilerules2.1.txt as is, rename it to .htaccess.
  5. Your Done. Test it from a mobile device.

If you have any questions please leave a comment.

Note: This script treats all opera mini, iphone and android the same as other phones and browsers. Leave some comments if you’d like me to address this.

.

Revisiting Mobile Redirection Using .htaccess ReWrite Rules

This article is out of date, check my latest code snippet here.
Back in 2007 I wrote a post detailing a method for detecting and redirecting mobile browsers using .htaccess. Since then the mobile landscape has changed quite a bit: iPhone and Android have been released, the PDA market is all but dead and phones are better in general.

My original post was based on a PHP script by Andy Moore. It’s worth noting that he has continued to update his script and now has a fancy little generator to help you create a PHP based redirect ruleset. Check out detectmobilebrowsers.mobi for more info.

His solution will probably work for a lot of applications, but there are 2 main reasons I prefer using Apache’s rewrite rules to redirect mobile browsers:
1) Application independent. By putting the rules in the root .htaccess file you can easily redirect traffic across multiple directories, independent of any webapp that might or might not be running in those directories.
2) Faster. Placing the rewrite rules in apache’s httpd.conf file is potentially faster, than running the regexp in a php script for every request.

Enough of that, here’s the updated ruleset.

# don't apply the rules if you're already in the mobile directory, infintine loop
# you'll want to test against the host if you're using a subdomain
RewriteCond %{REQUEST_URI} !^/mobiledirectoryhere/.*$
# if the browser accepts these mime-types, it's definitely mobile, or pretending to be
RewriteCond %{HTTP_ACCEPT} "text\/vnd\.wap\.wml|application\/vnd\.wap\.xhtml\+xml" [NC,OR]
# a bunch of user agent tests
RewriteCond %{HTTP_USER_AGENT} "sony|symbian|nokia|samsung|mobile|windows ce|epoc|opera" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "mini|nitro|j2me|midp-|cldc-|netfront|mot|up\.browser|up\.link|audiovox"[NC,OR]
RewriteCond %{HTTP_USER_AGENT} "blackberry|ericsson,|panasonic|philips|sanyo|sharp|sie-"[NC,OR]
RewriteCond %{HTTP_USER_AGENT} "portalmmm|blazer|avantgo|danger|palm|series60|palmsource|pocketpc"[NC,OR]
RewriteCond %{HTTP_USER_AGENT} "smartphone|rover|ipaq|au-mic,|alcatel|ericy|vodafone\/|wap1\.|wap2\.|iPhone|android"[NC]
# put your rewrite rules here

Text Version

As you can see, the user agent list is a fair bit less verbose. I’ve been testing the ruleset on a very busy site, based on over 250k mobile site hits this set of rules is causing a lot fewer false positives, while not missing any significant number of mobile browsers..