Archiv der Kategorie ‘Wordpress‘

 
 

Editorial Plan

This website covers a range of areas all concerned with business and the way that their web presence fits into marketing, communications and overall branding. As a one-time journalist the best way I can see of doing this is to create an editorial plan and then research and write.
This page is a movable framework.
Initial thoughts are:
  • What is WordPress?
  • WordPress history.
  • Why business is right to be concerned about WordPress
  • What will WordPress do? 
    • for you
    • for your customers
    • for your search engine ranking
  • Why WordPress?
  • WordPress Plugins. What’s that all about?
  • How to make the best of a WordPress website.
  • SEO and WordPress
     

WordPress, a Google parallel

WordPress came into our consciousness a few years ago. Blogging had arrived and it seemed to be something to do with that. However our parent company (we hadn’t been born back then), Creative Thing, do PR work from time to time. It occurred to us that if you ignore the word Blog, WordPress is a fully functioning online newsdesk. So we told our client ACID about it and they said they would have one.

And having climbed inside WordPress we realised that it could do lots more. It could run websites of all types and sizes, with content management systems coming free. It would be easier to create better websites. We win, our clients win and this felt like a revolution about to happen. A bit like when Google emerged.

Prior to Google there were a lot of search engines out there. They were part of a suite of things. All doing the same kind multitasking wrapped up in portals, features and functions which were designed to capture our imagination or, more significantly, our default home page and thereafter have a degree of control over our online viewing habits. Then one day Google showed up.

It was thing for searching the web and nothing more. It had a single line text box in the middle of an otherwise blank screen with the word Google above it. No style, no, add-ons, no translation devices, no email thing, no portal. And not much has changed with the core product since then. It was and is great because it does its job well and doesn’t confuse anyone over that. It instantly captured the home pages of users all over the world.

Where web sites are concerned, there are loads of content management systems out there. Loads of poor designers and developers and websites built on everything from Vignette to planks of wood. Then one day WordPress emerged. It started out as a blogging tool, but critically, it was open source, that is it had all its source code open for all to see and improve, develop, and share. 

WordPress must have had the largest development team in the world working on it for years. They freely share their work with other developers and designers, creating new interfaces, functions, security layers and add-ons. It has become much more than a blogging tool, it is an easy website generation tool. Someone with a basic understanding of the web can set up a site. Critically people with advanced understanding of the web can build on WordPress and make it jump through hoops, sing, dance and tell jokes.

WordPress is the best way to build a website. It is so good that a WordPress website would cost between five and twenty times more done in any other way.

WordPress as CMS – Dynamic Forms

While I’m still working out the exact method to define a content type, I’m far enough along that I was able to start working on the code to display the extra forms for each content type.

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 2.1 “Ella”!

It’s hard to keep working on the plugin when I find out that a new version of Wordpress has been released.

Lot’s of cool stuff from a user and developer standpoint. Read the announcement.

Sounds like there’s a lot of new goodies for plugin developers. I don’t know whether I should keep working on my plugin or spend the rest of the day playing with the new version!

WordPress as CMS: Content Types

I’m currently working on the Content Types feature of my CMS plugin for Wordpress. As previously discussed, I think this is an important feature for a CMS that is truly extensible and flexible enough to be used for any purpose.

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 – New Features Part 2: Media Management

Compared to other content types, media types (video, image, audio, etc.) are differentiated by certain characteristics:

  • 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 1: Content Types

One of the best things to come out of beta testing this plugin in a real-world situation is the advent of new features. Had I been developing the plugin in complete isolation, it’s quite likely these new features could have been implemented completely differently (or not at all).

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 – First Implementation

Development has continued steadily on the CMS plugin for Wordpress. I am currently beta testing it on some projects to help me better develop this plugin for real-world use. The first of these projects is a site for an international film festival called Cinema Paradise.

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 – File Management

Things have gotten a bit busy around here as of late, but I’m still working on building a more efficient interface for managing content. I have eschewed Wordpress’ default single-column interface for a more “explorer-like” two-pane file manager. The left pane will list the hierarchy of Sections. When a section is selected in the left pane, the posts in that section will be displayed in the right pane. I think this works much better than paginating the listing of posts independently for each section, as that can get quite messy real quick-like.

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.