On the Delicious Brains site there's a new post from Gilbert Pellegram announcing serializededitor.com, an editor specifically designed to help visually edit serialized PHP data.

I recently built a command line daemon in PHP to emulate AWS SQSD for the purposes of testing in Mergebot. As it turns out, one of the benefits of building a large, complex product like Mergebot is that there are pieces of the system that we need to build for the project that might be of use to other developers.

Today, we’re launching that system piece, a free online visual editor for PHP serialized data as serializededitor.com.

In this article, I’ll explain how and why we built this “side” project and how I overcame some of the challenges I faced when building this project.

He starts off with the problem they were trying to solve when creating the editor, mostly centered around determining the differences between two pieces of serialized data. They found something similar to what they were wanting but it didn't provide the "easy editiing" functionality they wanted. He then goes through some of the issues they bumped up against along the way: working with the data and PHP's unserialize, the creation of their own parser, the work to create the Vue.js frontend and re-serializing the data once complete.

They've also open sourced the project over on GitHub so you can clone it locally and contribute back.

Paul Jones has posted an article to his site with another helpful hint to modernize your legacy PHP application. In the post he looks at updating serialized object handling with the help of the class_alias function.

Several weeks ago, a correspondent presented a legacy situation that I’ve never had to deal with. He was working his way through Modernizing Legacy Applications in PHP, and realized the codebase was storing serialized PHP objects in a database. He couldn’t refactor the class names without seriously breaking the application. [...] Before I was able to reply, my correspondent ended up changing the serialization strategy to use JSON, which was a rather large change. It ended up well, but it turns out there is a less intrusive solution: class_alias().

He talks about how this function could be useful to prevent the need for updating the class name in every serialized instance by setting up an alias to the new name. You can even use namespacing in the alias that will let the autoloader work with the PSR-0/PSR-4 handling to correctly load the class. With this in place, you can then refactor to the new version of the class without worry of breakage.

As mentioned on the Zend Developer Zone and by John Herren, Yahoo! has added a new feature to its Pipes functionality - serialized PHP results.

Until now JSON output has been the only way to obtain all the data flowing through a Pipe. Starting today we've added a second way of getting all the data - serialized PHP Pipe output. [...] It's then up to you on how you want to display or use the Pipe data. The possibilities are endless.

If you haven't messed with Yahoo's Pipes system, you owe to it to yourself to at least go and play with it for a little bit.

In response to Terry Chay's response about his previous blog post, Frank Kleine has posted a few more comments on the topic of object serialization and some of the assertions Terry made.

Terry Chay made some remarks to my last blog entry about a solution for lazy class loading without using __autoload(). Some of his statements seem like I explained my implementation not good enough leading to wrong interpretations. In this blog entry I'll use some of his statements to take a deeper look into my implementation and show that he has drawed some conclusions which I want to disprove.

He goes back and corrects some of what Terry has said in his response, including showing a more detailed version of him implementation. Be sure to check out the comments for the post, though - Terry comes back and clarifies some of the comments he'd made including the framework talk and changes of perspective having seen the new code snippet/information.

In response to Terry Chay's response about his previous blog post, Frank Kleine has posted a few more comments on the topic of object serialization and some of the assertions Terry made.

Terry Chay made some remarks to my last blog entry about a solution for lazy class loading without using __autoload(). Some of his statements seem like I explained my implementation not good enough leading to wrong interpretations. In this blog entry I'll use some of his statements to take a deeper look into my implementation and show that he has drawed some conclusions which I want to disprove.

He goes back and corrects some of what Terry has said in his response, including showing a more detailed version of him implementation. Be sure to check out the comments for the post, though - Terry comes back and clarifies some of the comments he'd made including the framework talk and changes of perspective having seen the new code snippet/information.

It seems that Yahoo! has posted their latest effort to help developers of web applications world-wide - the Yahoo! PHP Developer Center.

There are already several links to articles (HowTos on creating REST web services) and links to other code examples using the service. Along with this release, they also note that:

...many of their web services now return serialized PHP (developer.yahoo.net/common/phpserial.html). PHP developers will now be able to consume these web services even more easily than before. Yahoo!'s Search, Maps, and Travel REST web services now return serialized PHP by simply adding the "output=php" parameter to any web services request.

The example of this feature has been given in the form of a search for PHP-related podcasts: link here. The resulting output can then be used in a PHP application through the use of the unserialize function.

It seems that Yahoo! has posted their latest effort to help developers of web applications world-wide - the Yahoo! PHP Developer Center.

There are already several links to articles (HowTos on creating REST web services) and links to other code examples using the service. Along with this release, they also note that:

...many of their web services now return serialized PHP (developer.yahoo.net/common/phpserial.html). PHP developers will now be able to consume these web services even more easily than before. Yahoo!'s Search, Maps, and Travel REST web services now return serialized PHP by simply adding the "output=php" parameter to any web services request.

The example of this feature has been given in the form of a search for PHP-related podcasts: link here. The resulting output can then be used in a PHP application through the use of the unserialize function.