I’ll admit, when I first added the option for a user-definable extension to posts (i.e. post-name.html), I did it because it was the only way to get the darn thing working. I needed that extra bit of text to help differentiate sections from posts from categories from tags. Without it, WordPress couldn’t determine how to handle the different requests. Well, since then (a whole 3 days ago), I’ve become more familiar with the zen of rewrite rules (though they still mostly remain shrouded in mystery), and along with some refinement in the way sections are managed, I’ve been able to do away with the requirement for faux file extensions entirely. Note that I did not do away with the extensions themselves. If you want them, you can add whatever extension you like. But they are no longer required, and that’s the important bit. I don’t know if I just got used to having them around these past few days, but I actually think I like having an extension appended to the post’s title better that not having one. There’s a few reasons for this:

1. It makes URL’s more “hackable” – people are used to files having extensions and directories ending with slashes. By slapping an extension onto the post titles, I think it makes it clear that it is the end of the line. As a result, users will also be more likely to “know” that they could remove the “filename” (the post title + the extension) to get a listing of all the items in that “directory”. I believe this makes a site easier to navigate.
2. It’s customizable – I can choose any file extension I want, so I could add something that makes the site unique. I could even create a new file extension so people will wonder what the heck programming language I’m using the run site!
3. It’s confusing – Not really, but at least it abstracts the user from the underlying technology a bit. So people trying to scrape the site’s will have to work just a little bit harder to figure out what language is being used. I like a good challenge, so I figure they might too 🙂
   • Mass Edit – Delete Section(s)
   • Mass Edit – Change Parent Section
   • Mass Edit – Delete Posts
   • Mass Edit – Change Posts’ Parent Section

One thing that’s strange about this project is that I’m not approaching it in the say way that I do most other development projects. Usually, once I get a 0.1 version (the first working version), I import it into a Subversion repository and check out a working copy, and regularly commit changes to the repository. On top of that, I usually map out the project (using a tools such as freemind or the like), or at least track its progress using some sort of project management software (I’m currently testing OnTime for this purpose). However, with this project, I didn’t do either of these things. This project started with pen and paper, and has continued like that up until today. As I proceeded to fill up a small steno notebook with my notes on this project over the past couple weeks, I found it odd that this workflow was working for me, as I really like the idea of typing it in the first time around, so that all my notes are organized, indexed, and searchable later on. Yet, it was working for me, so I just kept doing it, all the while knowing that, sooner or later, I would have to type it all in. Well, today is not that day, but I have taken the first steps to managing this project from my computer. The reason for this is because my to-do list was getting bigger and spanning more and more pages in my notebook, all of which were separated by pages of notes that I made throughout the day. As my to-do lists got longer and more spaced apart, I started to lose track of the tasks that I had already written down for myself. It was time to bring this project onto my computer. I used OnTime to build a feature list for all the different areas of the plugin that I still need to add to and refine. I was also able to prioritize these features (though I would have like more than just 3 priority levels), so I know which features I need to tackle first so that I can get the plugin out to the public faster. I think this was a good idea as I now feel more organized and have a better idea of how much more I have before I can really consider this plugin “usable”.

Currently the list has about 40 features I’d like to add, though only a few of them are features I’d consider essential before this plugin is ready for public release. These essential features are:

As you can see, all the essentials are content management features, which I couldn’t imaging not having, nor would I call anything a very useful Content Management System without these features, so they are next on my plate.

Also, I now think customizable RSS feeds via the admin interface is very much a possibility, but I think I’ll make it a separate plugin so that anyone can use it. I don’t think it would take too much time to do, but I’m not the biggest fan of building the options menus, which such a plugin will require a fair amount of, so I think I’ll wait until I get the core functionality of this CMS plugin done first.