If you’ve been following along with 3.8/Twenty Fourteen development, you probably know that Featured Content is being handled by the theme now. It is being moved to the Customizer. This approach is wildly different that what I was doing in the plugin, and I am ok with that. Their approach is lighter weight and might be all a theme needs to display a section of featured posts.
My original idea after @obenland approached me to work on it was way more complex, and it was something that might not belong in core. Or it might, but the plugin didn’t make a compelling case – once again, no biggie.
What did we learn from this?
Having multiple active developers is a must. 15 people had commit, and our meetings had a healthy share of lurkers, but we only had one person doing development. I became the bottleneck for everything, which was enjoyed by no one.
I like the idea of using plugin development to drive feature development. For plugins to be successful projects, I think the teams working on them need to be staffed properly. I think our team went into like “oh cool, we’ll all kinda work on it and then it will happen” – wasn’t the case. We could have benefited from more planning and tasking.
If anyone would like to continue working on the plugin, please do. I would prefer to focus on core development instead.
I finally put a bunch of work into the coding of the plugin, and I think it is fairly robust at this point. Whether it makes it into core ( or whether it even should) is up for discussion, but I would like to share what I have.
To guide development, I made the following list of requirements. It should also be easier for people to follow along when we can all agree on an initial set of facts:
Wherever possible, existing WP functionality and screens will be used. The user should be able to associate posts with Featured Content theme areas as easy as selecting a category or making a post sticky, but, to be more robust, the user should be able to override certain features of a post when it is displayed as a Featured Item in a theme. Example: different title when featured vs what is displayed for a the full post, different image when in a featured module vs the featured image for the post when displayed in single.php.
Post Type / Taxonomy
A Featured Item uses the featured_item post type
A featured_item belongs to a Featured Area
Each Featured Area is a term in the featured_area taxonomy
Post types can opt in to featured content by adding featured_area taxonomy support
Themes can opt-in by supporting ’featured-content’ (the plugin currently brute-forces it)
Creating / Deleting
Add a post with featured area(s), make sure featured item(s) are created
Trash the post, delete permanently, make sure featured item(s) are deleted
Featured item should not have a title when created, it should inherit from the parent post when empty – view in list tables to verify
If a featured item’s title is edited, it should show that in the list table, unless it is empty
Add a post with a featured area, item is created. Edit post to belong to a featured area, 2nd featured item should be created.
Delete one of the featured items, the other should remain, the post should be linked to only one featured area.
Transitioning Post Status
Add a post in draft status, make sure featured item is in draft status
Move a post in draft to publish, make sure featured item is moved as well
If a post was created with 2 featured items and one is trashed: if the term is re-linked to the post, the item in the trash should be untrashed, instead of creating a 3rd item
Trash / Untrash
Trash a post, make sure the featured item(s) are deleted
Untrash a post, make sure the featured item(s) are not created
Trash an existing featured item, make sure post loses tax association
Untrash an existing featured item, make sure post regains tax association
Permanently delete existing featured item, make sure post loses tax association
The Taxonomy box for featured items should be present in Quick Edit
All saving logic should fire in AJAX save routine for Quick Edit
All featured items should be re-orderable via the Re-order items screen
menu_order should be set when items are reordered, only those that change should be sent
When new items are added to a featured area, they should be appended to the end of the list, not the beginning
By default, featured item contains the post data of the post it belongs to
If any fields have been overridden(post_title, post_excerpt), the post data is a merge of the 2
If the featured item has a featured image, the theme can override by using the property ‘image_id’ to grab the featured image on one of the decorated $posts that is returned when applicable
Yeah, so that is a mouthful. All of these use-cases are listed in the comments at the top of the plugin file as well. There’s been a lot of discussion about new UI. If someone wants to think way outside of the box and introduce new screens, keep the above in mind.
Sorry for no meeting this week, it’s been busy at my j.o.b. In addition to the weekly IRC meeting, we now have a Skype conversation going. Add me as a contact on Skype if you want to join in. My Skype username and Trac username are the same.
Last week, I made a screen to sort featured items within their respective areas. The logic to save the order when sorting still needs to be hashed out.
Currently, one person is doing the coding (me). This is not ideal, and I could use help. There have been a bunch of mockups, but I don’t currently have time to build a prototype for all of them. If would like to help with coding, please let me know in the comments.
To me, Featured Content is a flexible way to show one or many posts in one or many places in your theme. A blog might have 1 featured post area that will support 1-4 posts, as an example. A more complex site using WP as a CMS might program its homepage using many “featured areas” that contain varying numbers of post-like entities.
Featured Content, in the end, is just a way to return posts chosen by a content producer. The way in which featured content is selected should be intuitive, easy to manage, and use existing WP technology/terminology whenever possible. A featured post-like thing should an entity that points at a canonical post, while having the ability to override any of the parent post’s attributes on display. Example: I should be able to use a different title and image for a post that is featured when it is rendered in a featured area.
I should also be able to schedule featured items, much like I can schedule a post.
How are we going to implement it?
Here are my ideas:
I think we can get a lot of immediate mileage using a custom taxonomy, working name: “Featured Area” and a custom post type, working name: “Featured Item”. By default, a function like `wp_get_featured_content()` can return all featured posts. Passing a parameter can return posts matching that featured area slug that are published – `wp_get_featured_content( ‘mini-header’ )`. A custom taxonomy can be registered to post and featured_item. Themes can register the taxonomy for more post_types as necessary.
Post Formats are a big feature in WordPress 3.6. What you may not know is: there is now native support for Audio and Video in core! There has been great support for embeds by way of WP_Embed and oEmbed providers for a while, but, if you wanted to play an MP3 from your Media Library, you had to install a plugin. Supporting audio and video in core gives bands, podcasters, vloggers, et al the ability to easily and beautifully expresses themselves through sounds and moving pictures without using an external service.
How does this work?
At the core of the experience is the fantastic library, MediaElement.js. MediaElement is the facade layer that gives us maximum file support and cross-browser compatibility. While some libraries require a Flash-only solution to make your media work cross-environment, MediaElement lets you use HTML5 audio / video tags in every browser, and, only when necessary, will use a Flash or Silverlight plugin in the background to make incompatible media work. Translation, things like this: <audio> tag works in old IE, Windows Media files work in Chrome.
MediaElement uses the same HTML markup, regardless of playback implementation, and you can use CSS to skin the players.
MediaElement’s great, but we don’t want to be locked in to one external library forever. Instead of using MediaElement-specific markup everywhere, we expose audio and video markup through shortcodes: [audio] and [video].
For the following scenarios:
I have an old post that has a video in the Media Library attached to it, and I want to use the new shortcode: [video]
I have the URL for a video, from the Media Library or external, that I want to play: [video src="video-source.mp4"]
I have a source URL and fallbacks for other HTML5-supported filetypes: [video width="600" height="480" mp4="source.mp4" ogv="source.ogv" webm="source.webm"]
Same goes for audio:
I have an old post that has an audio file in the Media Library attached to it, and I want to use the new shortcode: [audio]
I have the URL for an MP3, from the Media Library or external, that I want to play: [audio src="audio-source.mp3"]
I have a source URL and fallbacks for other HTML5-supported filetypes: [audio mp3="source.mp3" ogg="source.ogg" wav="source.wav"]
Shortcodes focus on the “what” and abstract the “how.” If you want to use a library that is not MediaElement, you can! Just look at what to filter: here
There are also new embed handlers for audio and video. Using them is easy as dropping a media link on a line by itself in the editor:
I like this song because it is really cool!
Works for both audio and video with URLs matching the allowed (and filterable) list of extensions (see: here and here)
Using the new post formats UI, it is even easier to get directly at the audio and video in your Media Library. When selecting, the media modal opens to your library, filtered by media type.
In previous versions of WP, you could upload audio and video, but we were not generating metadata like we do for images. In 3.6, using the getID3 library, we are able to extract data from audio and video like cover art, song length, artist, album, song title, genre, codec, etc. It’s pretty great. We will soon be exposing more of this data in the admin as well, along with inline previews on the Edit Media page:
Themers can get in on the action, too, using structured-post-formats in their theme (Twenty Thirteen is a great place to look). The admin gives users flexibility when associating media with a post. the_post_format_audio() and the_post_format_video() will automagically retrieve and output your media in the front end.