How to Get Flash Working with WebkitGTK3

With the switch to GTK3 all Webkit using applications like Epiphany, Liferea, devhelp, yelp and others lost Flash support. The reason is that Linux-Flash is GTK2 only! And of course there won't be new releases from Adobe ever. So we have the following compatibility situation for Liferea

Uses Flash Status
GTK2 + WebkitGTK2 any native Flash Works
1.10 GTK3 + WebkitGTK3 v1.8 32bit native Flash Broken
1.10 GTK3 + WebkitGTK3 v1.8 64bit native Flash Broken
1.10 GTK3 + WebkitGTK3 v1.8 32bit Flash + nspluginwrapper Works
1.10 GTK3 + WebkitGTK3 v2.0 any native Flash Works

The WebkitGTK+ solution for the Flash problem was implemented in version 2.0 by having a second process linked against GTK2 to run browser plugins while Webkit itself is linked to GTK3. This makes Flash work again.

But the currently widely distributed WebkitGTK3 v1.8 does not have this feature yet and fails to use the native flash.

nspluginwrapper Workaround

The only workaround is to use nspluginwrapper to run the 32bit version of Flash. This is guaranteed to work on 64bit platforms. It might not work on 32bit hardware, sometimes also because nspluginwrapper is not available there. The steps to install it are:

  1. Install nspluginwrapper. On Debian
    apt-get install nspluginwrapper
  2. Download 32bit Flash .tar.gz from Adobe
  3. Extract /usr files according to the Adobe instructions
  4. In the tarball directory run
    nspluginwrapper -i -a -v -n

    to install the plugin

Now all WebkitGTK3 using applications should be able to run Flash. Ensure to restart them and check command line output for any plugin errors.

Upgrading to WebkitGTK3 2.0

If you can try upgrading to WebkitGTK3 2.0 (e.g. Debian Experimental).

PHP preg_match() Solutions for Typical Tasks

This post is to give an overview of when and how to use preg_match(). You will find that several task descriptions actually tell you not to use preg_match() which often is the first solution we think of when not knowing the PHP specific "best solution".

Extract date with preg_match

Format: DD.MM.YYYY

preg_match('/(?P<day>\d{2})\.(?P<month>\d{2})\.(?P<year>\d{4})/', $string, $result);

Format: MM/DD/YYYY

preg_match('/(?P<month>\d{2})\/(?P<day>\d{2})\/(?P<year>\d{4})/', $string, $result);

Format: YYYY-MM-DD

preg_match("/(?P<year>\d{4})-(?P<month>\d{2})-(?P<day>\d{2})/", $string, $result)

All three examples take the date to parse from $string return the day, month and year values in the $result hash. On successful matching $result will contain a result like:

array('year' => 2013, 'month' => 08, 'day' => 01);

Match IP with preg_match

To match an IPv4 address you can simply use:
preg_match("/\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/", $string, $result);

But as explained on StackOverflow this won't work for IPv6 and there is a better solution:


And for IPv6


Match Hostname with preg_match

Again a solution from StackOverflow, note that you need to do several checks for characters, total length and part length. For perfect RFC compliance this is propably not enough, but still good enough to untaint a hostname string:

function is_valid_domain_name($domain_name)
    return (preg_match("/^([a-z\d](-*[a-z\d])*)(\.([a-z\d](-*[a-z\d])*))*$/i", $domain_name) //valid chars check
            && preg_match("/^.{1,253}$/", $domain_name) //overall length check
            && preg_match("/^[^\.]{1,63}(\.[^\.]{1,63})*$/", $domain_name)   ); //length of each label

Match Email Address with pgreg_match

First: Do not try to develop something yourself!. If you still think you can start reading this LinuxJournal article and the respective RFCs. This is of course more complex than the host name matching as an email address usually contains one.

The IMO most interesting solution in PHP is to use checkdnsrr() and was described by this devshed article. It boils down to

  1. Sanity checking characters
  2. Extracting host name
  3. Testing host name by MX record lookup with checkdnsrr()

So this solution even gives up one checking the hostname syntax by just resolving it. This solution of course only works if you do not have to do too many checks per second. This might not be a good solution for massive checking without having a DNS cache in place.

When you still want to do only syntax matching try to use the PHP filter

filter_var($email, FILTER_VALIDATE_EMAIL)

Match HTTP URL with preg_match

Another case of do not try. Use the PHP filter instead:

filter_var($url, FILTER_VALIDATE_URL)

Extract HTTP URL with preg_match

Another case of do not try. Use the PHP function parse_url() instead. The example from the PHP manual shows how:



and it returns an array with all the parts:

    [scheme] => http
    [host] => hostname
    [user] => username
    [pass] => password
    [path] => /path
    [query] => arg=value
    [fragment] => anchor

Liferea Sync Support Status (TinyTinyRSS, TheOldReader, Feedly, AOL Reader, Digg Reader)

There is slow progress in the world of news aggregation services. Since the last post on possible sync implementations I was able to submit API access requests for AOL Reader and Feedly. There is a chance that the request for AOL Reader will be successful. The unexpected thing with AOL is that they require OAuth2 authentication which Liferea does not yet support. Still it will be possible to add it.

My clear favourites are still AOL and Digg. With two 3rd party hosters and one self-hosted solution (TinyTinyRSS) Liferea would provide a reasonable set of choices.

Name API Status Implementation Status
Google Reader Deprecated Implemented, Now Useless
TinyTinyRSS Published. Implemented, Stable
TheOldReader Published. Implemented, Experimental
AOL Reader Published API Key Requested
Digg Reader Planned 1) %
NewsBlur Published Not Planned.
Feedly Secret 2) API Access Requested

1) Digg has announced they will be implementing Google Reader API and hope is they open it up
2) Feedly has announced there will be a public API with v17

Liferea 1.10 GnomeKeyring Issue

If you are using 1.10 with the GnomeKeyring plugin, which will be automatically activated in GNOME environments, you might run into a strange bug (see SF #1099).

It appears that the keyring "liferea" created by the plugin can become "stale" - it just doesn't work anymore. At the moment I have no idea what triggers this and what is exactly the problem. If this happens Liferea cannot store passwords into the keyring anymore and you get password prompts all the time.

Workaround: Delete the "liferea" keyring from GnomeKeyring using the "seahorse" keyring editor. Ensure you have installed "seahorse" and launch it from the command line


and delete the keyring as shown in the screenshot:

TheOldReader Online Again

As reported on the TheOldReader status page it is online again since July 25, 21:07 UTC.

TheOldReader Down

If you are using Liferea with TheOldReader you currently see errors when synchronizing. This is caused by a storage incident with TheOldReader (see details here). There was an official mail from TheOldReader this morning informing about the downtime of approx. 1-2 days.

From the post

Here comes the worst news - this will probably take a day or two.
Sorry about that.

The amazing information in this post is that there are now 400k TheOldReader users!

So if you are affected please keep patient and give the guys credit for working so hard. After all it is a free service.

HTTPS Problems on ArchLinux

If you are using ArchLinux and clicking HTTPS links in the internal browser suddenly doesn't work anymore have a look at this bug report: It seems that a gnutls upgrade broke HTTPS in Webkit (which is the embedded browser in Liferea).

TheOldReader Sync Implemented

I originally intended to make AOL Reader work, but failed due to the undocumented and propably not yet published authentication API. I'll ask AOL about it, but if anyone knows please drop me a mail.

So I could not work on AOL Reader, so I choose to work on TheOldReader ( which I found very pleasant and stable. The API is close to Google Reader with the only limitation that it sometimes only has JSON support and no XML. As we use JSON already for TinyTinyRSS synching I could build on existing code.

So git master now has working experimental TheOldReader support!

This will be released soon with the initial 1.10 release.

So Liferea now has the following online synchronization support:

Name Status Import Google Reader
Google Reader Deprecated %
TinyTinyRSS Implemented, Stable No
TheOldReader Implemented, Experimental No
AOL Reader Planned, API not complete Yes
Digg Reader Planned, API not public Yes
NewsBlur Not Planned, API too different Yes
Feedly I registered Liferea as interested Client Yes

On the long term I'd like to support to new Google Reader clones to give Liferea users some choice along with TinyTinyRSS for the self-hosting choice.

Liferea synching to Feedly, AOL Reader and Digg Reader?

After Digg going live recently there are now three major free news aggregators available. With two of them you can register.

Today I migrated my old Google subscriptions to both Feedly and Digg Reader to have test accounts in case they open up their APIs. In the case of Feedly I did submit the developer registration, let's see if they find the Liferea user base large enough to respond. If you want to continue using a web-based aggregator you should migrate now to either Feedly or Digg Reader. Personally Digg feels a bit more like honest community than Feedly. But this probably doesn't mean much.

State of Feedly

Being the first to deliver the live migration Feedly gives you instant access, but no API. I guess they want to work only with some large aggregators.

State of Digg

Sadly Digg has post-poned the publication of their API for now. Meanwhile th import and the aggregator itself works fine. So let's hope.

State of AOL Reader

AOL Reader has an API, but I still don't have an account or I'd have started trying to port it. It seems they do not want or cannot scale as fast as intended.

Possibility of AOL Reader Support

Yesterday I took a look at the newly announced AOL Reader and of course its API. The API is similar to Google Reader, is actually somewhat simpler. So you for example can't do GET requests, everything needs to be JSON POSTs.

This is not really a problem, I believe the API can easily be implement by building on the Google Reader code and taking the existing JSON handling from our TinyTinyRSS API client.

At the moment I cannot do it, as I did not get an account for AOL Reader yet. The have a queue. Yesterday they gave out only 200k accounts. Let's see when they open up further.

If you want to lend an account for testing, feel free to drop a mail!

Syndicate content