So I’m looking to hand it all over to someone with more time and energy for it than I. Preferably someone who uses it in an active project (being primarily a ruby developer these days, I spend a lot more time with feedtools than with my own package). I’m going to mark the package as ‘unmaintained’ and if you want to take it on, take a look at the appropriate page in the manual.

And if you want the full story of why I’ve chosen now to make this move, it’s made fairly clear on flickr and my other blog.

Services_Technorati receives a version number bump, and little else. The alpha release was never meant to last quite this long given that it’s merely a port of a very stable package, and it’s finally marked beta. My hope is that the beta release will pick up a few more users to put it through its paces.

I had wondered about adding in some extra classes to encapsulate responses, but at the end of the day simplexml does a decent job, is well documented, and doesn’t add any overhead, so I’m happy just returning its objects and letting people work with them.

There are also a couple of bug fixes for the stable release of XML_Feed_Parser, kindly contributed by users. There are still a couple of outstanding tickets, but they’re issues which require more thought so I’m postponing them for 1.0.3 or 1.1.0.

So it seemed time to make the simple step of converting the code to be PHP5-only and use simplexml for their XML parsing. That removes the dependencies which were slowing me down, and should result in improved speed along the way as the XML parsing is now handled in C rather than PHP. I just released 2.0.0alpha1, but the code should be pretty stable and I’m hoping to run through the steps and get a stable release out very soon.

Update (27th Feb): I’ve just pulled this release and re-released it as 0.7.0. Apparently because the package never release 1.0 in its original version, I should just continue with the previous version numbers despite the change to PHP5.

You can get it through the usual channels, either downloading it directly or using the PEAR installer, and PEAR provides a bug tracker should you find any problems or have ideas for enhancements. My time to implement enhancements will be very limited, so I’m also very interested in hearing from anyone who’d like to sign on as a developer to help keep the package moving forwards.

Since HTML_Safe isn’t stable yet my plan is to put clear security advice in the manual and then if there aren’t any new issues with this release candidate to release it as a stable version. Once HTML_Safe stabilises I’ll revise the manual, work in support for that and release a new version.

This release fixes a few small bugs, mostly related to the packaging rather than to its operation, and I’m now bundling the various Relax NG schemas used for validation to save on HTTP requests. There is one open ticket that I’ll need to attend to, and then all should be ready for 1.0.

I’ve had a few requests for improvements to the package, mainly relating to improved handling of extensions, such as those beginning to appear for atom, but I decided to save those for a later (1.1?) release. If anyone would like to join me as a developer to work on those, I’d definitely welcome more involvement.

While many powerful authorization systems are purely role-based, something that can be achieved in LiveUser with the groups functionality covered in the previous entry on this subject, LiveUser also supports much more fine grained permissions. Each permission is its own entity, and permissions are grouped into areas. I created my areas directly in the database so won’t be covering that here. Once you have your area’s id in the variable $area_id and an instance of LiveUser_Admin in $admin you can call:

$right = $admin->perm->addRight(
  array('area_id' => $area_id, 
    'right_define_name' => 'a name for your right'));

to create the right and capture its ID in $right.

You can then ‘grant’ that right to a user with:

$admin->perm->grantUserRight(
  array('right_id' => $right, 
    'perm_user_id' => $perm_user_id));

Or grant it to a group with:

$admin->perm->grantGroupRight(
  array('right_id' => $right, 
    'group_id' => $group_id));

Where I ran into problems was when I attempted to check those permissions. From the API documentation, it wasn’t clear how to check for a right given only its name, but after a little exploration I put together the following method (used within my wrapper class) that handles it. $this->user is an instance of LiveUser and $this->admin is an instance of LiveUser_Admin:

function checkRight($area_id, $right_desc) {
  if (empty($this->admin)) {
    $this->getAdminInstance();
  }
  $filter = array(
    "fields" => array("right_id"),
    "filters" => array(
      "area_id" => $area_id,
      "right_define_name" => $right_desc));
  $rights = array_keys($this->admin->getRights($filter));
  $right_id = $rights[0];
  return $this->user->_perm->checkRight($right_id);
}

You’ll note that the final line makes use of the _perm property. In PEAR coding conventions a preceding underscore means a method or property is private and should not be accessed from outside the class, but this was the neatest approach I was able to find in the time. If anyone can tell me how to do this within the approved public API I’ll happily update this entry.

Update: Be sure to check out the comments, where Lukas has been adding some very useful information.

Two key developments in this version are support for the ‘content’ module in RSS2 and fix of a serious bug in the main __call method. I was accessing the compatMap variable (that handles the mapping of element names between different syndication formats) directly, and calling array_pop on it. That threw up problems if you wanted to access the same element multiple times, so I’ve added in a temporary variable to fix that.

The main development, however, is experimental support for the tidy library. If you think (or know) the feed you’re working with might not be valid XML, you can now choose to have tidy clean up the code before it gets handed to the DOM. Handling ill-formed XML is a much requested feature, and initial testing of this solution yields positive results.

The main focus has been on working through the tests that come with The Universal Feed Parser. I have a (rudimentary) script that converts those tests into PHP and makes some syntax conversion to bring them into line with my package. There’s still some hand tweaking required to get the tests running properly, but for the time being that seems preferable to writing a full lexer.

With those tweaks in place, the package now passes the majority of the Atom 1.0 tests. Along the way I’ve added a few new compatibility features (guid now maps to id in atom, in some cases uses of url/href will automatically map to uri where that’s appropriate), and cleaned up the workings of the __call magic function that does a lot of the dispatching within and between the classes.

Another major addition is the decoding of base64 encoded atom:text constructs.

Hopefully development will pick up speed over the next few weeks. My aim is to have a beta out some time in January.

I’ve cleaned up the handling of xml:base considerably, finally switching over to using PHP DOM’s baseURI attribute and checking the bases for all links returned, whether from link constructs or in text constructs with the type ‘xhtml’. That coincides with reworking the getText() and getContent() methods for atom so they now properly recognise the different types that the atom spec allows. There’s a little more work to do to properly allow non text/html mime types in atom:content, since I don’t want to return less common mime types without a way for the user to check the type beforehand. That should come in the next version.

I’ve had one enquiry as to whether the package will work for those not using PEAR. It’s dependency on PEAR is limited to the PEAR_Exception class, so for those who genuinely need to use it without PEAR, you could declare an empty class called PEAR_Exception that extends Exception and everything else should work. For those wondering whether there’s any way to get the code working with PHP4, the answer is ‘no’ since I make so much use of the PHP5 DOM implementation, plus simplexml and exceptions. For those looking for PHP4 support, check out Magpie.