Important meeting for theme developers


Next Tuesday at 18:00 UTC all theme developers should log in into Slack and participate in the meeting. The agenda includes separating functionality from presentation (themes shouldn’t create content) and we should all post examples (themes from

Here is a theme example required to make changes:

Hopefully this will clear the confusion and the guidelines will be more clear regarding themes creating content through widgets or theme options/Customizer.

(Ben) #2

I’m not sure what you mean regarding themes creating content? Could you give an example of something that a theme (the theme you linked?) does that would create content?

(Jimmy Smutek) #3

Hey Ben, I just started reading through the ticket, but immediately came across these examples from comment 5 on the trac ticket.

  • The contact form on the static front page is Plugin territory

  • Testimonials, About Us, About Us features, Our Team, and Our Focus Theme options and related custom Widgets are all user content creation, and as such are Plugin territory. (They are essentially CPTs, disguised as custom Widgets.)

  • Custom post meta data, except for presentational meta data, is content creation, and therefore Plugin territory, e.g. author details, team member position, social network profiles, etc.

I’m sure there’s a ton more good info in the rest of the ticket discussion.


Exactly what @smutek said, also you can read the meeting archive from yesterday. It has all the info you need.

(Ben) #5

awesome - thanks a lot. That clarifies things perfectly :slight_smile:

(Justin Tadlock) #6

The contact form is not content. That’s plugin functionality that TRT doesn’t allow in themes. It’s not a part of what’s up for discussion.

(Jimmy Smutek) #7

Got it, thanks for clarifying that. :smile:

(Justin Tadlock) #8

Essentially, what’s up for discussion is how we deal with those gray areas because theme reviewers have been inconsistently applying the content vs. presentation guideline. These are things that are technically content but maybe not something the user will need beyond the theme. Custom post types, taxonomies, non-presentational metadata are all things that are not in a gray area. Those aren’t up for discussion. Those are the clear-cut cases that we settled long ago. However, there are new scenarios that we haven’t considered as a team.

Footer copyright text is a good example of something that’s typically theme-specific. The theme users wouldn’t care about that with the next theme.

Creating portfolio projects via theme options or custom widgets is probably better handled by a portfolio plugin that the theme integrates with. It’s nothing more than a CPT disguised as a theme option. The theme user would probably not want to re-add all of their portfolio items when switching themes.

Then, there are some that we don’t have an answer for. That’s what we’re discussing and trying to figure out. Ultimately, what we’re attempting to do is clear up some confusion so that reviewers can be more consistent.

(Jimmy Smutek) #9

The discussion in the linked ticket was really interesting.

Yep, this makes sense and I agree as well.

I’m glad to see this. I tried my hand at theme reviews earlier this year. I did 2, maybe 3 reviews and I definitely got the impression that there were things that were not concrete and didn’t seem so clear. One of my biggest concerns was that I didn’t feel like I was quite qualified, (for example, I still don’t understand sanitizing and security stuff). Also, with these gray areas I was worried that I was going to approve something that should not be approved.

I didn’t stop reviewing for that reason, I just got really busy and haven’t made the time for it. Overall it was a great experience and I plan to get involved with TRT again really soon. It seems like all of you have been working really hard on the handbook and guidelines.