Title: Standards vs. Innovation Author: Justin Tadlock Published: November 26, 2014 --- [ ](https://profiles.wordpress.org/greenshady/) [Justin Tadlock](https://profiles.wordpress.org/greenshady/) 12:00 am _on_ November 26, 2014   # Standards vs. Innovation One of the reasons I originally got involved with the Theme Review Team was to add a little balance to what I and many other theme authors felt like were overly strict guidelines dealing with how themes should be coded. We needed more voices from experienced people doing this theme thing. Standardization is almost always a good thing. However, it is not good when it stands in the way of innovation. The one thing I’ve fought long and hard for is to make sure the TRT doesn’t stifle innovation in any way if it can be avoided. I think we’ve all heard it before — “If you’re not doing it this way, maybe your theme just isn’t right for our repository”. That’s directly in opposition of the plans for the theme repository, which is to provide the best free WordPress themes in existence. Sometimes, our way isn’t the best way. I even like to think of myself as a pretty darn good developer, but I’m continually amazed at some of the cool techniques that theme authors are employing in their themes. Often times, these techniques simply clash with our guidelines. It’s not bad code; it just doesn’t fit into our standards. ## The need for standards Don’t get me wrong. Anyone who knows me, knows that I’m a stickler for standards. I’m pretty up front about it. We absolutely need standards and to continue improving on our guidelines. And, there are things where we need to draw a pretty hard line. Frankly, we see a lot of bad code coming through the review process. Without guidelines to guide reviewers and theme authors, it’d be a mess. However, we must recognize that there are some people out there doing some awesome stuff that’s not going to fit into this nice, neat little box we want everyone to fit into. If we’re stopping these themes from making into the repository, we’re not doing our jobs. We’re failing as a team. We need to be able to recognize when theme authors are writing good code that doesn’t match up with what we think a theme should be. Admittedly, I’ve fallen short in this myself and have been a bit too strict at times. I hope to do better in the future. ## What prompted this discussion? In our weekly meeting, it was mentioned that a `comments.php` template (loaded via the **comments_template()** function) should be required in all repository-hosted themes. It had already been decided that this wasn’t a requirement, but it was brought back up for discussion. It’s a rarity that a theme author would do anything different anyway. However, there are many ways (using coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. WordPress functionality) to display comments. I don’t want us to stand in the way of a theme author simply trying something different. This discussion went on to say that the use of **get_header()**, **get_footer()**, and **get_sidebar()** should be required. Yes, we absolutely should be using those functions **if** our intention is to load those templates. That’s not really in question. What’s in question is whether we should require their use. Anyone who has been around theming for a while knows that the only theme files required for a properly-working theme are `index.php` and `style.css`. If we begin requiring the use of specific templates, we’re doing a major disservice to the theme development community. We will make certain that they cannot innovate when it comes to templates. There’s a case to be made that the use of those functions will fire certain hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. that plugins may use. That’s definitely true. However, that’s a slippery-slope to go down. I can sit here and rattle off any number of hooks that may or may not be fired, depending on which functions or features a theme decides to use. I’m prepared to go down that slope, but it won’t get us anywhere except for possibly even stricter guidelines. ## An ongoing issue This is not a single, one-off issue that we’ve had. It’s part of a larger issue that has been going on for years. Standards are good only when they don’t get in the way of good developers innovating. Some of the awesome stuff we have today with theming (features now in core) would never have been possible if those theme authors were building themes within the current era and trying to get their themes on the repository. If our goal is to make every theme the same, I’m not so sure this is a community I want to be a part of. If our goal is to have quality themes with good code, we need to be able to think outside of our set of standards once in a while. We’ve made great strides in the past few weeks in getting rid of some legacy stuff, clarifying existing guidelines, and making things a little less strict. I want us to continue down this path. ### Share this: * [ Threads ](https://make.wordpress.org/themes/2014/11/26/standards-vs-innovation/?share=threads) * [ Mastodon ](https://make.wordpress.org/themes/2014/11/26/standards-vs-innovation/?share=mastodon) * [ Bluesky ](https://make.wordpress.org/themes/2014/11/26/standards-vs-innovation/?share=bluesky) * [ Facebook ](https://make.wordpress.org/themes/2014/11/26/standards-vs-innovation/?share=facebook) * [ X ](https://make.wordpress.org/themes/2014/11/26/standards-vs-innovation/?share=x) * [ LinkedIn ](https://make.wordpress.org/themes/2014/11/26/standards-vs-innovation/?share=linkedin) * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fthemes%2F2014%2F11%2F26%2Fstandards-vs-innovation%2F%23respond&locale=en_US) 1. ![](https://secure.gravatar.com/avatar/250257111d1248c34046552bbcdf6999949ef56b2f992dd5eb39bf45cabeb18a? s=32&d=mm&r=g) 2. [Samuel Wood (Otto)](https://profiles.wordpress.org/otto42/) 12:06 am _on_ November 26, 2014 3. Typically, the guidelines run along the lines of “If you have a headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes., then you should name it header.php, and use get_header() to call it”. 4. I don’t see how that is overly strict in any real way. 5. On a broader note, including functions like wp_head() and wp_footer() are really not optional. WordPress expects them to be there. WordPress adds things to them. If they’re not there, then parts of the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functionality don’t work. Themes must support the core functionality. So yes, I’ll fight back against you on that score. 6. But if you don’t have anything that qualifies as a “header”, then not having one is fine. Put your call to wp_head() in the head section of your index.php, as appropriate. 7. * ![](https://secure.gravatar.com/avatar/8013a62d7397c006bae48b96d6832a573ea71a7d5d3597fe584210567b508c05? s=32&d=mm&r=g) * [Justin Tadlock](https://profiles.wordpress.org/greenshady/) 12:56 am _on_ November 26, 2014 * I’m in complete agreement with everything you just wrote. 8. ![](https://secure.gravatar.com/avatar/fcbc6869ca65225c6bfbd46b7f1720efc6bd0b966f1a3ea9401663d9e9870459? s=32&d=mm&r=g) 9. [NateWr](https://profiles.wordpress.org/natewr/) 12:24 am _on_ November 26, 2014 10. It would help me to orient myself in this discussion if you could provide a few examples of themes doing good work that might veer away from the current guidelines. The example in Otto’s comment seems straightforward enough, but I suspect your discussion of innovation might be referring to more imaginative or substantial modifications. 11. * ![](https://secure.gravatar.com/avatar/8013a62d7397c006bae48b96d6832a573ea71a7d5d3597fe584210567b508c05? s=32&d=mm&r=g) * [Justin Tadlock](https://profiles.wordpress.org/greenshady/) 1:23 am _on_ November 26, 2014 * I’ll show you one from my own experience that I had to fight tooth and nail to get through the process. It’s the [HTML attribute system](https://github.com/justintadlock/hybrid-core/blob/master/functions/attr.php) I built. You’re free to see it in use in any of my recent themes. * The original argument was that I must use the `post_class()` and `body_class()` functions. In general, that’s a very good guideline. However, that guideline didn’t allow for the use of `get_body_class()` or `get_post_class()`, equally appropriate coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functions, which my attribute system made use of. Note that the system had to use the getter functions because they returned their values rather than printing them. That’s the short version of it anyway. * In that particular case, things worked out after a long discussion. But, I think it’s a good example of how we can be a bit strict at times without looking at the whole picture. 12. ![](https://secure.gravatar.com/avatar/59e1a590bd62f727f14fef6e1bd149246dba2ccde87b108f54f7bb3869fc4235? s=32&d=mm&r=g) 13. [Reza](https://profiles.wordpress.org/rezaurc/) 12:43 am _on_ November 26, 2014 14. > I’m a stickler for standards. me too 🙂 15. ![](https://secure.gravatar.com/avatar/7d256f7b605361e4dc402138e2896ff727d2a13d669f1420a8644d12a90bb7af? s=32&d=mm&r=g) 16. [Chip Bennett](https://profiles.wordpress.org/chipbennett/) 1:42 am _on_ November 26, 2014 17. I’m going to write a post to touch on this from a higher level, but I am concerned about removing the requirement for Themes to support the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. comments feature via `comments_template()`. There are significant Plugins that rely on the filters fired by `comments_template()`, that would no longer work if those filters are not fired: JetPack Comments, Disqus, Livefyre (just the first few that I checked). 18. So, I think that “plays well with Plugins” is a critical feature of hosted Themes. Hooking into the comments template is a very common PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. interaction. So, either we require comments implementation via `comments_template()`, or we have to verify that Themes are properly using core filters such as `comments_template`, `comments_array`, etc. 19. In 99% (if not 99.9%) of Themes, I don’t see any avenue for innovation that involves circumventing `comments_template()`. And for that 1% (or 0.1%), there is always the option to make a one-off exception. 20. As for `get_header()` etc. – they fire hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. as well, but they are very edge-case hooks, that rarely if ever get used. So, I would agree: if a Theme developer wants to duplicate the headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. markup in every template file (or use only an `index. php`), there is little-to-no risk that a Plugin or core would be impacted by the` get_header` action being missing. (Or, it’s very easy for the reviewer to recognize the missing hook, and ask for it to be included. 21. But when you’re talking about functional output as complex as `comments_template()`, I think it’s asking too much of reviewers to grok that much code. The learning curve is steep enough as it is. 22. * ![](https://secure.gravatar.com/avatar/8013a62d7397c006bae48b96d6832a573ea71a7d5d3597fe584210567b508c05? s=32&d=mm&r=g) * [Justin Tadlock](https://profiles.wordpress.org/greenshady/) 1:57 am _on_ November 26, 2014 * I’m not sure how much you’ve caught up on things since your TRT vacation, but it was said in a meeting or one of our posts (can’t remember which) that we want to avoid exceptions. We’ve traditionally always allowed exceptions to most guidelines with a valid reason, but this is something that the team is trying to get away from. * Not to mention, the problem with this is that it would likely go into Theme Check. A theme author wouldn’t even be able to submit their theme without some special, behind-the-scenes type thing going on. * In 99% of cases, this will never be an issue. That’s why I believe the particular case of `comments_template()` is really non-issue and doesn’t need to be addressed. I just want us to leave open the possibility that someone is going to try something new. Having a specific guideline for this just adds to the clutter when it’s already rare that this would happen. We don’t need to cover absolutely everything in the guidelines. * I also happen to believe that it’s OK for plugins not to work with every theme. We should try our best to make sure they all play nicely together, but if a theme author really wants to try out something new, we shouldn’t stand in the way. - ![](https://secure.gravatar.com/avatar/7d256f7b605361e4dc402138e2896ff727d2a13d669f1420a8644d12a90bb7af? s=32&d=mm&r=g) - [Chip Bennett](https://profiles.wordpress.org/chipbennett/) 2:00 am _on_ November 26, 2014 - So, if Theme Check simply checks for a call to `comments_template()`, the problem is solved, with no (known) burden placed on developer innovation. - And if it is desirable to facilitate innovation (and I agree that it is, indeed, desirable), then I don’t understand the need or desire to move away from exceptions. To the best of my knowledge, there were probably fewer than a half-dozen such exceptions requested/granted in several years. * ![](https://secure.gravatar.com/avatar/8013a62d7397c006bae48b96d6832a573ea71a7d5d3597fe584210567b508c05? s=32&d=mm&r=g) * [Justin Tadlock](https://profiles.wordpress.org/greenshady/) 2:04 am _on_ November 26, 2014 * That wouldn’t solve the problem if it’s a “warning” rather than an “info” notice. Warnings aren’t even allowed to be submitted. They don’t get past the uploader. * I agree on exceptions. I didn’t think anything needed to change there either. - ![](https://secure.gravatar.com/avatar/7d256f7b605361e4dc402138e2896ff727d2a13d669f1420a8644d12a90bb7af? s=32&d=mm&r=g) - [Chip Bennett](https://profiles.wordpress.org/chipbennett/) 2:45 am _on_ November 26, 2014 - But in the case of `comments_template()`, I think it *should* be a warning. There’s no good use case to omit it, and too many end-user problems if it *is* omitted. - ![](https://secure.gravatar.com/avatar/8013a62d7397c006bae48b96d6832a573ea71a7d5d3597fe584210567b508c05? s=32&d=mm&r=g) - [Justin Tadlock](https://profiles.wordpress.org/greenshady/) 2:57 am _on_ November 26, 2014 - Yeah, I completely disagree on that point. - ![](https://secure.gravatar.com/avatar/8013a62d7397c006bae48b96d6832a573ea71a7d5d3597fe584210567b508c05? s=32&d=mm&r=g) - [Justin Tadlock](https://profiles.wordpress.org/greenshady/) 4:01 am _on_ November 26, 2014 - > There are significant Plugins that rely on the filters fired by comments_template(), > that would no longer work if those filters are not fired: JetPack Comments, > Disqus, Livefyre (just the first few that I checked). - I did want to touch on this a moment because I do think it’s worth discussing. - The first thing is that the JetPack Comments module doesn’t rely on the ` comments_template` filterFilter Filters are one of the two types of Hooks [https://codex.wordpress.org/Plugin_API/Hooks](https://codex.wordpress.org/Plugin_API/Hooks). They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. hook, at least as far as I know. I’m not sure about the other plugins, but I imagine Automattic has some pretty smart devs on board who realize that not all themes (even those outside the repository) are going to use that particular function. What’s true today has always been true for themes: only an `index.php` and `style.css` file are needed to make a theme that works properly. Any pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress. org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. developer messing around with this sort of thing knows this. - From a plugin development standpoint, it can be pretty dangerous to be overwriting an entire theme template like that. There’s really no telling what you might end up doing to the output of a theme because you have no way of knowing exactly what it is that you’re overwriting. If possible, a smarter thing to do would be to use the hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. related to `wp_list_comments()` and ` comment_form()`. - Let’s say that we do decide all themes must use `comment_form()` and load a `comments.php` template. That puts us in a position of dictating what must go into that particular file as well, which would probably be a requirement that both `wp_list_comments()` and `comment_form()` be placed in the file. See, this must be a requirement because we’re assuming that plugins are going to overwrite the comments template with their own. That definitely throws out p2, which is a pretty innovative theme. But, it’s going to show multiple comment forms unless those plugins write in some kind of exception specific to it. * ![](https://secure.gravatar.com/avatar/7d256f7b605361e4dc402138e2896ff727d2a13d669f1420a8644d12a90bb7af? s=32&d=mm&r=g) * [Chip Bennett](https://profiles.wordpress.org/chipbennett/) 3:59 pm _on_ November 26, 2014 * JetPack and (IIRC) LiveFyre rely on the `comments_array` filterFilter Filters are one of the two types of Hooks [https://codex.wordpress.org/Plugin_API/Hooks](https://codex.wordpress.org/Plugin_API/Hooks). They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., which is applied as part of the` comments_template()` functional output. Disqus relies on the `comments_template` filter, which is also applied as part of the `comments_template()` functional output. * Either way: they’re both coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. filters. Thus, core intends for them to be filterable. * I see no problem with the comments list and comments form being required as part of supporting the core Comments feature. This is part of the baseline end-user expectation of functionality. - ![](https://secure.gravatar.com/avatar/0c00bc6bb79905cd73ec1cb0f22bf813f7f34f46ee670d018b30b5569b2924dd? s=32&d=mm&r=g) - [Tammie](https://profiles.wordpress.org/karmatosed/) 9:50 am _on_ November 26, 2014 - Just adding a clarification as I feel there is some feeling of something that’s not happened. Exceptions is a word that can have a lot of meaning. In the context of how it’s been used in our team meetings, meetings after, blog posts and the revised requirements; it was referring to having more clear cut requirements. This is absolutely something we should be encouraging and we have all talked about desiring this. - However, there will always be ‘required if’ cases. Whether it’s a template, function or tag – some cases only require ‘if’ something is there. You could even put the accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both“ direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers).( https://en.wikipedia.org/wiki/Accessibility)-ready tag into that. The ‘ifs’ are a fact of themeing not something we ever talked about having to reduce blindly. They also can be clear cut – if this happens, this happens. The issues come when we have long clauses and long paragraphs to clarify a requirement, be it an ‘if’ or a global requirement. - Our drive as a team has been towards clarity and ease of understanding for all levels – be you advanced or a new theme reviewer. Not towards blind ruling out a type of requirement just because. * ![](https://secure.gravatar.com/avatar/8013a62d7397c006bae48b96d6832a573ea71a7d5d3597fe584210567b508c05? s=32&d=mm&r=g) * [Justin Tadlock](https://profiles.wordpress.org/greenshady/) 6:15 pm _on_ November 26, 2014 * I must’ve misunderstood. This was exactly the type of exception I was talking about [here](https://wordpress.slack.com/archives/themereview/p1415121812001632). I’m glad that’s clear because I thought you were talking about not wanting to allow any exceptions. - ![](https://secure.gravatar.com/avatar/db998bdb0f76240cd86cf6bd8f64bd619bda0314bcead1d8ef5c9c3ba839ed71? s=32&d=mm&r=g) - [Daniel Tara](https://profiles.wordpress.org/pseudoxiah/) 3:11 pm _on_ November 26, 2014 - I once wanted a theme to display commens in archives like P2P2 P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at [https://make.wordpress.org](https://make.wordpress.org/) or Pinterest does it and was disappointed to see that comments_template(); only loads them on single posts. I was almost at the point of giving up using that function when I discovered that a global $withcomments can be set to true and the template loads anywhere. I believe in such cases it should be first looked into if CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. has a filterFilter Filters are one of the two types of Hooks [https://codex.wordpress.org/Plugin_API/Hooks](https://codex.wordpress.org/Plugin_API/Hooks). They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. or hook that can help you acchieve what you want before circumventing its implementation. Some core functionality is indeed limited and could prevent something from working the way we want it to but in most cases it’s extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. enough to allow for almost anything. The problem is that such hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., filters or globals are often well hidden and developers prefer to just implement their own thing rather than dig up in the WordPress source code. * ![](https://secure.gravatar.com/avatar/8013a62d7397c006bae48b96d6832a573ea71a7d5d3597fe584210567b508c05? s=32&d=mm&r=g) * [Justin Tadlock](https://profiles.wordpress.org/greenshady/) 4:35 pm _on_ November 26, 2014 * We’re not having a discussion about what can be done with coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. or globals. We’re talking about stopping good developers from being able to do something when there are no options are available like that. And, we’re talking about adding in new guidelines for a %0.01 chance of something happening. * Some people seem to be misunderstanding that. This is nothing more than the pedantic attitude that we had before with TRT that we’ve been desperately trying to get away from. - ![](https://secure.gravatar.com/avatar/7d256f7b605361e4dc402138e2896ff727d2a13d669f1420a8644d12a90bb7af? s=32&d=mm&r=g) - [Chip Bennett](https://profiles.wordpress.org/chipbennett/) 8:01 pm _on_ November 26, 2014 - “…pedantic attitude that we had before with TRT”? Give me a break. - I don’t think end users would find it “pedantic” for the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. comment feature to be consistent from one Theme to the next, and for their chosen comments PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. to work consistently from one Theme to the next. - `wp_list_comments()` can be overridden completely via callback, as can `comment_form()`. There’s no reason not to use them. There’s nothing“ pedantic” about requiring that Themes implement comment lists and comment reply forms using these core functions. - The same holds true for `comments_template()`. - Ambiguous, non-specific “innovation” is not sound reason to avoid standardization in implementation of a core feature. - ![](https://secure.gravatar.com/avatar/8013a62d7397c006bae48b96d6832a573ea71a7d5d3597fe584210567b508c05? s=32&d=mm&r=g) - [Justin Tadlock](https://profiles.wordpress.org/greenshady/) 8:35 pm _on_ November 26, 2014 - I doubt we’ll ever agree on this because you seem to be missing my point altogether. I see no reason in continuing this with you. 23. ![](https://secure.gravatar.com/avatar/0c00bc6bb79905cd73ec1cb0f22bf813f7f34f46ee670d018b30b5569b2924dd? s=32&d=mm&r=g) 24. [Tammie](https://profiles.wordpress.org/karmatosed/) 1:55 am _on_ November 26, 2014 25. I’m going to take a nonspecific view in my response, as this particular post brings important philosophical points up regarding approach. 26. First up, i agree its very good to check ourselves in our approach. Particularly after a period of change like we have just experienced and continue to ride. We should always remind each other of our coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. focus and steer our review ship back onto it. We should also always check what that focus should be and as a team review. We are a team and our different voices all count equally. 27. I see innovation and standards in some respects as not opposing but balancing. The handbook itself to me, is a constant quest almost of Zen proportions to get as reduced but as robust as possible. This said, my personal take home was more that the hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. conversation could be seen as either innovation or a tighter standard. That’s why the discussion to me seemed right. I was hearing voices from both ends of the spectrum, hence a debate. 28. I’ll clearly state as I have before, my own preference is less requirements and more clarity. A binary set of requirements that can be said in single sentences not clause paragraphs. I say preference, because I get the world isn’t binary. 29. I delight at theme innovation, I think any themer does. We live for those joyous theme moments of delight when we become a fan girl or boy. Innovation for innovations sake doesn’t ever work. It always pushes forward when done on the shoulders of solid foundations. The foundations of good theming. We need to be clear enough to allow innovation, but also not make reviewing too hard to do. Not every I and t can always be crossed. We need that balance. 30. Sometimes our tools have to be updated. Sometime requirements need changing. Sometimes its a matter if education. Sometimes we have to draw lines in the sand. Sometimes we have to open doors we previously locked. 31. ![](https://secure.gravatar.com/avatar/f74e342feb67d21bd90e316bf8f68400dbb0eced2bfad7f90a69cda29f32ac23? s=32&d=mm&r=g) 32. [Sakin Shrestha](https://profiles.wordpress.org/sakinshrestha/) 3:46 am _on_ November 26, 2014 33. Innovation and unique design is very important for the Theme Repo now as we are having lot of similar design these days. Yes, I agree with [@greenshady](https://profiles.wordpress.org/greenshady/) that, it is not good when review stands in the way of innovation. But again standardization and quality of code is very important. Let’s find the balance. 34. I am happy to see theme review team actively discussing about it. It’s good to see [@chipbennett](https://profiles.wordpress.org/chipbennett/) back and I am sure we will come up with good review guideline. As for now the guideline is not so easy for reviewer as well as theme author. The recent changes in Handbook with Required and Recommended and updates in Theme Check pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. is a good progress and will ease the process. 35. Also as per your discussion in WordCampWordCamp WordCamps are casual, locally- organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. [Learn more](https://central.wordcamp.org/about/). San Francisco, there will be time where we need to to look at the theme case by case. So, I think this clause can help innovate. But, I think we need to state clearly about how theme author can do this or ask for reviewer for special case. If we can solve this then yes, there will be innovation coming in while maintaining standards. Also in make blog section with Design Challenge and educating about the design and coding standard will definitely make this process smooth. 36. It’s good to see that we all are here to make things better in Theme Repo. Thank you all. 37. ![](https://secure.gravatar.com/avatar/987ef7bf8a72a011aa249f6cee71130ee27968bee77dd6985d27160d5ba06143? s=32&d=mm&r=g) 38. Anonymous User 9:11 am _on_ November 26, 2014 39. There is a comment that talks about guidelines being a balancing act and I agree. But it’s not as simple as balancing standards and innovation. When taking decisions, we need to take a multitude of other factors into account. 40. Like Justin, I am a very big proponent of standards. Having standards makes themes easier to review and easier to test through automated scans. 41. The more scenarios we have to consider during automated scans, the more difficult it becomes to scan for this effectively. We cannot on the one hand state that we need automation to be able to reduce review times and then on the other hand allow even the most obscure development techniques. 42. To take Justin’s example, I don’t really see why you would need to write a wrapper function to achieve the desired result for the body class. You could well use CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s body_class(), filterFilter Filters are one of the two types of Hooks [https://codex.wordpress.org/Plugin_API/Hooks](https://codex.wordpress.org/Plugin_API/Hooks). They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. the classes and then add a function to output the item scope values. 43. That would achieve the same outcome, use WordPress’ built-in function and not fail an automated scan such as this one: [https://github.com/Otto42/theme-check/pull/5](https://github.com/Otto42/theme-check/pull/5) 44. Saying that having stricter standards makes innovation impossible is not a great argument in my opinion. A theme developer that makes the case that he cannot create a theme with the existing APIs and Template Hierarchy is similar to a developer making the case for hacking Core. 45. I often see the argument that having good theme development practices is a matter of education. And I agree with that. 46. But the guidelines should be done in a way that covers the basics, as in what functions and templates are needed for a theme to be coded in an elegant way and work with most plugins. 47. With the basics covered, we can focus on providing education for more advanced things. Because that is where the value of experienced reviewers comes in. 48. * ![](https://secure.gravatar.com/avatar/8013a62d7397c006bae48b96d6832a573ea71a7d5d3597fe584210567b508c05? s=32&d=mm&r=g) * [Justin Tadlock](https://profiles.wordpress.org/greenshady/) 5:23 pm _on_ November 26, 2014 * > The more scenarios we have to consider during automated scans, the more > difficult it becomes to scan for this effectively. We cannot on the one hand > state that we need automation to be able to reduce review times and then > on the other hand allow even the most obscure development techniques. * Honestly, I rarely use any type of automated scanning for review. I have eyeballs that work better and can tell me the whole story. If we’re relying this heavily on automated scans, maybe what we really need is better education of our reviewers. One of the bests ways get that education in is by seeing different scenarios. * I haven’t been asking for better automation to reduce review times. Most of the problems I see aren’t something that an automated scan can check for anyway. * > To take Justin’s example, I don’t really see why you would need to write > a wrapper function to achieve the desired result for the body class. You > could well use CoreCore Core is the set of software required to run WordPress. > The Core Development Team builds WordPress.’s body_class(), filterFilter > Filters are one of the two types of Hooks [https://codex.wordpress.org/Plugin_API/Hooks](https://codex.wordpress.org/Plugin_API/Hooks). > They provide a way for functions to modify data of other functions. They > are the counterpart to Actions. Unlike Actions, filters are meant to work > in an isolated manner, and should never have side effects such as affecting > global variables and output. the classes and then add a function to output > the item scope values. * Of course, you would be coding that incorrectly and doing some really unexpected things. You better believe this wouldn’t be allowed on the theme repository. * My method allows plugins to still use the proper core hook, it utilizes a core function, and it is coded correctly. Not only that, it serves as a real-world example for a current ticket in TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.[https://core.trac.wordpress.org/](https://core.trac.wordpress.org/).. If we’re preferring automation over that, then this conversation isn’t really going anywhere. * > A theme developer that makes the case that he cannot create a theme with > the existing APIs and Template Hierarchy is similar to a developer making > the case for hacking Core. * This post has nothing to do with not using existing APIs. You know as well as I do that this is not similar to hacking core. We’re talking about putting in additional guidelines that would serve no purpose but to blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. that %0.01 chance of someone trying something new. * Also, I can code you a theme using existing APIs and the Template Hierarchy with a single `index.php` template. * > I often see the argument that having good theme development practices is > a matter of education. And I agree with that. * Me too. Spending our time on education is more important and will be more productive than having this discussion. 49. ![](https://secure.gravatar.com/avatar/8013a62d7397c006bae48b96d6832a573ea71a7d5d3597fe584210567b508c05? s=32&d=mm&r=g) 50. [Justin Tadlock](https://profiles.wordpress.org/greenshady/) 10:59 pm _on_ November 26, 2014 51. I’m going to attempt to sum my thoughts up here because I fear this discussion has taken a turn for the worst. That’s probably my fault for not staying on course. 52. One of our goals with the guidelines is to simplify things so that things don’t get too complex. This means throwing out some of the requirements that are really unnecessary clutter. We could attempt to dot every “i” and cross every “t”, but that makes things more complex for both authors and reviewers. 53. In the particular case of the `comments_template()` function, I’d be the first person telling you that you must use it for a number of very good reasons. However, do we really have an issue here? How many themes has anyone ever seen that doesn’t make use of this function? I’m sure there are some, but I can’t think of any offhand. So, why are we arguing over adding a guideline that is, for all intents and purposes, useless? That’s like adding a guideline saying that all themes must call `the_post()`. _No s***, Sherlock_. But, I’m not going to knock someone if they need to do something that’s not supported by coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. 54. If this guideline is useless, what’s the big deal? Going back to the first point, it adds unnecessary clutter. And, in that 0.01% – 1% chance that someone has a really awesome idea they want to try, we say “no” without any consideration. ### Leave a Reply 󠀁[Cancel reply](https://make.wordpress.org/themes/2014/11/26/standards-vs-innovation/?output_format=md#respond)󠁿 You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fthemes%2F2014%2F11%2F26%2Fstandards-vs-innovation%2F&locale=en_US) to post a comment. This site uses Akismet to reduce spam. [Learn how your comment data is processed.](https://akismet.com/privacy/) # Post navigation [← We are going to have an extra meeting…](https://make.wordpress.org/themes/2014/11/25/we-are-going-to-have-an-extra-meeting/) [Handbook refresh. →](https://make.wordpress.org/themes/2014/11/26/handbook-refresh/)