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!

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.

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!

Thanks!

Well, it has come to our attention that on a Windows based web server with the PHP setting “register_globals” enabled, a hacker could use Pixelpost maliciously to read files located on the server.

If you are running Pixelpost v1.7.1, and are on a Windows server, please download the security patch below to play it safe. (It won’t hurt you if you’re on a Linux box either)

If you are running a version of Pixelpost older than 1.7.1, we recommend you upgrade to the latest version, which is available on our home page, as it already includes this patch. That way your photoblog will be safe and sound.

Download: Pixelpost 1.7.1 - Security Patch 1 (9 KB)

Installing Pixelpost can now be as simple as typing this single command: sudo apt-get install pixelpost

It doesn’t get much better than that!

You can find out more about Xavier, and his Pixelpost endeavors over at his blog: http://www.luthi.eu/blog/

http://www.linux.com/feature/128667