This posed a problem. Zend_Config_Writer will only write to a file, not update it. I would need to read in all the sections of the application.ini file (production, testing, development) and take into account any sections added by users and dependencies, remove the old file and write the new one. That seemed very heavy handed and dangerous.

Zend_Config has a merge() function, so the idea came to me to use two config files. Keep the application.ini file for system values that are ‘global’ across installations, and then added a local.ini for things like DB settings. Zend_Config_Writer would just write local.ini settings to the global space and everything would be great. Merge the local settings into the application settings and your done!

A problem surfaced. Manuscript is built using Zend_Application. Zend_Application takes care of all the bootstrapping, reading the config files, and setting up all the dirty stuff for me. It also only takes the path of single config file. I have two config files. Crap.

Luckily Zend_Application doesn’t automatically bootstrap itself, but it does load the configuration immediately. What I ended up doing was this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$application = new Zend_Application(
    APPLICATION_ENV,
    APPLICATION_PATH . '/configs/application.ini'
);
 
$localConfigFile = APPLICATION_PATH.'/configs/local.ini';
if(is_file($localConfigFile)) {
    $config = new Zend_Config($application->getOptions(), true);
    $local  = new Zend_Config_Ini($localConfigFile);
    $config->merge($local);
    $application->setOptions($config->toArray());
}
 
$application->bootstrap()
            ->run();

You initialize Zend_Application like normal and call the default application.ini. Zend_Application makes that config file available as an array, so I pull the loaded config back out and pass it into a new array-based Zend_Config ($config in the above). I create a second config ($local) with Zend_Config_Ini.

Using merge(), I merge the $local file into the $config file. This gets me a proper representation of what I wanted. I push this config back into Zend_Application and then call the bootstrap. The bootstrap is none the wiser that it actually is using two config files and my database gets bootstrapped properly!

It is not as clean as I want it to be but it gets the job done and users can override or add their own config information to local.ini and not worry about editing the supplied config file in the release.

Well, there is. The Zend Framework introduced a few classes to help facilitate uploading and working with files after they make it to the server. Taking advantage of Zend_Form_Element_File and the Zend_File_Transfer_Adapter_Http makes it dead simple to upload a file.

Generating a Form

The first step is to generate a form. I use Zend_Form more and more for this as it takes away having to do the markup for forms as well as provides an easy way to mark up the forms. Let’s make a simple upload form:

[cce_php]
class Form_MyForm extends Zend_Form {
public function init() {
$file = new Zend_Form_Element_File(’file’);
$file->setLabel(’File to Upload:’)->setRequired(true);

$submit = new Zend_Form_Element_Submit(’submit’);
$submit->setLabel(’Upload File’);
$this->assignElements(array($file, $submit));
}
}
[/cce_php]

Zend_Form 1.9.6 takes care of making sure that the form itself is set to to the proper encoding type for you and making sure that a MAX_FILESIZE field is set up. Less work you have to do! Now you just display that form in your view.

Getting the File

Now that we’re allowing the user to upload the file, how do we get it? You can go back to using the $_FILES superglobal and the upload functions but there is an easier way. Let’s take a look.

[cce_php]
// Check for Post and Validate your form before this

// Define a transport and set the destination on the server
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->setDestination(APPLICATION_PATH.’/../data/’);

try {
// This takes care of the moving and making sure the file is there
$upload->receive();
// Dump out all the file info
Zend_Debug::dump($upload->getFileInfo());
} catch (Zend_File_Transfer_Exception $e) {
echo $e->message();
}
[/cce_php]

So with 8 lines of code we have our error checking and getting the file moved into the proper place. It does all the is_uploaded_file, move_uploaded_file, making sure it gets there, and renaming the file. That’s it!

But wait, I don’t want the filename to be whatever the original filename was!

You’re covered. Zend_Filter_File_Rename allows you to rename a file however you want when you receive the file. Let’s say you allow the user to upload a new avatar picture for a Forum, and that file is always called ‘$userId.jpg’.

[cce_php]
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addFilter(’Rename’, APPLICATION_PATH.’/../public/images/avatars/’.$userId.’.jpg’);
[/cce_php]

That’s it. When the file is received (and that is the important part which I’ll show in a minute) it will be renamed and put in the appropriate folder. Notice I didn’t set a destination – when using the Rename filter, the destination is part of the filter.

Caveats

Receiving a file, and Zend_Form::getValues()

Always make sure to receive your file with the receive() method before calling the getValues() method on your form. getValues() will internally try and shuffle your file around since Zend_Form is aware of the file upload and receive() won’t work. It is an easy but frustrating mistake to make.

Renaming and Receiving a file

Try the following:

[cce_php]
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addFilter(’Rename’, APPLICATION_PATH.’/../public/images/avatars/’.$userId.’.jpg’);
Zend_Debug::dump($upload->getFileInfo());
$upload->receive();
Zend_Debug::dump($upload->getFileInfo());
[/cce_php]

You’ll notice that the name of the file doesn’t get rewritten until after the receive. This is because the file is already on the server by the time your code runs, the Transport just makes it easier to work with. It is important to remember this if you need the original filename but don’t want that to be the name on the local filesystem. Once the Rename filter is run the original filename is lost.

For example, in one internal project for myself I upload the files and hash the name on the filesystem, but in the database I need to have the original filename when the user downloads the file. In that case you can call all the Zend_File_Transfer_Adapter_Http() methods before the rename, receive the file, and then work with the file after that.

Going Futher

The manual for Zend_File has more filters and examples for the uploaded files. You can even have your form support multiple file upload elements with minor alterations to the examples above. There are validators specifically for files to make the file uploads safer (not foolproof, but a bit safter)

Take advantage of Zend Framework’s tight integration for forms and file uploads and make your life easier.

GIGO = Garbage In, Garbage Out

Those four letters are probably some of the most ignored four (OK, three) letters in programming. Most programmers assume wrongly that their users are not out to get them and destroy precious data, but they are. Fortunately most users don’t know that they are trying to destroy the precious balance that most web apps have, and unfortunately most web apps don’t care. Programmers then have to worry about the rest of the users that are trying to abuse the system, and then the users who are maliciously attacking the system. By ignoring GIGO, you end up with a sad list like the OWASP Top 10.

OWASP Top 10 – We Shouldn’t Need It

Despite what that heading says, I’m not saying that the Top 10 is a bad thing. It’s just sad that most of the vulnerabilities can easily be done away with if programmers just take a little extra time and remember to treat everything that a user submits as garbage. Let’s take a look two that should have never made the list, let alone made it to the top two:

• #1 – Cross Site Scripting (XSS)
• #2 – Injection Flaws (SQL, Command, etc)

What do both of these problems have in common? Both are caused by applications blindly accepting user input. The problem is made even more sad by the fact that PHP, especially, has many tools available to help mitigate these two types of attacks.

Filtering Out Cross Site Scripting

Cross Site Scripting, or XSS, is actually a form of injection, but instead of being executed by the server it is executed by the user’s browser. The classic example, one that happens so frequently it makes an appearance in the satirical Forum Warz, is of the guestbook or forum that just displays whatever a user types in back to everyone. Since the Forum (in this case) doesn’t actually do any filtering on the user’s input when they make a post, they can enter things like this:

[cce_html]
U’ve been pwned!!!!!~~~!!11009“1~

<script type=”text/javascript”>alert(document.cookie);</script>
[/cce_html]

While the author of the forum may have never intended for users to type in HTML tags, in this case a user did. Now anytime someone visits that post, a pop-up will show the cookie data to the user. An actual attack would probably post that back to a URL and be completely silent. So, how do we get rid of this attack?

PHP’s Filtering Functions

Whitelist HTML Tags with strip_tags()

strip_tags() can either be used in two ways – remove all the HTML tags in a string or to only remove tags that are not in a white list. This is convenient if you want to allow a subset of HTML to be used in an input form.

[cce_php]
// Grab the user’s input from POST
$message = $_POST['message'];

// Just remove all the HTML tags
$message = strip_tags($message)

// Only allow basic text formatting such as Bold, Italics, Underline
$whitelist = ‘<b><i><u>’;
$message = strip_tags($message, $whitelist);
[/cce_php]

This will filter out that nasty <script> tag in either case. This makes it extremely nice if the app uses a WYSIWYG editor like TinyMCE or FCKEditor that uses HTML natively instead of something like bbcode.

Convert HTML with htmlentities()

htmlentities() converts HTML entities (special characters) into their viewable equivalents. For example, to display the ‘less than’ symbol (<) you should actually type in ‘&lt;’ to make sure that browsers display it properly. htmlentities() will take a string and convert anything that has an entity to it.

[cce_php]

// Message is = <b>This is cool!</b>
$message = $_POST[‘message’];

// Now we’ll get: &lt;b&gt;This is cool!&lt;/b&gt;
echo htmlentities($message);
[/cce_php]

This is useful when you want to take text as it is and return it so that it displays properly. It has the side effect of also destroying attacks that rely on HTML tags since they tags are converted into displayable entities instead of interpreted by the browser. I call this a side effect because I don’t really suggest using htmlentities() in this way. If you are not going to allow HTML at all, strip it with strip_tags().

Use PHP 5’s filter_input for a common interface

PHP 5.2.0 introduced a new funtion, filter_input(), which allows for a single function to do different types of filtering and validation.

[cce_php]
// These two should do the exact same thing, strip all HTML Tags
$message = filter_input(INPUT_POST, ‘message’, FILTER_SANITIZE_STRING);
$message = strip_slashes($_POST[‘message’]);
[/cce_php]

While nice, it needs to be expanded a bit to become extremely functional for anything other than basic use.

Zend_Filter Makes it Way To Easy

Zend_Filter, part of the Zend Framework, exposes a great deal of filtering and makes it easy to integrate with allowing user input. Zend_Filter will filter using:

• Alphanumeric
• Only Alpha (with or without whitespace)
• Numeric
• HTML Entities
• Whitelist HTML Tags

[cce_php]
$alnum = new Zend_Filter_Alnum(true); // Filters out everything but letters, numbers, and spaces
$alpha = new Zend_Filter_Alpha(); // Filters out everything but letters, including spaces
$tags = new Zend_Filter_StripTags(); // Filters out just HTML Tags
$message = “Let’s <b>filter</b> this message out!!!111!”;
echo $alnum->filter($message); // Lets bfilterb this message out111
echo $alpha->filter($message); // Letsbfilterbthismessageout
echo $tags->filter($message); // Let’s filter this message out!!!111!
[/cce_php]

Zend_Filter also allows for Filter Chains that allow a programmer to add a bunch of filters and apply them all at once. This is useful if you want to strip out all the HTML, and then strip out any remaining special characters, unlike the first filter example where the text inside the tags is left.

The real jewel with Zend_Filter comes when used with Zend_Form. Zend_Form allows for forms to be built in PHP and then sent to the browser. When generating elements for the form, the programmer has the option to add filters and validations to elements that are fired off when the form is processed. A full tutorial is beyond the scope of this article, but the documentation shows how to use filters on the elements here.

Remember, Don’t Trust Your Users

I’ll tackle Injection attacks in another post, as there are different types of injection attacks. For now though, always remember to sanitize and filter ANY input that you accept from the user. While most users are not trying to be harmful, there are ones out there that are. It also means one less thing you have to worry about being a flaw or bug in an application.

PS: Hungarian Notation

One thing that may be useful that I picked up from Joel Spolsky is the concept of (proper) Hungarian Notation. Have a read through his post for the proper way to do Hungarian Notation and why it makes sense.

What Hashing Is

Hashing is a mechanism for figuring out if two things are similar and is a one-way process. You take an object (file, string of text, ISO) and convert it to a fixed length string. You can then use this key to see if something else is the same thing.

The most common example of this is with large downloads. All the major Linux distributions will give an MD5 hash for their downloads so that you can verify that the file was not corrupted during transmission. You can run the ISO file through an MD5 generator which will give you back a 32 character string. If that string matches what Canonical says was their MD5, you have a match and your ISO is good.

In programming, one of the most common methods for hashing is password. In this case it is done for two reasons:

1. You never, ever store passwords in Plaintext in a database
2. You never should care what the user’s password is

Since #2 means you never need to know what the hash stands for, Hashing is a light-weight alternative to encryption while still providing security.

$password = md5($_POST['password']);
$username = $_POST['username'];
$result = mysql_query("SELECT username, password FROM user_accounts WHERE password = '$password' AND username = '$username'");
if( mysql_num_rows($result) == 1 ) {
echo 'Found a proper account!';
} else {
echo 'Invalid username and Password';
}


Salts

No, not Bacon Salt. Salts are additional bits of text you add to something before hashing to prevent someone from cracking the hashes that you are using.

$salt = 'ThisIsAReallyLongAndSecureString';
$hash = md5($_POST['password'] . $salt);
echo md5($_POST['password']) . ' != ' . $hash;


Salts are only useful if you are trying to use Hashing for security reasons, like storing passwords. If you are looking for just verification then a salt is useless. If you are using hashing for security purposes, ALWAYS USE A SALT.

Proper Hashing

Prior to PHP 5.1.2, the two most common ways to hash a file was to use either of the built-in hashing functions for MD5 or SHA1. Due to the fact that MD5 and SHA1 are considered insecure I don’t recommend using them even with a salt. You can generate a hash very easily using either MD5 or SHA1 and it should work on every single platform.

$sha1 = sha1('This is a string');
$md5 = md5('This is a string');


Since 5.1.2 PHP has added a proper hashing library that allows you to take advantage of more powerful algorithms. It is turned on by default, but if PHP is compiled by hand it can be disabled.

You can find out what algorithms are installed on a system by running the hash_algos() function. This returns an array of different algorithms that are installed on the system and that are available for use. These are also the names that can be used with the companion function hash(). So, if you wanted to store a password in the database the proper way using a hash, you would do something like the following:

// Our Salt
$salt = 'SuperSecretSaltNoOneWillEverFindOutAbout';
// The user-supplied, unhashed password and username
$usPassword = $_POST['password'];
$sUsername = mysql_real_escape_string($_POST['username']);
// Generate a SHA-384 hash using our salt
$sPassword = hash('sha384', $usPassword . $salt);
// Save it to the DB
mysql_query("UPDATE user_accounts SET password = '$sPassword' WHERE username = '$sUsername'");

Fine, what is Encryption then?

If Hashing is a one-way street, Encryption is two-way. You would use encryption whenever you need to safely store information but need to retrieve it later. (Again, you almost never need to know what a user’s password is, so why use encryption?) Encryption is also a heavier action than hashing.

Say we had a table, user_accounts, which had the following fields:

• id
• username
• password
• name
• social_security_number
• address_street
• address_city
• address_state
• address_zip
• cc_number
• cc_type
• cc_cvv
• cc_exp_date

We would want to hash the password obviously. ID, username, and name we can probably not worry about doing anything too. Everything else though we would want to encrypt as all that information can be used in a very destructive manner if the database is stolen, but we need to use that data. Encryption would allow us to store that information in the database and sleep at night, yet still pull it back up when we needed it.

Keys

Keys, unlike Salts in hashes, are required. The key is used during the encryption process as a constant. If you use the wrong key you will not get back what you stored as the key is actually used for both encryption and decryption. Like a Salt, you’ll want to store this somewhere such as a file with limited read access.

For security reasons you will also want to look at a key rotation plan. One advantage that hashing has over encryption is that it is not meant to turn the random output of the hash back into something useful, where encryption is designed for just that purpose. If someone gets a hold of the encryption key, it is trivial to decrypt the data.

You will want to consider a key rotation plan because of this. Every set number of days you will want to decrypt all the data using the old key and re-encrypt it with the new key. Yes, it is time consuming, but that is the tradeoff for using encryption and staying secure.

Encryption Made Easy

PHP can do encryption as well as hashing. I personally prefer using the Mcrypt library that is available on most Linux systems, but PHP can also use OpenSSL. Encryption is a fairly heavy weight process and requires a bit of setup to get going. I’ve created a simple class for setting up and using Mcrypt at http://code.google.com/p/tws-code/ .

$key = 'SuperSecretKey';
$twsMcrypt = new Tws_Mcrypt($key);
$encryptedString = $twsMcrypt->encrypt('This is a secret message');
$unencryptedString = $twsMcrypt->decrypt($encryptedString');

Tws_Mcrypt can also take a second constructor argument to specify the type of encryption to use, otherwise it defaults to RIJNDAEL_128. It also encodes the encrypted string in Base64 to make storage easier, so if you encrypt something using Tws_Mcrypt and try to decrypt it straight, make sure you Base64 decode it first.

“Unless you are a cryptanalyst, don’t do your own crypto”

One final comment on hashing and encryption. The algorithms that are used in either case are tried and tested algorithms that are hard to crack and, in some cases, extremely sophisticated. People much, much smarter have taken the time to develop them and you, me, nor anyone that is not a cryptanalyst will do better.

Don’t think that the nifty encryption algorithm you came up with last night while you were in the zone will be any better than the ones that ship in PHP or in libraries like Mcrypt or OpenSSL. It won’t be and will only put you at risk.

So which to use?

Use Hashing when:

• You don’t care what the actual data is
• You just need to do verification
• You need something extremely light-weight

Use Encryption when:

• Data needs to be secured, but pulled back up later

Keep all this in mind next time you are talking to someone about how your application works. Don’t tell them you are encrypting passwords in the database when what you are really doing is hashing them. Don’t think that using straight MD5 is a viable means for data security.

Hopefully this will help you choose which type of security based on what you are doing as well.

Photo by steveluscher (via Flickr)

Over the last few days, I’ve seen two discussions on mailing lists that I subscribe to. One was on the Zend Framework MVC list and the complexity of Zend Framework and and the second was on the OpenBSD misc mailing list on the degradation of the computer industry as a whole.

I’ve been programming for as long as I can remember, starting with BASIC on an old Tandy that we just happened to have since my father worked at Radio Shack years ago. From there I had a dry spell until the web started to take off and I learned HTML (yes, it isn’t a programming language but a markup language, but humor me). Javascript was about as tough as I would get until dabbling with some C++ books during high school.

During college I was blessed with having a great teacher that taught me one thing: Programming is an art, and it takes patience and learning to get it right. I had him for two years across multiple languages (COBOL, RPG ILE, Visual Basic .NET, C++, C#, AS/400 CL) and every single class was the same thing, just a different syntax. Why?

He was teaching how to program, not how to slap some language verbs together and get a running program. A programming language was nothing more than a tool, and there is a reason that there are so many languages out there. Define a problem, pick the appropriate language(s), and develop a solution. VB isn’t the answer to everything, and neither is C#, Python, or PHP. If you need a quick and dirty Windows app, use VB.NET/C#. Need a web app, pick Python, PHP, or .NET.

Of course, a major part of learning the art of programming is the ability to troubleshoot. If code isn’t working, it is a programmer’s job to find out why. It is also the programmers job to keep on learning and diving into the more complex nature of languages to better themselves, their code, and their ability to move forward.

My favorite language thus far is PHP. The strength of PHP and its weakness is that PHP allows anyone to pick up the code and develop extremely powerful web applications (or desktop apps if one is inclined) with little knowledge of what they are doing. One doesn’t need to know what they are actually doing when there are multitudes of tutorials out there that just spoon-feed up-and-coming ‘programmers’ solutions. Take a look at stackoverflow.com’s PHP questions and you’ll see what I mean.

The main gripe of the original author of the Zend Framework thread was that Zend Framework was too complex to be useful to new programmers. No, it isn’t. Zend Framework is complex and hard to use to programmers that are lazy and can’t be bothered to actually learn what is going on with the tools that they are using (though I will admit I still am dismayed at the new Bootstrapping process, but just because I don’t like it doesn’t make it hard, and I see where it is going).

Each new version of Zend Framework is more complex than the last but that is a trade-off of progress. As a programmer this should not be an issue. You have the source code and what I consider some of the greatest documentation for a framework out there, and there are some great people leading the team. If a framework and its core principles are too hard, either switch frameworks/languages or learn. Don’t complain (unless it’s a bug, but then ZF is open source so just fix the bug).

*Just as a note, I’m not saying that function-based programming is any easier or better. The Drupal and Wordpress source code can be just as complex as the Zend Framework and it’s OO-based approach.

jQuery is being employed in the Adminstration area to make it function much easier and cleaner than ever before:

The Plugin model has been revamped from the old BiffCMS months ago as well as the addition of Sections. A nicer WYSIWYG editor is in place over the old BiffCMS. All in all, Kiroku has grown a lot since BiffCMS was started by me years ago as a quick way to design and maintain web pages.

There are a few other projects that I’m working on and, as they grow, are moving away from the Biff name. The BiffAPI most of my code was built on in the PHP4 days is no longer worthwhile since I’ve moved on to the Zend Framework, so its appropriate that these project names change.

If you’re interested in working with Kiroku, just drop me a line through e-mail or hit me up on Twitter.

Among my time spent getting to know the PHP community and finally getting to meet the people I talk with on #phpc, I managed to attend a few sessions.

Day 1

While I wasn’t present for the tutorial days, I was there for the main body of the conference. Andrei Zmievski, after being released from captivity, assured us that at some point PHP6 will be released and will contain some great features (granted, Sara Golemon showed us exactly why PHP 5.3 is going to be the next big thing to look forward to with features such as lambdas, smarter garbage collection, and other things that are as cool as velociraptors).

From there I attended Christian Wenz’s talk on Ajax testing and the tools that can be used. I wanted to hit up some of the talks that would help me out at work, so from there I listened to a talk by Mike Pavlak about running PHP on the IBM i brand of servers (who knew that PHP was a first class citizen on the i?). Stefan Priebsch gave some pointers on how to build an MVC application, I listened to Wez Furlong give a great talk on getting things done by using the Scrum method of application development planning, and I finished out the day listening to a talk by Chris Shiflett on security centered design and common mistakes that sites make in their assumptions with user security.

I rounded out the day by listening to Michelango van Dam give a great Uncon talk about using PHPUnit for Test Driven Development.

Day 2

My second day started off with the earlier mentioned talk by Sara Golemon on the new features in PHP 5.3 (my opinion – I cannot wait until PHP 5.3 arrives). After that it was a talk by Derick Rethans on K.I.S.S (Keep It Simple Stupid) design tips for web applications, Jason Sweat on common design patterns for use on the web, and then over to Paul M. Jones for a talk on organizing your web project (thankfully I’m doing it right on Kiroku and Congregate!). I got to see Rich Bowen talk about mod_rewrite, and I finished off my day attending to hack-a-thon (more on this in a later post). There I met Brett Bieber who works on the PEAR2 project who showed me how to start testing PEAR2, the new features it will bring, and even gave me a shirt!

Day 3

Day three was the last official day of the conference. Sean Coates gave a talk about tokenizing in PHP and how to leverege it for a developers own use, Cal Evans gave a great talk on why telecommuting is no longer a perk but an expectation for PHP developers, and Terry Chay gave an empassion, funny, (and moderately curse filled) ending keynote on why PHP developers are engineers and why that is what makes us stand out in the crowd.

This day finished off with a talk by Paul M. Jones on why personal frameworks suck but are a natural right of passage, and Michelango van Dam gave a second Uncon about Continuous Integration.

My Quick Take

This years php|tek was even better than last years. Not only did I get to meet a ton of great people but I learned a lot more than I could have even hoped. The PHP language is poised to continue to be one of the best, if not the best, web language that there is despite opposition from Sun/Oracle’s Java and Microsoft’s .NET. PHP 5.3 and 6 are adding sorely needed constructs to the language that will do nothing but improve the quality of software that developers can write.

For all the crap that PHP takes, there isn’t anything I can see in the upcoming releases that will make me want to switch.

I want to thank all the people that I met there, and if I left anyone off the list I apologize:

@enygma, @sweatje, @nateabele, @brandonsavage, @EliW, @tswicegood, @elazar, @DragonBe, @CalEvans (even if he doesn’t remember me) and everyone else who I didn’t catch their twitter handles or irc names.

What was overhauled?

The basic folder structure and some plumbing were overhauled in the last few days. The introduction of a ‘plugins’, a ’sections’, and a better theme system were all moved around and coded to allow for easier development. If you were using the Zend Framework version of BiffCMS all you will need to do is move some files around, but this is not a simple ‘overwrite files’ kind of upgrade.

Plugins

The heart of BiffCMS has always been Modules, which dictate what pages you can add to your site through BiffCMS. Since this has a much different term to Zend Framework developers these are now renamed Plugins and are much more easy to develop. Using the new ‘plugins’ folder, each plugin is now fully self contained inside its own folder. Need to install a new plugin? Drop it into the ‘plugins’ folder and go from there (still needs to be manually entered into the DB, but work on installation is coming along).  I’ve also added an Externallink plugin that allows pages that direct to outside URLs.

Sections

BiffCMS is built using Zend Framework’s MVC components and therefore has full support for Zend Framework modules (collections of Controllers and View Scripts). BiffCMS calls these Sections and they can be used when a simple page Plugin is not enough. Drop them into the ’sections’ folder and add them to the index.php page just like a regular Zend Framework module. Work is also progressing on allowing Sections to be enabled and disabled via the admin GUI.

Theming

The last thing a web developer wants is for his website to look like everyone elses. BiffCMS now has support for packaged themes, much like the BiffAPI version used to. Just create a folder containing at least a ‘layout.phtml’ and an ‘admin-layout.phtml’, drop it into the ‘www/themes/’ folder, and you can select it from the System Config portion of the Admin. These are just regular Zend Framework layout files so existing layouts can be easily ported.

Administration

Along with the above changes, BiffCMS now supports adding and editing users (deleting coming soon!), the beginnings of a System Config section to allow low level config changes like Themes, and a better Plugin management system.

If you want to check it out, head over to http://code.google.com/p/biffcms and check out a copy of the SVN. Within a few weeks there will be a formal release as some loose ends are tied up.

Want to know how easy it is to get up and running with BiffCMS? I installed the app, ported the layout, and added a few pages in just about four hours total. Less than half of a day and I’ve got a site that I’m happy with and will have to do less to maintain than the straight Zend Framework-based site that was there before.

Want to try out BiffCMS? Head on over to the Google Code site and check out the latest working copy. I’ll be bundling a full release here within a week or so.

What does it do?

Right now not a whole lot. You can add projects and tasks to those projects. Thanks to the beauty of jQuery and AJAX you can edit the tasks right there in the table without having to go to any special pages so updating your tasks is as simple as using a spreadsheet. It is great for simply noting down what you need to do but in the coming weeks it will be expanded to do much more. Time spent on each task is recorded as well as who completed the task.

Installation

Installation is fairly easy. Check out a copy from SVN and put it up on your web host. You will need to edit the ‘public/.htaccess’ file’s rewrite rule to the path that you unpacked it to. Once that is done run the SQL setup script in ‘data/db/base.sql’ to set up a basic database. That’s all there is!