Implementing these possibilities on your website requires knowledge of the OpenID and OAuth protocols, as well as specifics each site might have done differently than the standard. Once you start programming it, the code has a tendency to be a lot of copy-paste work with just small differences, and that isn’t making your code very clear.

As with a lot of programming problems there is a free, open-source solution: HybridAuth. HybridAuth tries to take away all specifics for the seperate social media sites and gives you a generic way of authenticating users to these sites while also providing API-access where applicable.

I think things like this are usually better explained with a piece of code(the code is inspired by examples from the HybridAuth website):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<?php
$config = dirname(__FILE__) . '/library/config.php'; // this config contains things like tokens and what providers are enabled
require_once './library/Hybrid/Auth.php';
try {
    $hybridauth = new Hybrid_Auth($config);
    /*
    * When the user is not authenticated this redirects that user to the twitter authentication page.
    * Twitter then sends the user back to this page
    * If the user is already authenticated it simply goes on to the next line of code.
    */
    $provider = $hybridauth->authenticate('Twitter');
    $user_profile = $provider->getUserProfile(); // getUserProfile() is available for every "provider" and contains basic information like the displayName and where allowed by the user: the e-mail address
    echo 'Hi there! ' . $user_profile->displayName;
    $provider->setUserStatus('Hello world!'); // This is an example of API-access, this specific function(getUserStatus()) is available in more providers    
    $account_totals = $provider->api()->get('account/totals.json'); // You can also directly call the api of a provider by using $provider->api()
    $user_contacts = $provider->getUserContacts(); // getUserContacts() is available in most providers, and does what it says: it gets the users friends/contacts
} catch(Exception $e) {
    echo 'Ooops, we got an error: ' . $e->getMessage();
}
?>

Now what if we want to do exactly the same, but for Facebook? That’s actually quite simple: the ONLY line we have to edit is the line that says:

1

$provider = $hybridauth->authenticate('Twitter');

and change it to

1

$provider = $hybridauth->authenticate('Facebook');

It really is that simple.

But does HybridAuth only support Facebook, Twitter and Google then? No, it supports way more, a list of all supported providers as of 23 march 2012:

• OpenID
• Facebook
• Twitter
• Yahoo
• Google
• MySpace
• Windows Live
• LinkedIn
• Foursquare
• AOL

And there is even an additional providers package available for download which adds support for:

• Github
• Gowalla
• LastFM
• Vimeo
• Viadeo
• Identica
• Tumblr
• Goodreads
• QQ
• Sina
• Murmur
• Pixnet
• Plurk

That is 23 different providers(counting OpenID as only 1 provider, even though multiple sites supports that). And even if you want your visitors to be able to login using another provider, it’s quite simple to add support for that, especially if that provider has OAuth support.

So does this HybridAuth library also have disadvantages?

The answer to that is: yes. But that doesn’t mean the library is useless. The biggest disadvantages I’ve found are:

1. If you plan to use it in a framework or CMS that abstracts for example the $_SESSION variable, it requires more fiddling than it seems at first sight to get it working. Even though there is a Storage class which you can easily edit to use something else than $_SESSION, the Storage class is not always used for storage, sometimes $_SESSION is hardcoded.
2. There are some small bugs that can still be quite annoying, and since the library seems to be largely maintained by one person it can take some time before the bug is solved in the main release.

For me these disadvantages don’t weigh up to the advantages. And if they don’t for you: just make a pull request at the Github page and fix it.

If you want to know more about HybridAuth you can visit the website: http://hybridauth.sourceforge.net/, which also has some documentation on how to use it.

One of the key features of this website was its search feature. It’s going to be a huge collection of items of different types: stories, events, news, profiles, images, videos and a lot more… All these types of  items can have the same properties: title, author, description, tags, dates, date ranges, specific locations, location areas and links to other items. These items can also have content which contains text, images, videos, links to other items and more. As a visitor you need to be able to work your way through all these items and that’s where the search comes in.

We wanted everything in the search we could think of and we wanted it to filter on most of the properties:

• Text: in text, tags, title, subtitle, description etc.
• Tag
• Location: both by region and within a certain distance from a specified location
• Time: both by a period in time and by a specific point in time
• Author
• State: published or not
• Used: used in other items
• etc.

I thought everything through and looked at each type of search option separately and concluded most properties weren’t a problem with the queries in our database MySQL. There were some that did pose some problems, but I found solutions for this in advance:

• Filter by a region: There are only 8 regions. When an item is added or edited we can just calculate to which regions it belongs and save that too.
• Filter by a specific location: Not filter by radius but filter by a box. We now have minimum and maximum longitudes and latitudes to filter by.
• Filter by text: Easy enough: just use a lot of LIKE ‘%word%’ and that’s it. When this would prove to be a performance issue we could always create a shadow table in MyISAM with a fulltext index and that’s it.

With a potential number of 20 tables involved with this query this wasn’t going to be an easy task and performance was going to be an issue. But I’ve read the book High Performance MySQL and a lot of articles on the MySQL Perfomance Blog. So I know the explain statement, I know MySQL can’t use more than one index from a table in a specific query, so I have to choose my indexes carefully and I know a large UNION statement performs better than a simple OR. I know everything I know to get the job done. What could go wrong?

The answer to this question is as simple as it is frustrating:
A lot!

The problems began when we started some test imports of images from external sources into our development environment. These were literally tens of thousands of images. Suddenly the site didn’t perform very well on our development environment: Our search query was taking 2 minutes to run when we hadn’t even used all the filtering options. No problem: we would locate the bottlenecks and fix them! We did and performance improved… a bit. We did it again and performance improved… a bit. So now we were really digging into the endless possibilities of queries and we were trying to find out which indexes were wrong and how we could tempt MySQL into using the right indexes. Until we ran into a bit of a problem: dependent subqueries, which really didn’t really seem that dependent at all… A bit of googling taught me this is a known problem in MySQL and there are workarounds. These workarounds involve writing stored procedures or clientside code to collect the data from the subquery in a separate query and feed the results to the main query. Because our subqueries can potentially produce thousands of results and they need to be combined with other subqueries, I didn’t think these workarounds were gonna give the performance benefits we were aiming for. It was time to sound the alarms…

Solr

It didn’t take very long to find the tool we needed. I attended a workshop about integrating site search at the dutch phpconference in 2010 where the speaker tried to – but couldn’t really – hide the fact that Solr was his favorite tool to use for site searching. With only a few weeks until the deadline we didn’t really have time to obtain knowledge about using a to us completely new tool like Solr. Luckily Bas de Nooijer was able to lend us a helping hand and we got Solr up and running and integrated in our site in just a few days! The performance benefits were amazing, though we did have some issues adding multiple locations and date ranges to the items in Solr. Without getting to much into the technical details I’ll try to explain what happened.

Multiple locations and areas

The newest beta versions of Solr do have support for multiple locations, but we didn’t want to take the risk of using a beta version. On top of that we still had the problem of multiple dates and dateranges. The problem of filtering on multiple locations and areas was solved by storing location and area ids in Solr so we could make a query in MySQL of which the resulting ids would be passed to the Solr query. If we would have a lot of locations this would still pose a problem but fortunately this was not the case.

Multiple dates and dateranges

Bas and I found a, what I think, clever solution for this part of the problem. We first thought we could store all days as a number within an item. Because we had items with ranges from 3000 B.C. until 1000 A.D. it turned out that an item like this really had to much days in it to be able to store it in any convenient way. This was solved by taking the full years out of these date ranges and store them in a separate field. The number of days was now small enough to be stored and we could filter by a custom date range by splitting it up into years and days and find the related items with a simple OR in the Solr query.

Thanks to Solr and Bas de Nooijer we could launch the site as scheduled with a very nice and fast search feature. Check it out at Oneindig Noord-Holland (site is in dutch).

Since a few years triptic has been acquainted with the guys of onlinespamfilter.nl. Onlinespamfilter.nl promises their clients to get rid of e-mail spam within 24-hours. The guys at onlinespamfilter.nl have built an ingenious filtering systeem that will recognise well over 99% of all spam. And it works! So when the developers at triptic were working on some of our clients’ weblogs, trying to get rid of form spam, we discussed this issue with Gerard and Jasper at onlinespamfilter.nl. We talked about using the powerful spamfilter combined with an API, in order to get rid of formspam in much the same way as getting rid of e-mailspam.

As you might know -when you’re a blogger for instance- that formspam can be a drag. Your blog makes it possible for people to post comments. That’s what makes your blog lively. Yeah! Sadly, spambots can also find their way to your commentbox. Result: you have to work your way through hundreds of irrelevant comments before you get to that one intelligent comment made by a designated reader. There is a “solution”. Of course! Just let readers type an unidentifiable series of letters, numbers and dollarsigns in a small box and all will be fine. <Not>.

So, the task before us seemed easy enough. Together we had to come up with someting clever. And we did! As a result you now can bèta-test our formspam killer. We lovingly call her SpamBeetle. SpamBeetle is available as a WordPress plugin. Little as she may be, she will beat the hell out of spam. Want to try it for your self? Send an e-mail to let us know that you want to be one of our béta-testers. We’ll send you al the information and API’s you need.

Keep in mind that some plugins might not work and need additional configuration changes after you have moved your blog. Please let me know about them.

I will distinguish between two types of migration: Only changing the url and moving to a new server.

Changing the url

You will only change the url to your wordpress installation. The code and database will stay on the same server. If you’re moving to a new server, please scroll down to “Moving to a new server”.

1. Install the ezmigrate plugin (when it’s not already installed).
2. Make the url change. For example by moving or renaming the wordpress directory or creating the new domain name and point it to your installation.
3. If you are using a caching plugin: empty or delete the cache folder(s).
4. If you are using Permalinks: go to the Administration > Settings > Permalinks panel and update your Permalink structure to your .htaccess file, which should be in the same directory as the main index.php file. (Text copied from the wordpress codex).

That’s it. There is no need to change any settings or do a search and replace in your database.

When you’ve moved to a new domain name and you don’t use any caching tool you will find that your wordpress installation still works on your old domain name as long as it still exists.

When you do use a caching tool and still expect visitors on your old domain you will need to make sure your old domain name will redirect to your new domain to prevent the cache from filling with pages containing old urls. This can be achieved for example by placing the following code at the top of the file wp-config.php:

if ($_SERVER['HTTP_HOST']!='www.newdomain.com') {
  header('HTTP/1.1 301 Moved Permanently');
  header('Location: http://www.newdomain.com'.$_SERVER['REQUEST_URI']);
  exit;
}

Moving to a new server

1. Install the ezmigrate plugin (when it’s not already installed).
2. Get a backup of your database by using any of the methods described at: http://codex.wordpress.org/Backing_Up_Your_Database
3. Download all of the wordpress files to your local computer.
4. Edit wp-config.php and change the database settings for the new server.
5. Upload all of the wordpress files from your local computer to the new server.
6. Place your database backup into the new database by using any of the method described at: http://codex.wordpress.org/Restoring_Your_Database_From_Backup
7. If you are using a caching plugin: empty or delete the cache folder(s).
8. If you are using Permalinks: go to the Administration > Settings > Permalinks panel and update your Permalink structure to your .htaccess file, which should be in the same directory as the main index.php file. (Text copied from the wordpress codex)

Again:  There is no need to change any settings or do a search and replace in your database.

Related articles:

• ezMigrate plugin for WordPress
• http://codex.wordpress.org/Moving_WordPress
• http://codex.wordpress.org/Changing_The_Site_URL

Now that PHP 5.3 has closure and lambda function support, we all would like to use it. However, not all of us are able to do so because we are still stuck with hosting providers not able or willing to upgrade to PHP 5.3. Wanting to use closures myself on servers that only support PHP 5.2 I came up with a solution to be able to use closures in PHP 5 versions prior to 5.3:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

<?
class PhpClosure
{
    private $variables;
    private $callback;
 
    public function __construct(array $variables, $callback)
    {
        $this->variables = $variables;
        $this->callback = $callback;
    }
 
    static public function get(array $variables, $callback)
    {
        $closure = new self($variables, $callback);
        return array($closure, 'call');
    }
 
    public function &__get($name)
    {
        return $this->variables[$name];
    }
 
    public function __set($name, $value)
    {
        $this->variables[$name] = $value;
    }
 
    public function call()
    {
        $arguments = func_get_args();
        array_unshift($arguments, $this);
        return call_user_func_array($this->callback, $arguments);
    }
}
?>

Before we take a look at some usage examples, let’s first take a look at some code that uses a closure in PHP 5.3:

1
2
3
4
5
6
7
8
9
10
11

<?
$var = 1;
$f = function($i) use (&$var) {
    $var += $i;
};
echo $var.'<br />';
$f(2);
echo $var.'<br />';
$f(3);
echo $var.'<br />';
?>

This produces the following output:

1
3
6

All following code snippets use the PhpClosure class to do exactly the same thing and produce the same output without PHP 5.3:

1
2
3
4
5
6
7
8
9
10
11

<?
$var = 1;
$f = new PhpClosure(array('var'=>&$var), create_function('$closure,$i', '
    $closure->var += $i;
'));
echo $var.'<br />';
$f->call(2);
echo $var.'<br />';
$f->call(3);
echo $var.'<br />';
?>

This looks a lot like the PHP5.3 code snippet! Of course, if you don’t like the way $closure->var needs to be called you can always add an extra $var =& $closure->var;.

Personally I don’t like the way create_function works. In my opinion the way you need to provide code inside a string makes it just as evil as eval. Also, your editor won’t show syntax highlighting or code completion for code inside a string. To overcome this I’ll give a name to my anonymous function. Now it’s not an anonymous function anymore, but the closure still works:

1
2
3
4
5
6
7
8
9
10
11
12

<?
$var = 1;
function increase($closure, $i) {
    $closure->var += $i;
}
$f = new PhpClosure(array('var'=>&$var), 'increase');
echo $var.'<br />';
$f->call(2);
echo $var.'<br />';
$f->call(3);
echo $var.'<br />';
?>

This is also possible using methods within objects by passing array($this, 'methodName') instead of 'increase'.

The last code snippet shows how to get a variable of the callback type to be able to use it with functions like call_user_func, usort or array_map:

1
2
3
4
5
6
7
8
9
10
11
12

<?
$var = 1;
function increase($closure, $i) {
    $closure->var += $i;
}
$f = PhpClosure::get(array('var'=>&$var), 'increase');
echo $var.'<br />';
call_user_func($f, 2);
echo $var.'<br />';
call_user_func($f, 3);
echo $var.'<br />';
?>

Related articles:

• http://www.steike.com/code/php-closures/

Introduction
At triptic we like to develop our projects on a development server using a Version Control System. That way we can work with multiple people on the same project and test it before putting it on a production server. We all have our own checkout of a project and our own url through which we can view our checkout of the project so we can test our code before committing it to the repository. We also like to use the same single database for all developers so we can look at the same content and the same settings. I know there are reasons not to do this, but for smaller projects it’s just a fast way of getting things done. When a project is finished we migrate everything to a test server so the customer can have a look at it before we move it to the production server. Because development on a project is never finished we need to be able to make code changes on the development server. We also need to be able to test it with the newest content, so we often move the production database back to the development database before putting the newest code onto the production server.

Short version:

• Our projects need to migrate a lot
• On a development server our projects need to be available through multiple urls at the same time

Our own solution
This is why our home grown Content Management System determines its location on the fly and puts a <base href=”"> in the header of every page. Additionally the current directory within PHP is always set to the root location of the CMS. This way we can use relative urls and relative locations everywhere in the code and we can move projects anywhere without the need to change anything. But sometimes our own CMS is just not the right tool for the job and we need to use some other framework or CMS.

The problem with WordPress
When we need to create a blog the obvious choice is to use WordPress. Unfortunately it doesn’t have the same characteristics  as our own CMS that allow it to migrate so easily. Absolute paths our stored in the database which need to be changed every time the project changes location. There are ways to do search and replaces and there even are plugins that help you to do this, but I really don’t like doing this every single time the project switches location. It also isn’t possible to view the project through multiple urls at the same time which doesn’t allow for development the way we’d like to.

So…, I went on a mission to fix this.

The result:
the ezMigrate plugin for WordPress

ezMigrate plugin

The ezMigrate plugin does the following things:

• It determines the root url of the blog.
• It replaces the options “siteurl”, “home”, “upload_path” and “fileupload_url” to the correct values, independent of their values stored inside the database.
• When not already set in wp-config.php it sets the constants WP_CONTENT_URL, COOKIEPATH and SITECOOKIEPATH to the correct values.
• When a post is saved into the database it replaces all root urls in href and src attributes with a placeholder. (This is also done for all posts when the plugin is activated).
• When a post is retrieved from the database it replaces all placeholders with the current calculated root url. (This is also done for all posts when the plugin is deactivated).

This way you don’t need to do anything when you migrate your blog and you can even make your blog accessible through multiple urls. It made life for me and the other developers at triptic a lot easier when we need to develop blogs using wordpress.

What this plugin doesn’t do (but might do in the future):

• Put a <base href=”"> in the header of your template. You can easily do this yourself by placing  <base href="<?php echo ezMigrate_getFullUrl();?>/" /> right after the <head> tag in the header.php file of your theme.
• Replace urls outside of the four mentioned options or outside of href and src attributes in posts. But so far it has been sufficient for my projects.
• Make changes that might be necessary in the .htaccess file.

This plugin is a step towards setting up a development environment with a VCS and multiple developers but there are still some problems to overcome. The contents of the .htaccess file are still dependent on the location and you might not wish to leave the .htaccess file sitting outside of the repository. I will write more about how to solve this in a future post, as well as what to do with the wp-content directory.

Download the ezMigrate plugin for WordPress and follow the installation instructions.

Comments on the usage of this plugin and suggestions are greatly appreciated.

Related articles:

• Moving wordpress using the ezMigrate plugin