Archetyped

While the interface I’ve built may work fine for small sites, I realize that it would not work so well with sites that have a lot of content. For sites with large amounts of content, pagination would be pretty necessary, as would a way to filter what posts are displayed.

I’ve started thinking about how to create an interface that will work equally well for small sites and content-heavy sites alike.
Here’s a mockup of what I’ve got after working on it a bit this morning:

For comparison, the interface as it is now:

Basically, I’ve added some filtering options at the top, as well as display options for each section. I think it starts to look too busy when the options for each section are displayed, but I think it’s really important that the options are at a per-section level so that you can flip through the posts for a single section without affecting what the other sections are displaying.

Also, listing of the content is currently table-based (to keep in line with Wordpress’ default Page/Post listing interface), but think I might move to a <div>-based layout for more flexibility.

It seems that in the process of getting the mass editing features working yesterday, I inadvertently borked something else! I thought everything was working fine, but when I reloaded the main page, I got no response, and php.exe was slamming my CPU. Not good. I wanted to get it worked out, but as tired as I was, I soon realized that I wasn’t getting anywhere, so I left it for the next day.

This morning, I attacked the problem again. Unfortunately, restarting my computer didn’t help . Deactivating the plugin, however, did help, so I knew where the problem lay. I was messing with a bunch of utility functions in my plugin yesterday, so I figured I must have forgotten a bracket somewhere and sprung a leak, causing the PHP interpreter to go into an infinite loop. I couldn’t find any issues with the code just by stepping through it so I removed all the code from the plugin, and re-added it back to the file one function at a time. Everything seemed to be working fine until I hit a function that fetches all the parent sections of a section. For some reason, when this function was called, the PHP interpreter was going crazy. Even still, I could find no problems with the code itself. Then it hit me, the database!

I checked the database, and sure enough, I found a section whose parent section was set to itself! I was manually changing values in the DB to test my mass editing code in different situations and I must have set the parent section of that section incorrectly (obviously). I’m not sure how it happened, but once I made the change, everything is once again working nicely (and seems a good bit quicker too, compared to when it wouldn’t load at all ).

Once I got that bug out of the way, I moved onto optimizing the mass editing code. Like I said, the code was pretty messy as I was just focused on getting it working, so I ended up with a fair amount of repetitious code. This is abnormal for me, as I usually take the time to work out how best to structure things so that I don’t have any repetition. I guess I just wanted to get these features out of the way, so I didn’t plan for very long this time. In the future, I think I’ll need to remind myself to take the extra time it takes to get it right the first time, because going through messy code to find ways to optimize it was not fun. Ah, another day, another lesson

Thankfully, the optimized code is much cleaner and works quite well. Tomorrow, I think I’ll a little bit more time optimizing things a bit more and then move onto adding some new features (though I don’t quite yet know which features I’ll work on).

I spent yesterday creating the interface to perform mass operations (i.e. operations on multiple items at once), and today I started adding some functionality. I’ve just started, and the code is pretty messy ATM, but here’s what I’ve got so far:

• Move Items - Select the items you want to move, choose the section you want to move them to, and specify which item they’ll be inserted after (only applies to sections as posts do not have a menu order), and submit the form. Simple and quick.
• Delete Items - Select the items you want to delete and check the option to “Delete Selected” and submit. All selected items will be deleted. Currently, all child items of any deleted items are moved to the next available parent section (meaning it checks to make sure the parent section isn’t also being deleted), but I’m thinking about adding an option to delete all the children items (sections and posts) of a section that has been deleted. It wouldn’t be too hard as I’ve already built a helper function that gets all the child items (regardless of depth) for a given section, so maybe I’ll add the option just for kicks.

Here’s a shot of the interface (temp (?) icons by famfamfam):

It’s not a long list, but it’s a pretty significant list to me because these were two main administrative features that I felt were necessary for me to consider this plugin useful. I still have to work on optimizing the code, but I’m glad to have gotten this functionality into the plugin.

I’ll be honest though– these features were only added to provide a baseline level of functionality on a temporary basis. While it technically is usable, I don’t know if I would rank it high in usability. I would really love to move items around simply by dragging/dropping them. Also, I’m not really fond of having to go the post edit form every time I want to modify a minor detail of a post/section (i.e. title, parent section, status, etc.), so providing functionality for mass editing of those details is on the to-do list as well. I’ve got a couple more things I’d like to add as well, but I best not get too far ahead of myself

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

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:

• Mass Edit - Delete Section(s)
• Mass Edit - Change Parent Section
• Mass Edit - Delete Posts
• Mass Edit - Change Posts’ Parent Section

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.

Categories are nice, but truthfully, given the choice, I’d probably use tags wherever appropriate. Whereas categories are innately related to each other based on their hierarchy, tags initially do not have any relationship with each other. It’s by their pairings that relationships and meaning are formed. Which tags are associated with another is totally up to the user, and these associations can change from one instance to another. Sure, “tags” are just “keywords”, but it’s really their application as terms that can be used to get results that are as general or precise as you desire that really gets me interested. I’ve always loved the power of “intersections” in databases, and that’s exactly the functionality tags provides.

Yesterday, I added support for categories in sections. I did that first because categories are a core component of any default Wordpress install. More importantly, categories are “easier” to work with if you’re not familiar with how tags work. As one of my primary uses for this CMS plugin is to build websites for others (who may not be very tech-savvy), support for categories was very important. Once I got that out of the way, I was free to add support for tags in sections, which is what I think I’ll be using more often. More specifically, I added support for the Ultimate Tag Warrior plugin (UTW) into sections as this is the plugin that I use for tagging content. It’s a good plugin, and satisfies my needs quite nicely. Interestingly, though there does appear to be code to detect whether an RSS feed of the tag results is being requested, it doesn’t appear to be fully implemented. I commented on the author’s site asking about this, but in the meantime, I added RSS feeds to the tag results within sections. That means a visitor can subscribe to a feed in a section (”books” for instance), along with some tags (let’s say “sci-fi” and “water”), and they will be notified via RSS whenever a new item containing those tags is added to that section. Well, at any rate, I think that’s pretty nice.

Thankfully, getting tags to work in sections didn’t take too much work. All I it took was adding a new rewrite rule to the wp_rewrite->rules array to redirect any request to domain.com/section-name/tag/tag-names to a something like domain.com/index.php?section=section-name&tags=tag-names. I found that I could not pass the tag-names using the query variable tag as UTW was already using that, so I just added the tags query variable (using the query_vars filter) to the wp_query->query_vars array so that I could use the tag-names to filter which posts were displayed in the section.

Did I mention that I also added RSS feed support to categories in sections? This provides pretty much the same functionality as the feeds for tags in sections, but for those who use categories instead.

In fact, you can even get the same functionality as tags since I added support for category intersections today. This means that by visiting http://domain.com/section-name/category/sci-fi+water, you’ll only get posts that are assigned to both “sci-fi” and “water” categories. RSS feeds work here as well (can you tell I like RSS?)

I held off from working on adding support for custom RSS templates today, but I do have a few leads on how to do it. For one, I could simply make the rewrite rule for the feeds within sections point to a file in the theme’s directory, thus giving the theme-maker the ability to customize RSS feeds. This would leave the default RSS feeds untouched, but allow custom features (such as plugins) to use customized feed templates. Another possible option is to use the template_redirect action to redirect certain requests (e.g. requests for feeds) to files in the theme directory. I’m still trying to decide whether it would be better to have customizable RSS templates live in Wordpress’ admin menus or in the theme directory. Having available in the admin menus would mean that only those with the proper access level could modify them and the RSS feeds could stay the same regardless of which theme you want to use. Now that I think of it, I guess it would be better to have RSS feed templates managed from the admin interface, but it just might take a little more work than simply redirecting the request to a file in the theme’s directory.

I finished off the day by adding support for listing only categories and tags that are used by the items in that section. I’ve still got a bit more work to do in this area, and once I’m done with that, I’ve got to figure out the best way to allow users to add categories/tags to further refine results (ala del.icio.us).

However, the next big step I have to tackle is refining the administration interface so that it’s simple to manage and modify all of the content. Really looking forward to that….yeah…:)

Well, that wasn’t so hard after all

Displaying items in a section filtered by a category is now working!

I was thinking it was going to be harder because I was initially thinking I was going to go with Worpress’ default category functions to display categorized items, which I would then have to figure out how to filter the results by the current section. I decided to first try the other route, and used my current implementation of fetching items belonging to a specific section and added in some category filtering code if a category was passed via the URL. This worked out quite well and thankfully didn’t take very time to implement at all.

So if you navigate to: http://domain.com/section-name/category/category-name, it will display only those categories in “section-name“, which are also assigned to the “category-name” category.

It works with categories and sub-categories equally well. As each category is actually its own row in the DB, all that’s necessary when looking-up sub-categories is to get the last category listed in the query string (e.g. domain.com/section-name/category/cat/subcat/ will get items assigned to subcat). In fact, it doesn’t matter what any of the text before the final category in the query string, because currently the script only looks at the last word. Also, the script checks to make sure that the extracted category text is actually a category. If it isn’t a valid category, the query will return all items in the section. Later, I may add some iteration to display items from the parent category if the sub-category is not a valid category.

The nice thing about breaking up the categories passed via the query string is that it also opens up the possibility for fancy intersections of categories/tags, etc. This is nice because it’s the intersections that I like most about tagging systems (such as finding all posts matching “Wordpress” and “CMS“)

Also, on the topic of customized RSS templates, I realized that I could generate customized RSS feeds within the plugin itself, thus avoiding having to deal with Wordpress’ default RSS templates. The RSS format is simple enough, and is quite strict, so I wouldn’t have to worry too much about writing a feed generator for any situation. By doing this, the default RSS feeds generated by Wordpress would work as usual, and I could happily create any custom feeds I wanted as well. I guess this will be my next task.

With these latest features added to the plugin, I’m finally starting to feel like I’m nearing a level of functionality where I would consider this plugin “usable“. I still have a bit more to do to standardize everything (function names, etc.), and make it simple to implement in themes (i.e. template tags). Hopefully, just a few more refinements and I’ll be able to release the first version of this plugin. Then I can get on to add some real functionality!

Actually, that was yesterday. After I got RSS feeds working again (again, a result of my custom rewrite rules), I set out to get feeds for sections working. Simply put, I wanted there to be a feed for every section (e.g. http://domain.com/section-name/feed) which displayed the latest items (articles, blog posts, etc.) in that section. As my implementation of sections doesn’t exactly jive with the way the feeds work in Wordpress (more on this in a later post), I was sure getting this feature working was going to require some twisty code. I sat staring out the window for what seemed like an eternity (probably 10 minutes), working out all the possible solutions to this as I could imagine. For the most part, I was coming up blank. So, I decided it might be a good idea to first find out how Wordpress creates its RSS feeds (did I forget to mention that I hadn’t actually done that yet?). I was relieved to find that RSS feed generation in Wordpress is amazingly simple. You’ve got a template file for each feed type (RSS, RSS 2, Atom, etc.) in the root directory of the Wordpress install. These template files are very similar to the template files in themes (they’ve even got their own template tags). From there, it was just a simple matter of having the template check if the requested page was for a section, fetching the items for that section, and inserting the data in the proper XML tags. After that, I added a custom rewrite rule (no conflicts this time, I swear) and I had working RSS feeds for sections, in about 5 minutes!

The only downer is that currently, Wordpress keeps the RSS templates in the root directory. This of course means that themes cannot include templates for customizing the RSS feeds. It also unfortunately means that a plugin cannot directly generate the RSS feeds (you can only append data to certain sections of the RSS feeds using hooks), so providing an integrated drop-in CMS solution with working feeds for Wordpress can’t be a 1-step process (it is now a 2-step process– bummer, I know). I have a few ideas that I need to explore, so there may still yet be hope.

Today, I am working on displaying items for all sub-sections in the parent section(s) as well. Previously, sections would only display items in that section, but not items belonging to the current section’s sub-sections. I found that somewhat limiting (as that would require users to navigate several levels down just to see if a sub-section had any new items), so I changed to display all items belonging to the current section and its sub-sections. I may provide an option to turn this functionality on/off later on (though at this point, I can’t see why turning it off would be desirable edit: I thought of at least a few situations where you would want to control this, so I’m adding the option).

Actually, I should have said I was working on it, because I just finished it.

Now: Lunch

Later: Filtering display of items to the selected section and category. I have a feeling this one will be interesting.

I just finished adding the ability select where a new section will be inserted by choosing the section you want the new section to appear after.
This was the first time in a while that I played with pushing PHP-generated data to javascript, so it was a good exercise.

Here’s a shot of it:

I find it much better than the simple “Page Order” box you get when creating pages. I always found typing in a number and hoping for the best to be somewhat ambiguous and imprecise (especially since the display order of pages is determined both by the page order value (which can be the same across several pages and the post date of the page). I’ll probably convert this little drop-down menu to be used for page creation once I finish things up with this plugin.

I’m still mulling over what the best way to store pages in the DB would be (actually, I barely thought about it today). I did, however, determine that I need to (once again) refine the rewrite rules. Currently, a user-defined extension is required for posts (.html, .php, etc.) in order to differentiate them from sections (since their are no section prefixes by default). Once I finish this wave of refinements to the rewrite rules, I think I may be able to do away with the extension entirely. This would be very nice indeed, as I thought I was going to have to create a new query variable and query interpreter to accomplish the same thing.

I’ve fixed the URL rewriting issue I was having. The problem was that the regular expressions used to determine the post data (either the post’s name or id based on the permalink structure) were not properly handling different base URLs. This was evidenced when I installed the plugin on a Wordpress install for a real website (as opposed to my local dev server). The regular expressions were no longer finding the post data, but instead returning data from another part of the URL string.

I’ve just finished rewriting the regular expressions, as well as cleaned up the URL rewriting code as a whole, so it’s working much better now.

The next issue: Section storage.

A couple days ago, I began to wonder whether I was storing the Section data in the best possible way. So I’ve been working out different solutions to see which one would be the most robust and future-proof. So far, there are major advantages and disadvantages for each solution. I’d like to implement the most flexible solution (to provide functionality for any possible situation), but I think I need to focus more on how sections will be used 99% of the time.

I’ve moved from developing the CMS plugin on my local computer, to deploying it on a server on the internet. I’ve already run into some issues, but at least it’s not totally broken Honestly, all in all, things seem to be looking pretty good.

The main issue right now? As usual, it’s those pesky rewrite rules and the modified permalink structure! Grrrr, I’ll get them yet!