Archetyped

I didn’t feel much like tackling the code refinement today, so instead I did a little bit of work on the administration menus as well as added some options to customize the plugin’s behavior.
Here’s a quick shot of it in action:

It’s pretty simple right now, as I just wanted to get a working version first, then I’ll play around with it.

Some interesting things I found out today:

For some reason, I couldn’t get the activate_ action hook, nor the register_activation_hook() function that wraps it to work. My goal was to add the required options to the DB when the plugin was activated (if they didn’t already exist), and delete them when the plugin was deactivated (so as to avoid cruft in the DB from uninstalled plugins). I couldn’t get it to work using either of these methods, and a quick googling didn’t turn up anything useful, so I’ll just have to look into it more at a later time. For the present, I’m adding the options to the DB (if they don’t already exist) by declaring them at the top of the plugin file. Aesthetically, I don’t really care for this because it means that the conditional statements to check for the existence of the options in the DB will run every time the plugin loads (which is every time any page reloads in WP). Seems a little inefficient if you ask me, but it appears to be the way several other plugins are written (based on a quick peek at the source of a few other plugins I’ve got installed).

Tomorrow I’ll be refining the options menus and moving on to the testing.

I had a feeling that the biggest challenge of this little experiment would be finagling proper CMS permalinks out of Wordpress. Simply put, I was not let down. Today was my first major foray into the world of WP_Rewrite (the class in Wordpress that handles all the URL rewriting), and I feel fortunate to have made it back out to tell the world about it. It is a world full of twists and turns, dead ends, and cliffs of confusion. Haha, nah, actually it was pretty enlightening to look over the class and see where all the URL “magic” happens. I still wouldn’t assume myself to be an expert on the subject, but at least now the depths of Wordpress’ inner-workings seem a little less dark and mysterious.

The truth is, I spent most of the day researching just how to manipulate the rewrite rules. Unfortunately, the official documentation was of little help in this matter. Sure, they’ve got a whole bunch of filters and hooks to get at the rewrite rules, but with little to no documentation on the vast majority of them, I can’t say I found much help there. As an aside, though sparse in some areas, the Wordpress’ documentation is quite useful. Also, I do realize that the documentation is a community-driven effort, and that I have no place to complain unless I’m willing to do something about it myself (which I am). Anyway, I found some discussion on the subject of rewrite rules in a few places, but a step-by-step rundown of the required steps was not be found. As such, I spent most of the day feeling like I was going in circles, all the while missing the “key” to tying it all together.

Ultimately, it turns out I was looking in the wrong place (sorta) for a solution. WP_Rewrite mainly kept track of the rewrite rules and how Wordpress handles fancy URL’s, but it seems to have little part in actually generating the permalinks. For that, we lneed ook to the function, get_permalink() (and its buddies in wp-includes/template-functions-links.php). This function takes the permalink structure defined by WP_Rewrite and generates the link for a post. In order to get the output of this function before it gets to the browser, you’ve got to use the post_link filter, which passes the URL to whatever function you call with the filter. I’ll admit, I spent a certain amount of time playing with the rewrite_rules_array filter, and wondering why nothing was happening to my links. After some more research, I came upon the aforementioned post_link filter, which finally enabled me to access the generated URL and manipulate it like so:
add_filter('post_link','url_magic_time') where url_magic_time is the name of the function that will process the URL before it gets to the browser. With a little bit of hair-pulling (mostly from the big hole in the documentation in this area), I got it working and Wordpress is now (mostly) giving me Beautiful Permalinks (not just “Pretty Permalinks”!)

However, even though I was getting Wordpress to generate the URLs of my dreams, the utility of WP_Rewrite remained a mystery to me. Why was everything I read talking about having to make new rewrite rules? Yesterday, I had tested my rewrite rules in my .htaccess file, and everything seemed to be working swimmingly (I tested the rules by manually typing in different URL’s, all of which worked just fine). I was under the impression that I wouldn’t even need to mess with WP_Rewrite to accomplish my goals. In the end, I was (half) right. It seems that when permalinks are turned off, the rewrite rules in .htaccess are enough to redirect a request to the proper destination (e.g. /section_name/post_name/ redirects to /index.php?name=post_name). However, when I turned permalinks on I was getting 404’s all over the place on URL’s that had worked seconds ago. I found it surprising that Wordpress had any control over the redirecting of requests, but upon adding a new rewrite rule to WP_Rewrite to recognize my customized permalink structure (with add_filter('rewrite_rules_array','my_fancy_rewrite_rules')), the permalinks were once again in working order! Surely, more testing in this area is required on my part.

I’m glad I got that beast out of the way today. Now comes the fun part: endless tweaking, incremental refinement, and (dread) testing! I’m expecting this is where progress slows somewhat. But at least a got I good amount done during these past 3 days!

Made some good progress today. After going over several potential implementations of Sections on paper, I finally ended up with a solution that I think is the simplest. Also nice is that this solution does not require adding any tables to the Wordpress database. While I wouldn’t have a problem with that if the plugin necessitated it, it’s also nice to KISS every once and awhile

So far, testing out this implementation seems to be working pretty well. I’ve added a drop-down menu to the Add Post page to allow the post to be assigned to a Section. Once the post has been published, it is then viewable via /section_name/post_name

I’ve also decided to implement tagging (using Christine Davis’ Ultimate Tag Warrior 3) in lieu of categories simply because I find it faster to add tags to posts rather than categories. I also like the lack of hierarchy and the potential for tag intersections to drill down results.

Also, I’ve pretty much got my mod_rewrite rules setup for Apache.

So, all in all, a pretty productive Sunday afternoon!

I still have the task of getting Wordpress to spit out my desired URL’s without too much hackery (would very much like to have Wordpress’ own the_permalink() template tag to produce the goods to improve compatibility with other themes).

Also on my to do list:

• Refine display of Posts in their Section (Make it more template-oriented)
• Displaying Posts in a Section filtered by a tag (or tags) - ala /section_name/tag/photography+japan/

I’m currently building it as a plugin/theme just to speed development, but I’m hoping to get it all packaged into a nice plugin once I’ve got it all worked out.

I’ve spent a good part of the day researching and testing different potential solutions to getting Wordpress to act like a proper CMS. There are couple major roadblocks that will require some creativity (especially since my goal remains to leave the core Wordpress code untouched). Honestly, I’m not sure if it will be possible (or productive) with the current version of Wordpress. Nonetheless, I am optimistic that a solution will be found.

Currently, one of the main issues I need to find a solution for would be:

Customizing the Permalink Structure

I’ve done a fair amount of research and testing today regarding using Apache’s mod_rewrite. As always, regular expressions rule the day! I’ve determined the permalink structure I want and have written the rewrite rules for them, so it’s ready to go on Apache’s end.
This is the basic structure:

• Section - /section_name/
• Tags - /tag/tag_name/
• Tags in Section - /section_name/category_name/
• Item - /section_name/item_name (Items will belong to one section only, while tagging will provide more general relational groupings)
• Paged Item - /section_name/item_name/page_number or /section_name/item_name/page/page_number
  (the choice is really only a matter of style and usability; they’ll both work equally well)

The trailing slashes play a large part in making this work. A URI ending with a slash indicates that there is more to be seen (thus a section or tag depending on position in the URI), while a URI with no trailing slash indicates that a specific content item is to be requested. I’ll of course need to look into providing some error correction, but the goal here is to get Wordpress’ structure to mimic that of a manually-created directory structure. A structure like this would not be difficult at all in the world of static pages.
Now all I have to do is convince Wordpress to play nice and let me modify its URL rewriting code without too much a fuss.

I have always loved Wordpress as a blog platform, but even with its “Pages” functionality, I never really saw it as a viable option for a CMS (Content Management System). When I was mulling over how to structure Archetyped.com, and do it in the least amount of time as possible, I decided to take a closer look at Wordpress for use as a CMS.

In the past couple of days since installing Wordpress, my opinion of Wordpress as a CMS has gone back and forth. In one moment, I may feel that Wordpress can in fact be used as a CMS (and a darn good one at that). Then, in the next, I find a deal-breaker that totally makes me question whether Wordpress has it in it.

For me, compromise is not an option. If Wordpress just can’t cut it as a CMS, then I’ll search for another. There are a lot of CMS’s out there, and I’m sure I could find the “perfect” one if I looked hard enough. But, what if Wordpress is that perfect CMS (and it just doesn’t know it yet)?

Here are some of the things it’s got going for it:

• Ease of use
  Wordpress is really easy to get going and adding content on. This cannot be said of many full-fledged CMS’s out there
• Blogging Power
  As this Wordpress’ main function, it is obviously one of it’s strongest. Wordpress features far better built-in blogging functionality compared to many other CMS’s (many of which do not even come with any built-in blogging functionality).
• Extensibility
  By leveraging the power of plugins and themes, it is very simple to enhance and customize Wordpress’ functionality to meet (almost) any need, while at the same time not having to touch the core code. This means the same modifications can easily be made to any install of Wordpress very simply.
• Pretty URL’s (mod_rewrite)
  Down with index.php?c=654&d=87df&treehugger=hippie&yuppie=needsahug! That’s all I have to say about that.
• RSS
  I use RSS every day, so I couldn’t imagine using a system that can’t give me RSS functionality. Oddly enough, several CMS’s do not include this functionality (while others make it difficult to implement).

That’s some tasty stuff. However, Wordpress also has some not-so-CMS-loving features:

• No Sections
  Organizing dynamic content by sections is a major need for anyone wanting to setup a content-based site (me). Unfortunately, Wordpress does not provide this functionality, while pretty much any self-respecting (and even those self-deprecating) CMS’s do.
• Funky Permalink Structure
  This is actually one of the most important features to me as structure is huge when it comes to usability and accessibility. In order for Wordpress to work properly as a CMS, I would need the structure to reflect “domain.com/section/item/” (such as: archetyped.com/software/structure) or in other cases, “domain.com/section/category/” (such as: archetyped.com/resources/articles). Of course, a structure like this presents some issues for Apache’s rewrite rules (as it would be hard to tell whether the request is for a category or a specific content item), so while it would be incredibly easy to get this structure with a manually created site, it may be a bit more difficult with a dynamically created one. Currently, I have my permalinks to posts to display as “domain.com/category-name/post-title”, which is great and works just fine for me. However, to display a listing of items in a specific category, the url looks something like “domain.com/category/category_name/”. This totally messes up the site’s structure for the user as there is no logical connection between “domain.com/category-name/post-title” and “domain.com/category/category-name/”. If the user wanted to go up one level (i.e. get a list of all posts in the category of the current post, he might think to type in “domain.com/category-name”, which would result in a 404 error. In order for Wordpress to work as a CMS for me, this would need to be resolved (I’m working on it)
  [Note: I’m aware of the hacks to get “domain.com/category-name” to work properly, but it creates several more issues that workarounds would need to be found for. Also, my goal is to see what is possible without touching the core Wordpress code]

I know it’s not a long list of issues, but IMHO, they are deal-killers. If they cannot be resolved, then Wordpress simply will not be a viable option as a CMS for me.

This is mostly an experiment to see what kind of potential Wordpress has to extend beyond its blogging roots. I’ll give it a week