Pixelpost

Some of you may be wondering what’s going on with the rumored Pixelpost v2.0. Well, as we’ve mentioned in previous posts, v2.0 is a complete rewrite, but we’re not simply trying to recreate the same issues with v1.0 again, we want to build a new core that can power Pixelpost for the next decade.

Believe it or not, the codebase for v2.0 has gone through many incarnations so far, in fact it’s in it’s forth rewrite.

What, you’re rewriting an app you haven’t released??!!

Yes, remember, we’re experimenting with new programing techniques and designs, and to be honest, not all of those experiments paned out like we planned.

In the previous incarnation of v2.0, the code was rather stable, but the whole system had gotten very complex and bloated, which goes against one of the core goals for v2.0: Simplicity.

We want v2.0 to be easy to use, flexible, and lightweight. And until we get the right mix of each, we really don’t want to call it finished.

But I’m happy to announce that the latest incarnation of Pixelpost v2.0 is looking very promising. It seems with each revision, the code keeps improving, and this latest revision is the best one yet. Will this one be it? Only time will tell, but I’ll let you in on a little secret…

Template tags are back, {{post.title}} anyone? Oh, and it’s possible that the dream of posting multiple images in a post just might come true.

Hello fellow Pixelpost users!

Only a few weeks after the latest release of Pixelpost I would like to announce the release of Pixelpost v1.7.3. It came to our attention there were a couple of places left in the code which could be used for an SQL injection or a XSS attack. So we’ve patched the code and threw in some additional bugfixes and other code as well.

If you have an older version, I’d highly recommend you to upgrade, if only for the security fixes alone.

So without further ado, here is the download link: pixelpost_v1.7.3.zip

For the technical minded, you can see the diff file for this version here: http://pastie.textmate.org/616485

If you want to keep with the latest development on Pixelpost, be sure to check out our Twitter account. And if you have any suggestions, feel free to send a message to @pixelpost, and we’ll check it out.

If you tried to upgrade from v1.7.1 to v1.7.2, even though it wasn’t necessary or suggested, the update script wouldn’t update the version number stored in the database. This bug has been fixed. Please re-download v1.7.2 from our site if you experienced this problem.

Hello fellow Pixelpost users!

I’d like to be the first to announce the release of Pixelpost v1.7.2. This version is a minor upgrade from v1.7.1, and focuses primarily on fixing a few bugs that some users experienced when using the included installation wizard. If you already have Pixelpost v1.7.1 installed, there is no reason to upgrade. But if you are using a version older than v1.7.1, I’d highly recommend you upgrade, if only for the security fixes alone.

So without further ado, here is the download link: pixelpost_v1.7.2.zip

And for the inquisitive users out there, here is a diff file showing all of the changes made in this version.

What is the most important part of a photoblog, besides the photos? In my opinion, I’d say it’s the RSS feed. It’s the piece that separates a photo album from a photoblog.

With the new version of Pixelpost v2.0 under development, I’ve been working on that very part. Currently, Pixelpost supports a few feed options, such as large photos, thumbnails only, thumbnails and text, etc. With v2.0 we’re going to revamp how feeds are created, so addons can easily customize the feed exactly the way you want.

How does this new feed system work? Actually it’s quite simple. Before the XML feed is generated, a PHP array, containing all of the feed’s elements, is created. Addons can easily add, remove or modify any of the array’s elements, just like you would with any PHP array. This makes it super easy for addons to add support for MediaRSS, or any other RSS extension.

After the array has been adjusted, it runs through the brand new Feed class, which takes the PHP array, and turns it into a beautifully formatted XML feed, complete with correct syntax, and code indentation. The class goes a step further and escapes any special characters that could cause a problem with the XML syntax.

In summary, this should make working with feeds a piece of cake.

If you’d like to see a sample PHP feed array, and the corresponding generated XML, check out the links below.

And as always, if you have any thoughts or ideas about the new feed system, please leave a comment.

PHP Array Generated XML

Thanks to a comment on the previous post, I decided to run a simple benchmark test on the new file based config vs a MySQLi database based config. The benchmark consisted of two tests for each config type, first a read test, which would read all 37 configuration options into an array, 10,000 times. The second test, a write test, would save an option 10,000 times. All tests were run on my Quad-Core Mac Pro via PHP CLI, so server load wasn’t an issue.

The results weren’t too surprising, the file based config was able to load 10,000 times in just 2.0413 seconds, that’s fast! The database version took 10.6869 seconds. And as you’d expect, the write benchmarks were the opposite. The database version wrote the new option 10,000 times in only 1.7795 seconds, where as the file based method took 4.3609 seconds. Why is that? It’s simple, a database can update a single row very efficiently, where as the file based config has to rewrite the entire file each time you change an option.

Another thing I noticed while testing, the file based config used substantially less CPU than the database version, but the file version required substantially more disk activity.

In summery, I think a file based config makes more sense, as load speed is more important for a web application like a photoblog. That being said, any information that will change on a regular basis, such post information, comments, and stats would be much better served by a database.

If you’d like to see the rough, but simple benchmark source code, check this out: http://pastie.textmate.org/516039

As always, if you have any questions or suggestions, be sure to leave a comment!

I’m sure some of you are wondering how things are progressing on the brand new v2.0. Well, first of, let me assure you that progress is being made, it may be slow, but it is progress! (We’re still looking for one or two developers to help speed things up, BTW)

Just recently, I’ve finished setting up a new configuration API, which will allow developers to easily configure Pixelpost, as well as create and save their own configuration options. The draft API looks something like this:

    // Change the active template to "Simple"
    Config::set("template", "simple");

    // Returns the active template "simple"
    Config::current()->template;

    // Create a new option, which contains an array:
    Config::set('my-option',array('value1','value2'));

    // Delete the option:
    Config::remove("my-option");

For the developers out there, you’re probably thinking, OK, this is nice, but it’s not really that big of a game changer. Well, here is the twist, rather than saving the options in a database table, like we’ve done in the past, these options would simply be saved in the pixelpost.php configuration file, as a php array. And since the configuration, generally speaking, only changes when you’re using the admin interface, the file won’t need to be updated that often. So, why should we store all the options in a database, only to require that it be queried on every page load by both guests and admins? Besides the speed benefit, both power-users and people who have are migrating their blog to a different server, can easily adjust the options for their entire blog by simply editing the pixelpost.php file, rather than firing up the admin interface.

This is a major change, we’d like to get some feedback you all, to make sure the development community agrees with this change. Because, after all, we’re building this for you! (And ourselves too of course!)

Pixelpost is in need of one or two PHP developers who know how to produce clean, well written code. Experience with object oriented programing is a plus, as well as past experience with mySQL/SQLite. Accepted applicants will become one of the developers in the close-knit Pixelpost core development team, which is responsible for creating the next-generation Pixelpost application. Applicants can expect hours of work, and no pay, other than the satisfaction of creating one of the best open source photoblog apps out there. If you’ve read this far, and are still interested in helping out, send an e-mail to jobs [at] pixelpost.org with a little information about yourself and a few links to some of the projects you’ve worked on.

You may have noticed that there hasn’t been much activity on the Pixelpost development front, but looks can be deceiving. Behind the scenes we’ve been working on some brand new exciting code, which will eventually become Pixelpost 2.0.

With this version, our goal is to make it faster, simpler, and easier to use than our previous versions. And we’re doing that by removing all non-essential elements, and making them optional plugins. And that’s where you come in, after all, we’re doing all this work for all of you!

Here is the question: What are the most important things you’d need Pixelpost to have built-in, and what things would you like to see as optional plugins?
Comments? Tags? Multilingual? EXIF?

Let us know in the comments!