Side Projects and Blog Posts

In a previous post I described my workflow for side projects in general. I wrote that throughout the project I publish blog posts describing my thoughts, plans, progress, etc.

In this post I describe in further detail the technicalities of side-project-related blog posts. I explain my guidelines and considerations for some of the common blog posts that accompany side projects. I also describe how I use WordPress features and plugins to generate project index pages and lists of active and archived projects. These features include custom fields, page hierarchies, and queries, with a couple of plugins and template modifications.

My main goal here is to cut friction and overhead when I work on my side projects, and keep project-related posts organized.

Requirements

My requirements from project-related blog posts are:

  1. When composing a project related post, require no more than 10 seconds of overhead to take care of organization. This is mandatory, so I can focus on the project and the post, and not on the meta.
  2. Readers must be able to see all posts related to a certain project easily, without cumbersome searches or tags-foo.
  3. Readers must be able to see that a post is related to a project easily.
  4. Readers must be able to get to the lists of projects directly from the main navigation menu.
  5. I should be able to set project status (active, archived, pending, etc.) easily.
  6. The implementation must work well with my automations and backup strategy.
  7. The solution should avoid cluttering tags and categories.

Implemented Solution

First, I created a “Projects” WordPress page. The idea is to have an “index” page per project, with the top-level Projects page as the parent of all project-index pages.

I used the Advanced Custom Fields plugin to create a Project status custom field:

  • The field group is shown (as side meta box) only for pages with “Projects” as the parent page:
  • The group contains one status field – a radio button with the available status values (active, archived, on hold, and pending):

This way, I can easily set (and change later) the status of a project from the project index page (requirement #5).

I edited the Projects page to dynamically list all projects:

I used the display posts shortcode plugin to dynamically generate lists of pages whose parent page is the current page. The grouping is done by filtering on the project_status custom field. Each list includes project thumbnail images (if present), and is sorted by page title. Here is the shortcode that accomplishes this:

[display-posts orderby="title" post_parent="current" meta_key="project_status" meta_value="<status-value>" post_type="page" image_size="thumbnail"]

I created four more top-level pages, one for each project status value. Each page contains a shortcode similar to the above snippet, to display only the projects with that status. I replaced the post_parent="current" filter with post_parent="<id-of-projects-page" to make it work correctly.

Now, for every new project, I create a project index page (not post). I set the parent page to be the Projects page, and the project status to one of the status values.

Here’s an example of an active project index page:

You can see the parent attribute set to “Projects”, and status custom field set to “Active”.

The content of the page can be whatever I want it to be (e.g. a project overview). The important part is another use of the display posts shortcode. This time it displays all posts with the project custom field set to the project index page, ordered from oldest to newest. Here’s the complete shortcode:

[display-posts meta_key="project" meta_value="current" meta_is_id="true" order="ASC"]

This use of the display-posts shortcode requires my current page custom field addon. Without my addon, there is no such attribute meta_is_id, and the “current” meta_value will not be converted correctly. I would have needed to specify the page ID instead.

I used the Advanced Custom Fields plugin to create a Project custom field:

The field name is the custom field name that I query on. Post Object field type determines that the field value is a relation to another post item. I set required to No because not all posts are project-related. I set Post Type to page to have a drop down populated only by existing pages. This custom field is only relevant for blog posts (and not other pages), so I added a rule to show the field group only if post type is post.

When composing a project-related post, I can choose a related project from a drop down of existing pages:

This is all that’s required to have the post listed in the project index page (requirement #1).

As for reader experience in accessing the information (requirement #4) – I simply added the projects pages to the main menu:

In addition, when rendering a project-related post, I added a project reference to the post meta space (requirement #3):

I accomplished this by editing the post-meta.php file of my template (under includes/post-formats). The piece of PHP & HTML code that follows adds a <span> element with the project title and link to project index page:

<?php
// don't do anything if ACF plugin not installed
if( function_exists('get_field') ) {
$project = get_field('project');
// if `project` custom field is set, `get_field` will return a WP_Post object with the project index page
if ( $project ) { ?>
<span><i class="icon-book"></i><a href="<?php echo get_permalink( $project ); ?>"><?php echo get_the_title( $project ); ?></a></span>
<?php }
} ?>

This code snippet should be inserted where appropriate. I inserted it after the tags list.

I don’t like the fact that I had to edit a theme template to accomplish that. This has at least two downsides I can think of. One downside is maintenance – updating the theme in the future might overwrite my modification, and require I do it over, assuming I remember. Another downside is the need to redo the modification if I change to another theme in the future.

The maintenance issue is addressed by using WordPress Child Themes. But it still means that the files I override will not be updated when the theme is updated – it would require me to manually merge the upstream changes with my own.

This is it. A bit of initial configuration, some set up per project, and minimal overhead for each project related post.

Summary

In this post I shared my requirements and solution for organizing side-project related blog posts on this site. To meet all of my requirements, I wrote and published a (http://wordpress.org/plugins/display-posts-shortcode-current-page-custom-field-add-on/) for the display-posts shortcode. I would like to acknowledge Bill Erickson, who practically wrote this addon for me when I tried to modify the code of display-posts shortcode to do what I wanted.

I also discussed shortcomings of the implemented solution, with regard to theme modifications. This remains an opportunity for improving my solution, especially if anyone out there knows how to accomplish the same thing with a minimal plugin.

As always, I’d love to receive feedback. Especially if you have ideas how to improve my solution without too much effort. The comments are open 🙂

No Comments Yet.

Leave a Reply