I spent some time yesterday working out the specifics of storing connections between content types and connections between different items (posts) and I’m pretty happy with the result.

An example of how connections can be useful:

Say you have 2 content types:

1. Recipes
2. Ingredients

Of course, all recipes must contain ingredients, so we need to tell the CMS that these two content types are connected. We can also define the type of connection between these items (“One to One” or “One to Many”).

• One to One: One item of one content type can connect to one item of another content type
• One to Many: One item of one content type can connect to several items of another content type

Will a recipe need to connect to just one ingredient, or will it need to connect to several? In this case, we would want to be able to connect a recipe to several ingredients, so we’re going to create a One to Many relationship between Recipes and Ingredients.

Now, when I’m adding a new recipe, thanks to the connection between these two content types, a list of ingredients will be displayed in the form to select ingredients that the recipe uses. Since this is a One to Many relationship, each ingredient has a checkbox next to it so that I can select multiple ingredients from the list. If it were a One to One relationship, the ingredients would be displayed as a drop-down list, which would only allow for one ingredient to be selected.

I really like the possibilities of this feature, but I think the goal now is to make it usable. In my opinion, it’s quite powerful as a feature, but it’s also somewhat abstract. So I’ve got to find a way to make it instantly clear how this feature could be useful to a user.

WordPress as CMS – Making the Connection was originally published on Archetyped on February 3, 2007 11:03am

The idea is simple: Select a content type, and the additional form fields for that content type appear below the main form.

Today, I built a working example of just that. Most of the work now will go into making this functionality more robust and flexible.

WordPress as CMS – Dynamic Forms was originally published on Archetyped on January 23, 2007 11:51pm

At the moment, I’m working on determining the best way to define a Content Type and its options in the database. Some types of content will use data from wp_posts along with data from other tables (joins), while others will be totally separate, so it’s important that the definition format is robust enough to handle all sorts of types. From there, the next step is to implement that format so that I can easily (and efficiently) pull all data (including custom metadata from other tables) for a post (or group of posts).

WordPress as CMS – Content Types was originally published on Archetyped on January 19, 2007 02:35pm

When I started working on it today, I felt that it still wasn’t quite as “dynamic” as I would like. I felt that I was doing too much configuration, and more of the inner workings should be automatic for me to really call this app “intelligent”.

The goal is to make a system where relationships are automatically determined and content is displayed based on these relationships. I’m at the point in development where I’m starting to work on the layout and structuring of the content. Things feel quite a bit less flexible.  I have no single-use functions (such as a function to display lists and another to display items in the current list), but rather all content display is handled by intelligent functions and variable values.

So now, I’m about to rewrite a large part of the code to make things even more automatic. I’d like to get started on this as soon as possible, but I’m still working out some of the details:

• Just how object-oriented should it be?
• Should configuration (parent/child relationships, etc.) be set in the objects or based on the DB structure (or both)?
• What’s the most optimized way to fetch all the content while still retaining as much flexibility as possible?

Trust me, there’s more. I’m stopping for the evening in the hopes that some time away from the questions will help me to better find the answers.

Lists – So Close, Yet So Far was originally published on Archetyped on November 30, 2006 07:14pm

The Problem

Whenever I talk to others, I’m always hearing about new things– restaurants I should try, movies I should see, books to read, etc. If something something sounds interesting to me, I’d like to take note of it so that I can try it. Now, since I first started using a PDA (starting with the stately, Palm Vx, say, 7 years ago or so), I don’t really ever carry paper or (more importantly) a pen around with me anymore. This was not really ever a problem with a PDA, as I could simply add a note to my PDA, which could later be synced to my PC, saving the item for future reference. I’ve since given up the bulk of having to carry around a PDA and a cellphone in lieu of a smartphone (the svelte Audiovox SMT 5600/HTC Typhoon). While my smartphone satisfies 99% of my on-the-go needs, there is no built-in tool to easily manage my ever-growing list of interesting things to do/see/eat/etc. (though 3rd-party solutions may be available). On occasion, I have carried around a pen and a bit of paper to write down anything that I may want to remember, but I wouldn’t consider this the ideal solution because it 1) adds the extra step of having to re-input anything I write down into my computer to add to my main list, and 2) having to carry more stuff in my pocket kind of invalidates my reasoning for giving up the utility of a full-fledged PDA for the pocketability of a smartphone.

The Solution

Manage lists of items anytime, anywhere using any web-enabled device.

The Implementation

Using a simple web-based interface, Lists enables me to do the following:

• Create lists to manage different groups of items
• Add items to a list
• Mark when an item has been done

As this tool is meant to help me when I’m on the go, it needs to be easily accessible via my mobile phone. In addition to the above-mentioned functionality, the following are also a priority for a good mobile experience:

• Speedy code
• Optimized layout of content (i.e. nothing superfluous should take up space on the small screen of a mobile phone)
• Full functionality without requiring fancy client-side stuff (i.e. no ajax, etc.)

Admittedly, this is a very simple tool to create. So to make this more of an exercise, I’m working on making the whole system as dynamic as possible. The goal is to make it as intelligent as possible with as little manual code as possible. All database queries, relationships (i.e. between lists and items), displaying of content, etc. should be automatically determined based on a minimum of configuration information (database info, etc.).

After a few days of planning and writing the code, I’ve currently got the basic functionality working (add/edit/delete lists, add items to lists, edit/delete items, etc.). The next step is to further optimize the code so that it is even more intelligent.

How would this be used?

When I hear about a movie that sounds interesting, all I need to do is select my “Movies” list and add the movie to it (via my mobile phone or any other web-enabled device). Then, the next time I’m in the video store looking for a movie to watch, all I need to do is check the list with my mobile phone and I can see a selection of movies that I know that I’d like to see.

The same goes for finding a place to eat when we’re driving around trying to decide where we should go to eat. With a quick look at my “Restaurants” list, we’ve now got a list of potential places to check out.

Even simpler, Lists can be used to create a list of groceries to buy while I’m at home, and then use my phone to reference the list while I walk around the grocery store. Saves time and paper. Sounds good to me!

Other Thoughts

This is a simple project made mostly for me personally. But I do plan on adding multi-user functionality so that others can use it too. I also will most likely provide the source code for download on this site once I get to a point where I’d consider it fit for public consumption.

Mini Project: Lists was originally published on Archetyped on November 29, 2006 06:38pm

• Media files generally need to be uploaded to the server
• They can be embedded in other content (posts)
• They require specific markup to be displayed

It is because of these special characteristics that content types classified as media are not treated the same as other content types. For the most part, media will be added when adding another content type (an mp3 for a podcast, a thumbnail image for an article, etc.). Nonetheless, they are still treated as a separate content item (which means that they may be selected and embedded in any other content item as well).

Some differences regarding how media items are handled:

• Upload Capability – Media files may be uploaded
• File Organization – Media files are saved into directories based on file type
• Embed Media in a Post – Media can be easily added to a post by clicking an “Insert Media” button, viewing a gallery of media items (sortable and filterable), and selecting the media item(s) to insert.
• Automatic Media Viewers – When a media item is displayed, it is automatically wrapped in a the proper markup to allowing viewing. For example:
  • Images (gif, jpg, png) are wrapped in <img> tags
  • Flash Videos (flv) are wrapped in a flash video player
  • Mp3 files are wrapped in a flash-based audio player

  The nice thing is that these viewers are simply the default templates defined for each of the content types. This means that:

  1. Viewers can be easily modified
  2. Default viewers can be easily overridden via a template for further customization

Adding new media types is as simple as adding any other content types (define the characteristics of the media type, create default viewer template, and you’re done).

Personally, I like the automatic viewers for displaying media the most. This relieves template creators from having to do this task, and all they have to do is add a simple template tag (show_media(), for example).

WordPress as CMS – New Features Part 2: Media Management was originally published on Archetyped on November 26, 2006 04:37pm

There are several little enhancements and optimizations all over, but there are two new features that I believe have the most impact:

Content Types

Different types of content have different attributes. While most content types share some attributes (i.e. title, main content text, categories, etc.), they often diverge from each other in their “supporting” attributes (aka metadata). In the case of Cinema Paradise, a film would have a certain set of metadata (director, length, country, etc.), while an event would have completely different set of metadata (time/date, location, etc.).

For a site needing to manage several different content types, there are two important questions:

• How is the metadata added to a post (and how is it stored)?
• How is the metadata displayed?

Adding metadata to a post

Generally, additional metadata is added to a post via custom fields and stored in the wp_postmeta table. When you write a new post, simply fill in the appropriate custom fields (or add new ones), and you’re good to go. This is fine for blog sites (where blog posts are the only content type), but for a content-heavy site where several different types of content are added regularly (articles, blog posts, etc.), this just isn’t acceptable. Not only would a large list of custom fields be disorganized and hard to manage, but on a site with multiple users (each of whom may only need to work with certain content types), there is a good chance that mistakes will be made (e.g. typing metadata into the wrong custom field, etc.).

To make the creation and management of different content types simple and effective, the following functionality was (or will be) introduced into the plugin:

• Add new content types

Users are able to create new content types and define its attributes. For each attribute, users may define the different characteristics such as data type, default values, etc. Some examples of data type are:

• Date
• Address
• Phone Number
• Database Lookup – (Creates a drop-down list of values fetched from the DB. Used mostly to create relationships with other content types)
• File Upload – (image/video uploads, etc.)

The order and layout of the content type’s attributes can also be set.
As an example, three content types from the Cinema Paradise site were “Director”, “Film”, and “Event”. Here is a breakdown of each content type:

Director

• Name – Plain Text
• Country – DB Lookup (List of Countries)

Film

• Title – Post Title
• Description – Post Content
• Country – DB Lookup (List of Countries)
• Director – DB Lookup (Items matching “Director” content type)
• Genre(s) – Post Categories

Event

• Event Title – Post Title
• Event Description – Post Content
• Start Time – Date
• End Time – Date
• Location – DB Lookup (Items matching “Location” content type)
• Select content type for a post

Once a content type has been created, it may be selected from a drop-down list in the Write Post form when creating or editing a post. When a content type is selected, a form containing a field for each of the content type’s attributes will appear below the post content text box. The user can then fill in this form with the appropriate metadata.

Each field in the form is not just a simple text box either. A specially formatted form field will be displayed depending on the data type for each attribute. For instance, a date field will have a field where a date (month/day/year) may be entered, along with a popup calendar for quick and easy date selection, and an address data type will have text fields for Street, City, State, Zipcode, and Country data to be entered.

This makes it simple to enter metadata for different content types, and because only the form fields necessary for that content type are displayed, the likelihood of user-error is greatly minimized.

A note on metadata storage

For the first implementation of this feature on Cinema Paradise’s site, a new table is created for each content type. Since there were a finite amount of different content types to manage, I felt this was the best solution (faster/more specific queries, etc.). However, I am currently reevaluating the implementation of how metadata is stored to best accommodate the creation of an unlimited number of different content types.

Displaying metadata for a post

Template Hierarchy

Once a post has been assigned a content type, the focus now moves onto how to display this extra data. First, when creating a new content type, a default template may be defined. This template will be used if no templates have been set for a content type in the template directory. If a template for a content type has been defined in the template directory, it will override the default template. Currently, content type templates are defined by creating a file with the same name as the content type (this may change in the future to better differentiate content type template files from other template files). Furthermore, content type templates may be defined on a per-section basis. This means that content of a specific type (e.g. an article or an event) can be made to look different from one section to another. Again, if a section-specific content type template is present, it will override both the global content type template file and the default content type template (only for posts in that section, of course).

Custom Template Tags (Conceptual)

Currently, metadata may be displayed simply by inserting $post->attribute-name into a template. This works and is quite simple, but I would like to align the display of a post’s metadata with the main data of a post which can be displayed using template tags such as the_title(), the_content(), etc. So for an event, a user could create template tags such as event_location(), event_start(), and event_end().

Honestly, I don’t know whether this is practical to implement, or if it is even possible. I need to look into this more.

WordPress as CMS – New Features Part 1: Content Types was originally published on Archetyped on November 26, 2006 02:52pm

So what did the CMS plugin do for the site?

• Logical/Hackable Permalinks – http://cinemaparadise.org/films lists all the films, while http://cinemaparadise.org/films/lady-vengence displays the details of one of the films in the festival (Lady Vengeance)
• Simple Section Creation – As easy as creating a page or a post in WordPress (Actually, there are two ways to do it, and one way is even simpler than adding a page or post)
• Easily add content to sections – When writing a post, simply select the section the post should belong to via a drop-down menu (in the post form sidebar).

Other features, such as Section-specific RSS feeds, tags, and categories are available, but the client chose not to use them. But they are still there. For example:
http://cinemaparadise.org/films/feed

Next Step: Roll the additions (i.e. new features) and optimizations gained from working on this site back into the plugin itself.

WordPress as CMS – First Implementation was originally published on Archetyped on November 26, 2006 01:09pm

Ultimately, I would like to integrate drag/drop functionality to for moving files from one section to another. However, to keep things simple initially, it’s simply going to be form-based

1. select the posts
2. select the section to move the posts to
3. click submit

I’ll post an screenshot of the interface once I get it working.

WordPress as CMS – File Management was originally published on Archetyped on September 15, 2006 05:50pm

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:

Content Management UI

For comparison, the interface as it is now:

Current UI

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.

WordPress as CMS – Interface Design was originally published on Archetyped on September 2, 2006 01:17pm