Michael's Weblog

I've been recently asked to check out some CMSes for someone, and try to find a recommendation. What I've been finding hasn't really been encouraging. Out of the several CMSes I've tried, they've all failed for various reasons. I admit that I might be looking at this from a slightly different perspective than most - that of admining it and coding against it, rather than as a user - but it's still rather disappointing.

• Silverstripe is what I used first - but the forms (including the login to the admin) kept failing to render. In the end, I got sick of debugging it and started my hunt.
• Next up was Concrete5, which I heard mentioned recently. There were one hundred and fifty-five strict warnings in the front page of the installer. Bye bye.
• Next, CMS Made Simple. Its installer wanted E_STRICT and E_DEPRECATED removed from error reporting. At this point some folk might have continued; but that was enough for me not to consider it. I didn't have enough confidence in the code that I wanted to continue. It lost more points for the tarball not extracting into a subdirectory, which resulted in my document root being filled with nonsense.
• Joomla!... well, my last experience of it wasn't pleasant - I couldn't work out how the code was structured. It's also overkill for the requirements of this site.
• I would love to go for Habari, but the site isn't a blog, so it doesn't really fit the use case. It's still the top of the list just now, though.
• I could do what everyone else does and run Wordpress - but, again, the site isn't a blog, and I'd rather try something different.

I didn't consider Drupal or eZ Publish, which again I believed to be massive overkill for what is required of the site. What's going on? This is what PHP is supposed to be good at. Where are the simple, lightweight CMSes with modern code? Notices, strict and deprecation warnings should be considered errors when developing - this doesn't seem to be the case with many of the above projects.

So, that's what I've found. I now don my asbestos suit.

I've just committed two new plugins to the habari-extras Subversion. Firstly, there's the 'share' plugin, which adds the Facebook OpenGraph metadata to pages so that the Like button works, and also adds Facebook and Twitter widgets to the bottom of posts. Secondly, there's a bitly plugin, that pings bit.ly's API when every post is published and generates a short URL. This URL is then stored in the post info, and it provides a template to add it to the head of each page using the shortlink markup. I'd be interested in feedback from anyone more familar with Habari in case there's a better way to do what I'm doing.

• Share plugin
• Bit.ly plugin

I think I'm just about keeping to this one-post-a-week thing, almost. I've recently been playing with the internals of Habari, writing a couple of plugins. I've found it quite well put together, though I don't seem to ever get the Utils::debug() output to display properly - though this might have been due to the code I was writing running before a redirect. I believe though that I now have got 2 plugins which I'm going to investigate publishing - one which generates the Facebook and Twitter widgets at the bottom of the posts (and the relevant OpenGraph metadata for Facebook in the header), and another which pings bit.ly and generates a short URL for each post as it's published. I'm writing this post in part as a test to see that it works for real :-)

If I get a bit of time over the next few days, I'll finish tidying them up and make them available. If anyone's interested before I do, drop me an email or catch me on Twitter.

It's my intention this year to at write at least one post on here per week, ideally with some substance to it, rather than just recording what I had for breakfast (that being Twitter's job, after all). I'm not holding my breath about whether I will manage it or not, but I intend to give it a go. I have a draft in the works, which I will hope to get out there some time soon...

In actual news, I have been accepted to talk at ConFoo in Canada, on the subject "Making PHP See" - which is about image recognition using OpenCV and PHP. I'm really looking forward to the conference, and I'm fortunate to be up alongside some excellent speakers, so it should be great fun.

I noted a couple of comments after my talk on Cairo at DPC 10 yesterday, so I thought I'd respond to them here to clear up what's going on. It's always good to get some feedback about something I've been working on so I'd like to reply and keep the conversation going if I can.

First off, someone mentioned that the wrapper seems a bit beta and incomplete - and yes, that is true. The 0.2.0 release, which is the latest as I wrote this, is still marked as beta. The aim of me coming and talking about it is to try and get some more people interested in using it, so we can get some more information from real users about what works and what doesn't. I probably didn't help by mentioning that there are some features that we intend to implement that aren't there yet, which I'll list:

• Support for reading and writing images that aren't PNGs The developers of the core Cairo API are not really interested in handling all the various graphics formats that exist, so they decided to implement one and one only which is useful for getting data in and out. This is the functionality that we use at present. We (the developers of the wrapper) would like to fix that and handle JPEG, GIF, TIFF, and whatever new format is cool this week, but we're not quite sure how to go about that yet. We could recycle the code used by GD or use ImageMagick or GraphicsMagick, but those would introduce dependencies that people might not have available. Once we work out a decent solution here, it will be put in.
• Support for hyperlinks in PDFs and SVGs Again, this is something we'd quite like but it's not supported in the underlying library yet. There have been rumours about adding an API to do this, but there hasn't been a concensus about what's a good way to go about it. It's something I'd quite like to help fix, so I've been learning how Cairo itself is put together with the intention to add the support.

The other comments I saw suggested that the API is a bit fiddly, which I can't deny. It's not quite as simple to set up and get running as some of the other libraries in PHP already. This is nearly intentional - we're wrapping the underlying Cairo API as closely as we can, because we don't want to diverge too far from how other languages with Cairo wrappers work, so that developers who may be familiar with those already know roughly what is going on. It's for this reason that, for example, the API uses floating-point values from 0 to 1 to define the intensity of colours, rather than an integer value from 0-255 which most people are probably used to. This is because Cairo is designed not to make any assumptions about the surface you're going to be drawing to - some day we might get 16-bits-per-channel surfaces, and using float values means that we don't need to change the API or the values we're passing in to allow us to write to them. It'll just carry on working as it did before, just with better colour resolution.

However, if anyone has any ideas for how we could make things simpler, then we'd love to hear about it &emdash; drop us a line on the PECL developers mailing list (which you can find on the PECL mailing lists page), or find us on IRC on #php.pecl on EFnet.

There are a couple of things that I have worked on which sit on top of the Cairo extension, which can do some interesting things. If you're still at DPC I'll be demoing a couple of them on the uncon track at 2pm. It's only a 15 minute talk, so it shouldn't be too boring...!