04 - Creating a Content Model for an ExpressionEngine Site - Part 2
In part one of creating our portfolio-site content model we identified all the types of content on the site and broke them down into their composite elements. The work was CMS-agnostic, however, so in this installment we’ll mash it together with what we learned about how EE thinks about content and come up with an ExpressionEngine - specific Content Model that will help guide our implementation.
Let’s start by defining our Channel Field Groups and Category Groups.
Field Groups & Fields
As we were identifying the little bits that make up each type of content we were doing most of the work of figuring out our EE fields. However we can take advantage of working with a CMS to make things a bit more efficient in places - mostly around images and summary type fields. We can dynamically create those so we (or our Content Administrators) won’t have to.
Also important to keep in mind is that ExpressionEngine provides some fields by default (including title, author and entry date), so we won’t need to create those in our Field Groups.
Home Page Images Field Group
- Slideshow Image, File field type, mapped to an Upload Destination with an Image Manipulation specified to create the thumbnail version.
- Slideshow Text, Textarea field type, no formatting.
- Slideshown Link, text field, no formatting.
Blog - Video Field Group
A bit of a decision point here as the fields for the Video and Audio content types are pretty much the same - if you think about the core content being a media file. I could create one Blog - Media Field Group and assign it to both the Blog - Audio and Blog - Video channels. The only thing keeping me from doing that is knowing there are some nice add-on field types that make it easy to find and link to videos hosted on either YouTube or Vimeo (assuming we aren’t uploading Video files directly due to the large file sizes they require). While it might seem counter-intuitive that more fields and field groups will be easier in the end you’ll just have to trust me on this one.
- Video File, custom field type.
- Video Description, Rich Text Field
Blog - Audio Field Group
The only complexity I can see here is allowing audio files to be either uploaded or linked to. We’ll handle it with two fields and some logic in our templates.
- Uploaded Audio File, File field type, mapped to a specific audio uploads directory.
- Linked Audio File, Text field type.
Blog - Link Field Group
- Link Target, Text field type.
- Link Text, Text field type
Blog - Quote Field Group
- Quote Author, Text field type.
- Quote Text, Textarea field type, XHTML formatting.
Blog - Post Field Group
- Blog Post Image, File field, mapped to a specific Upload Destination with an Image Manipulation to create the footer thumbnails.
- Blog Post Text, Rich Textarea field, XHTML formatting.
Blog - Image Field Group
I may change my mind about this one as the essential elements of the Blog - Image are the same as the Blog - Post. One field group may be possible, but for now I will assume a dedicated one for each.
- Blog Image, File field type, mapped to a specific Upload Destination location.
- Image Description, Textarea field type, XHTML formatting.
About Field Group
- Main Content, Rich Textarea field type, XHTML formatting.
- Sidebar Content, Rich Textarea field type, XHTML formatting.
- Footer Blurb, Rich Textarea field type. XHTML formatting.
Work Field Group
- Work Image, File field type, mapped to an Upload Destination with Image Manipulations for smaller versions.
- Work Description, Rich Textarea field type, XHTML formatting.
- Work Client, text field, no formatting.
- Work Link, text field, no formatting.
File Upload Directories & Image Manipulations
It might be a stretch to consider the organization of uploaded files as part of a Content Model, but since EE’s Image Manipulations need to be defined before content is added (and indeed are involved in creating content) it’s probably best to map out what Upload Destinations we’ll need along with related Image Manipulations. One thing to consider here is how bullet-proof EE needs to be with regard to uploaded images. Do you trust yourself (or your users) to upload the correct full-size version, or should we just have EE do that as well? I’m going to choose the safe route and have EE create all necessary sizes of images for the site. I may need to revisit this as I figure out how the site’s “responsiveness” is implemented, but for now this will do:
Home Page Destination
- Main Image = 882px by 344px
- Small Image = 188px by 73 px
Blog Post Destination
- Main Image: 640px by 250px
- Footer Image: 54px by 54px
Blog Image Destination
- Main Image: 640px by 250px
- Popup Image: 940px wide
Blog Audio Destination
- No manipulations
Work Image Destination
- Related Image: 220px wide
- Gallery Image: 300px wide
- Main Image: 940 px wide
Our sample portfolio site uses categories in two sections: Blog and Work. These could possibly all share one Category Group but we’ll split it up into two just for the fun of it:
Blog Category Group
We’ll manufacture some specific categories here when we get to that point.
Work Category Group
Just so we don’t overlook it, our design also includes tagging - which will require a 3rd party module to pull off. Other that noting it here there isn’t much impact to our Content Model as tags are inherently ad-hoc.
ExpressionEngine has Status Groups that could also be part of a Content Model - for handling such things as Featured Content, or Featured Photos, etc. Our front-end design just didn’t have any aspects to it that I felt would best be served with a custom Status of any sort, so we’ll just use the default Status Group that EE installs with which allows entries to be Open or Closed.
Remembering our 1 channel == 1 content type rule the list of channels is pretty straightforward. They will all be assigned to the default Status Group. They will each be assigned their specific Field Group, the Blog channels will all share the Blog Category Group, and the Work Channel will be assigned the Work Category Group.
- Home Page Slideshow
- Blog - Audio
- Blog - Video
- Blog - Link
- Blog - Quote
- Blog - Post
- Blog - Image
So There You Have It
So there’s our completed ExpressionEngine Content Model - at least a rough one. We’ll refine things more as we start implementation by creating a good naming schema, etc. But for now it’s good enough to move forward with.
In our next installment we’ll begin moving the sample HTML code into EE.