PHP Development

Escape from FOSUserBundle

Posted on by Noel

Sometimes even great open source packages just fall off the maintenance wagon. FOSUserBundle, a historic go-to for the Symfony community, is sadly looking like one of those cases right now. Behind on updates for modern, long-term support Symfony versions, with calls to reconsider its pervasiveness going back at least as far as 2016, it’s no wonder there are questions about a migration path.

Unfortunately many of the problems with the bundle’s design – being very tightly coupled to the parent framework while not necessarily keeping up with its best practice – also preclude writing a good general purpose migration guide. But I’m hoping by documenting the biggest changes I had to make for my project to get out of FOSUserPrison, I can slightly reduce the time it takes to migrate some other projects.

Continue reading →

Multi-threaded quicksort! In PHP!

Posted on by Noel

Yeah! In PHP!

Why would you do this?

Well, I went to a PHP meetup presenting some common implementations and comparing them to the speedy native PHP implementation of sort() and related functions.

I figured that while efficient sorting isn’t the most common use case for PHP – and in a web context you often don’t want to let each user spin up numerous threads – for command line cases this approach should be able to provide a real performance boost.

In particular, the already-PHP-favoured quicksort algorithm works with a divide and conquer approach that should be perfectly suited to divvying up work between threads.

Continue reading →

Twig cache permissions for Apache + cron on CentOS

Posted on by Noel

I probably should have seen this coming, but when introducing Twig to a non-Symfony project, it hadn’t occurred to me to expect the same permissions dance that Symfony cover helpfully in their setup guide.

Having built a shiny new system that uses the same template cache for web requests (handled by the Apache user) and emailed reports (handled by another user via cron / command-line invocation), of course I hit exactly the same problem that those steps avoid. If you share any templates across the two users’ remits, eventually one will want to write to an existing cache file generated by the other user. It won’t have write permission, and Twig will freak out:

Continue reading →

Retrieving a user’s friends with PHP & the latest Facebook API

Posted on by Noel

I’ve not had to do much recently with Facebook APIs, which I found to be pretty poor a few years ago. However with some projects coming up which will need FB integration and the announcement this week that lots of things are changing, I thought it might be worth getting myself up to date and seeing if anything has improved.

To be fair, today’s PHP SDK looks to be miles ahead of what they were providing in 2011. But for all that the introduction of proper API versioning seems like a positive step, it doesn’t look like they waited to get the docs finished before announcing these changes! I found some PHP SDK documentation links broken (e.g. to the fundamental GraphObject!), and several features are only documented for PHP if you look at deprecated versions, which have a completely different instantiation style.

So on to my first post here! It’s not a very hard problem but it took me a little while to figure out how to list a user’s friends the ‘new way’.

Show me the code

Let’s assume you already have a FacebookSession called $fbSession, as that part is fairly well documented for the latest SDK. To get your authenticated user’s friends’ names in an array $this->_friends (keyed on user ID), you’d do:

$friends = (new FacebookRequest($fbSession, 'GET', '/me/friends'))
    ->execute()
    ->getGraphObject(GraphUser::className())
    ->asArray();

foreach($friends['data'] as $friend) {
    $this->_friends[$friend->id] = $friend->name;
}

This is working for me with v4.0.0 of the PHP SDK and the v2.0 API. I explicitly specified the API version in my FacebookRequest instantiation (not shown), but new apps should default to v2.0 anyway.

Since I didn’t find docs which even explained that I should look at ['data'] (I got to this through printing objects and trial & error), I’m unclear whether it’s possible to get actual objects for the friends listed and examine further properties. Given the new focus on privacy, with app-scoped user IDs and user-controlled sharing settings for each app, I suspect this may be all you get – but any comments would be helpful.

Where are your friends tonight?

Finally, don’t be surprised when your friend list is a bit shorter than before! The new API only returns friends who are also using your app. Perhaps a headache for some developers but I think a positive step for users concerned about data mining and which pieces of their information are being connected by marketers.

A cynic could argue it’s primarily an opportunity for Facebook to become the only ones who can connect those dots and to make more cash in the process – but I’d still rather have it this way than trust every single app to treat everyone’s data responsibly.