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.
First, check out the latest code in trunk here: https://plugins.svn.wordpress.org/wp-featured-content/trunk/
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.
The plugin is in the repo:
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.
Ahead of our first official office hours, here is an overview of what I would like to discuss:
What is Featured Content?
Obenland discussed the high-level concept here: https://gist.github.com/obenland/3010432c8edcfcbf95a9
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.
The plugin, in its current form, implements all of the above: https://wordpress.org/plugins/wp-featured-content/
Things to consider:
- How do we always keep the post and its featured_item brethren in sync?
- Do featured_items and posts always share the same post_status? Should they be independent?
- How do themes opt in to multiple featured areas if the terms have not be created for the featured_area taxonomy?
- What are alternate ways to implement the above?
As my last task as acting lead for Featured Content, I’m happy to announce our first IRC chat on Monday, 1700 UTC in #wordpress-dev, led by @wonderboymusic.
We will talk about the project organization and intended functionality for the plugin (on a high level!). Goal of the meeting is that everyone has a clear understanding of where the project is headed, what the next step in the process will be, and who is working on that.