WordPress.org

Ready to get started?Download WordPress

Review WordPress Themes

Updates from May, 2012 Toggle Comment Threads | Keyboard Shortcuts

  • Chip Bennett 3:21 pm on December 14, 2012 Permalink | Log in to leave a Comment
    Tags: ,   

    query_posts() 

    While the clock has started ticking on the 3.5 release grace period for Guidelines updates, I would like to discuss formalizing one other _doing_it_wrong() issue that has been implicitly enforced for some time now: use of query_posts().

    Would anyone be opposed if we formally added query_posts() to Theme Check as a required stopper?

    To understand why query_posts() is always inherently _doing_it_wrong(), see @nacin‘s WordCamp presentation You Don’t Know Query, and this great WordPress StackExchange answer by @rarst.

    In short, if you are creating secondary queries, you should use WP_Query(), and if you’re modifying the main query, you should filter pre_get_posts.

    Thoughts?

     
    • Andrew Nacin 3:23 pm on December 14, 2012 Permalink | Log in to Reply

      I’d say recommended, until WordPress itself declares that query_posts() is`_doing_it_wrong().

      • Chip Bennett 3:25 pm on December 14, 2012 Permalink | Log in to Reply

        What would the benefit be of making it only *recommended*?

        Whether core flags the function itself as _doing_it_wrong() or not, it is always a bad practice, leads to unexpected results, and causes problems for the end user.

        • scribu 3:37 pm on December 14, 2012 Permalink | Log in to Reply

          Using the ‘pre_get_posts’ filter incorrectly can also lead to unexpected results and cause problems for the end user.

          It’s actually easier to use query_posts() correctly than to add all the appropriate checks to a callback hooked into ‘pre_get_posts’.

          • Daniel 3:40 pm on December 14, 2012 Permalink | Log in to Reply

            This is a good point. The ‘request’ filter was built for the specific reason to alter the main query and the main query only; only problem is its implementation is still not complete. I propose we don’t push this as required until we are sure we have a bulletproof workaround.

          • Chip Bennett 3:52 pm on December 14, 2012 Permalink | Log in to Reply

            True. But then, so can calling wp_nav_menu() incorrectly (e.g. by passing ‘menu’ instead of ‘template_location’). But we don’t allow Themes to use wp_list_pages()/wp_page_menu()/wp_list_categories() in place of wp_nav_menu(). Instead, we educate about proper usage of wp_nav_menu().

          • Konstantin Kovshenin 7:04 pm on December 14, 2012 Permalink | Log in to Reply

            Using the ‘pre_get_posts’ filter incorrectly can also lead to unexpected results and cause problems for the end user.

            That’s so true!

    • Konstantin Kovshenin 3:25 pm on December 14, 2012 Permalink | Log in to Reply

      I’d go for recommended too, but huge +1 on the initiative!

      • Chip Bennett 3:28 pm on December 14, 2012 Permalink | Log in to Reply

        My problem with *recommended* is that, when query_posts() is used, it is almost *never* used *properly*. So, in order to pass the review process, the reviewer will have to help the developer rehabilitate the use of query_posts(), instead of simply requiring the cleaner, proper implementation via WP_Query or pre_get_posts.

        Instead of teaching developers how to rehabilitate query_posts() usage, wouldn’t it be a far better use of our time to teach *proper* usage of best-practice methods?

        • Maor Chasen 8:29 am on December 21, 2012 Permalink | Log in to Reply

          I agree. I think that for some developers it will take a while to realize that query_posts() is not the correct method, and if we don’t make it required now, then by the time it is being marked as _doing_it_wrong() in core — developers will still use it. IMHO, there are things that you don’t postpone, and this one is among them. Because if we don’t, it’s not just that we’re not teaching developers how they *should* do it, but end users might suffer from endless bugs that will be directly caused by the misuse of query_posts().

    • Daniel 3:29 pm on December 14, 2012 Permalink | Log in to Reply

      The only problem I see is with pagination. Functions like next_posts_link() and previous_posts_link() work directly with the $wp_query and $paged globals so to get them to work one needs to alter the main query.

      • Konstantin Kovshenin 3:31 pm on December 14, 2012 Permalink | Log in to Reply

        That’s easy, just delete 404.php and pagination will work again, haha! How about wasted resources? :)

        • Daniel 3:32 pm on December 14, 2012 Permalink | Log in to Reply

          Is this a joke? 404 HTTP status is triggered in the page headers before templates are loaded.

          • Konstantin Kovshenin 3:35 pm on December 14, 2012 Permalink | Log in to Reply

            Of course it’s a joke, while I’ve seen a few people do it. You should never, never, never use query_posts. Period.

            • scribu 3:40 pm on December 14, 2012 Permalink

              You should never, never, never use query_posts(), unless there’s no better way to do it. That’s why it’s not deprecated in Core, yet.

            • Chip Bennett 4:01 pm on December 14, 2012 Permalink

              @scribu: examples of cases where there is no better way to do something than via query_posts()?

              That’s the paradigm shift I’m struggling with, here.

            • scribu 4:10 pm on December 14, 2012 Permalink

              The exact use-case that query_posts() was designed for: using a custom page template as an archive of posts:

              Just call query_posts() at the very beginning and pretend it’s an arhive. query_posts() takes care of completely replacing the main query and the effect is limited to that custom page template.

              You don’t have to do any workarounds for conditional flags or for pagination.

            • scribu 4:11 pm on December 14, 2012 Permalink

            • Chip Bennett 4:12 pm on December 14, 2012 Permalink

              You don’t have to do any workarounds for conditional flags or for pagination.

              So, pagination works “out of the box” on a custom page template where the default query is stomped by query_posts()?

            • Chip Bennett 4:18 pm on December 14, 2012 Permalink

              Also, I note that even you say that using WP_Query() is the better method for creating secondary loops:

              The new way (better, because it has less side-effects)…

              :)

            • nofearinc 6:05 pm on December 14, 2012 Permalink

              what’s the preferred way to handle pagination though? It’s indeed using the $wp_query global inside of the pagination definition and passing arguments from the outside is a bit odd. There is no valid way to overload the query variable used for the pagination functions.

      • Chip Bennett 3:34 pm on December 14, 2012 Permalink | Log in to Reply

        Isn’t that an argument in *favor* of using pre_get_posts instead of query_posts()? If you alter the main loop query *before* the query is set up, pagination just works.

        • Daniel 3:37 pm on December 14, 2012 Permalink | Log in to Reply

          That works for most cases with one exception I’m aware of: custom page templates. If you want to display a custom loop in a page template you need the main loop unaltered before the template is loaded to make sure the correct one is loaded. Otherwise the function is_page_template( ‘some-template.php ) may not return the correct value.

          • Chip Bennett 3:49 pm on December 14, 2012 Permalink | Log in to Reply

            If you want to display a custom loop in a custom page template, then instantiate a custom query, via new WP_Query().

            Pagination still requires a bit of a work-around, but I would contend that work-around is far less intrusive than what is required to ensure that the main loop query is replaced cleanly.

            • Daniel 4:14 pm on December 14, 2012 Permalink

              The paginate_links() function could be used which accepts custom pagination arguments, and simple prev/next links could be generated by setting all numbered pagination values to 0; though I see that more as a hack rather than a workaround and I wouldn’t like to see it as recommended.

            • Daniel 4:17 pm on December 14, 2012 Permalink

              What I would like to see is functions like next_posts_link() and previous_posts_link() accept query objects as optional parameters. I believe that would be a huge enhancement in core.

    • Edward Caissie 3:36 pm on December 14, 2012 Permalink | Log in to Reply

      I’m not seeing ‘query_posts’ currently mentioned in the guidelines and if that is the case and although use-cases would be rare and still not likely best practice I would say we proceed in our standard method of first RECOMMENDED NOT to use then proceed to REQUIRED NOT to use.

      • Chip Bennett 3:47 pm on December 14, 2012 Permalink | Log in to Reply

        No, query_posts() is not explicitly listed in the Guidelines. But then again, neither are dozens of other functions that we exclude, based on this principle (and similar principles expressed in the guidelines):

        Whether implementing required, recommended, or optional features, Themes are required to support proper WordPress core implementation of all included features.

        My contention is:

        1. Creating secondary loop queries is properly implemented via new WP_Query()
        2. Modifying the main loop query is properly implemented via filtering pre_get_posts.

        • scribu 4:15 pm on December 14, 2012 Permalink | Log in to Reply

          I agree with 1.

          I only partially agree with 2. You can do it, but it’s very easy to mess up, when using pre_get_posts, even if you use is_main_query().

          • Chip Bennett 4:20 pm on December 14, 2012 Permalink | Log in to Reply

            I only partially agree with 2. You can do it, but it’s very easy to mess up, when using pre_get_posts, even if you use is_main_query()

            But what are the vast majority of use cases for modifying the main query in publicly distributed Themes? Changing posts_per_page? Excluding a special/featured category? Something similar? Those are all straight-forward and easy in a pre_get_posts callback.

            • Sergey Biryukov 6:46 am on December 15, 2012 Permalink

              FWIW, $wp_query->is_main_query() returns true in the admin as well.

              So, if a theme exludes a category or alters posts_per_page using a pre_get_posts callback, it should also include an is_admin() check to prevent unintended side effects in the admin.

    • Frumph 5:00 pm on December 14, 2012 Permalink | Log in to Reply

      query_posts is a valid and acceptable method of adding additional loops on your home page; unless something has changed recently that I am not reading here

    • Justin Tadlock 5:35 pm on December 14, 2012 Permalink | Log in to Reply

      query_posts() should only be used in custom page templates designed to be an archive-type page of posts. That’s the only use case I can think of at the moment.

      Most themes shouldn’t have a need to touch the main query anyway. There are some valid reasons for themes to do so, but this is generally plugin territory.

      • Konstantin Kovshenin 5:36 pm on December 14, 2012 Permalink | Log in to Reply

        new WP_Query() + the_post() + wp_reset_postdata() is a good alternative.

        • Ryan Duff 5:58 pm on December 14, 2012 Permalink | Log in to Reply

          Except in cases you intentionally want to stop on $post. It’s an extremely fringe case though.

          • Ryan Duff 6:18 pm on December 14, 2012 Permalink | Log in to Reply

            I’d like to expound on this after I read up to the top… and say that this fringe case is something I’d never see happening in a public theme.

          • Andrew Nacin 8:16 pm on December 17, 2012 Permalink | Log in to Reply

            No, it specifically works for that case. the_post() stomps $post. wp_reset_postdata() restors it.

        • Drew Jaynes (DrewAPicture) 6:00 pm on December 14, 2012 Permalink | Log in to Reply

          +Like

        • nofearinc 6:01 pm on December 14, 2012 Permalink | Log in to Reply

          +1 for that

        • Frumph 6:33 pm on December 14, 2012 Permalink | Log in to Reply

          My understanding is that new WP_Query() adds to the stack overhead while query_posts uses the internal post cache.. makes a big difference, unless i’m mistaken

          • Konstantin Kovshenin 6:36 pm on December 14, 2012 Permalink | Log in to Reply

            Both do the exact same thing, but in addition to that, query_posts() also breaks things and causes kittens to die.

            • Frumph 6:39 pm on December 14, 2012 Permalink

              Hrm. I don’t like kittens dying. ..

            • Konstantin Kovshenin 6:42 pm on December 14, 2012 Permalink

              Just to clarify, there is no overhead because query_posts() is just a wrapper function that calls new WP_Query() so there really is no difference between the two, except the kittens of course.

              When you want to alter the main query, both new WP_Query() and query_posts() are overhead because they both fire secondary queries, when you wanted to alter the main query, in which case you should have used the ‘pre_get_posts’ action or the ‘request’ filter.

            • Frumph 6:47 pm on December 14, 2012 Permalink

              ..so the point in not using query_posts is what? if they’re both the same? .. I mean yeah if it’s the front page and the loop has already fired of course you should use pre_get_posts, but if you have the parser ‘reject’ use of query_posts if it was used as it should as secondary loops, then well .. what then?

            • Konstantin Kovshenin 6:58 pm on December 14, 2012 Permalink

              Frumph: The point is that while query_posts() is just a wrapper for new WP_Query() it also does that in a way that breaks things, which is why avoiding query_posts() and using WP_Query() is safer.

              However, correct me if I’m wrong, but the reason this was brought up is because query_posts() is used in many themes to replace the main loop, so we should educate developers towards pre_get_posts, not secondary loops.

            • Chip Bennett 7:04 pm on December 14, 2012 Permalink

              …use of query_posts if it was used as it should as secondary loops…

              Actually, secondary loops are exactly the wrong reason for using query_posts(). Per the Codex:

              query_posts() is meant for altering the main loop….

              To create secondary listings…try making a new instance of WP_Query or use get_posts().

            • Konstantin Kovshenin 7:08 pm on December 14, 2012 Permalink

              Actually, secondary loops are exactly the wrong reason for using query_posts()

              query_posts() does not alter the main loop. In fact, get_posts(), new WP_Query() and query_posts() do the exact some thing in slightly different ways, so IMO saying query_posts() should be used to alter the main query is completely wrong, because query_posts() is fired after the main query has already been made, unless it’s called in functions.php :)

            • Chip Bennett 7:12 pm on December 14, 2012 Permalink

              query_posts() does not alter the main loop.

              Yes, it does: alter the main Loop – by replacing the query used to generate the data for that loop. :)

              I think that’s probably a semantic difference. The Codex says “alter” (the main Loop); in reality, the correct term is “replace” (the main Loop query. The end result, however, is the same: what gets output in the main Loop has changed.

            • Konstantin Kovshenin 7:14 pm on December 14, 2012 Permalink

              I think that’s probably a semantic difference.

              Exactly, which is why it’s so confusing and should be removed :)

            • Frumph 8:52 pm on December 14, 2012 Permalink

              That should probably be notated over to the codex editors yeah? .. hey whatever happened to our ‘best practices’ page someone was supposed to be working on?

          • Chip Bennett 6:38 pm on December 14, 2012 Permalink | Log in to Reply

            My understanding is that new WP_Query() adds to the stack overhead while query_posts uses the internal post cache.

            Just pass:

            'update_post_meta_cache' => false,
            'update_post_term_cache' => false,

            …as part of your argument array for new WP_Query( $args ) to eliminate that overhead.

            • Andrew Nacin 8:19 pm on December 17, 2012 Permalink

              No, definitely not. All query instances consult the same cache before deciding if additional calls to populate the cache is necessary.

              The flags `update_post_meta_cache`, `update_post_term_cache`, and `cache_results` should be immediate red flags in a theme. Chances are, they are doing it wrong, and trying to avoid one query but generating a bunch in the process (because some operation they are doing does consult meta or term data, even if they don’t realize it).

      • Hirak Santra 6:59 am on December 24, 2012 Permalink | Log in to Reply

        query_posts() can be used not only for custom posts. It can also bring data of a respective page by page_id or page_name.

      • Hirak Santra 7:01 am on December 24, 2012 Permalink | Log in to Reply

        query_posts() can not only bring data of posts page but also it can bring data from a page by page_id or page_name.

    • Chris Olbekson 6:47 pm on December 14, 2012 Permalink | Log in to Reply

      I would agree with the others that `query_posts()` should only be used in a page template that wants to work as an archive. It shouldn’t be used in an archive, header, widget, sidebar etc..

    • Andrew Nacin 8:43 pm on December 17, 2012 Permalink | Log in to Reply

      I went out on the WordCamp “circuit” and educated developers on query_posts() in three different cities. This was a carefully calculated initiative designed to boost developer education and awareness. I specifically gave the talk at three veteran WordCamp cities: Portland on the west coast, New York on the east coast, and in Europe (Netherlands). And, the talks have gotten quite a bit of play online after. The impact has been large.

      And yet, core still does not deprecate query_posts(), even though I added is_main_query() to core while on stage at WordCamp Portland. Why, despite recommending against its use, do we not argue for its alternatives?

      My goal was to focus on education and awareness beyond query_posts(). There are a lot of things WordPress developers do out of force of habit, without understanding what actually goes on under the hood. In the case of query_posts(), this was a particularly bad habit caused by lack of understanding.

      But, pre_get_posts may be the correct solution, but it isn’t a good one. It can break the admin. It can break secondary queries. And, it is not easy for developers to use. For a number of situations, query_posts() is sufficient, despite, in many of those situations, having edge cases. We led with a carrot, but if it tastes awful, is it really fair to continue with the stick? I my book, edge cases where it may not be perfect trumps side effects that break other things.

      I like to think I am very pragmatic when it comes to core’s development. I subscribe to “why walk when you can run” almost as much as the next 20-something, but learning to recognize when to walk instead of running is a major key to my own evolution as a developer of a large open source project. It is often important to let the core development process work at a more deliberate speed.

      So, I am often bearish on the adoption and evolution of newer APIs, and bullish on the deprecation of old ones. I could pushed the deprecation of query_posts() at any time since I first gave the talk in September 2011. That timeline includes three major releases, including one I led. Yet, despite kicking off this education initiative, I haven’t. That, I think, should speak volumes. That is why the theme reviewers should follow core’s lead on this.

    • Toru 5:13 am on March 25, 2013 Permalink | Log in to Reply

      I (or Japanese community while translating…) came a cross that on Codex’s http://codex.wordpress.org/Function_Reference/wp_reset_query
      word “deprecated” is used.

      Deprecated – only use query_posts if absolutely necessary (see query_posts: Caveats)

      I have not been able to follow much of the progress on this topic recently, but I believe Nacin’s above post was the final say for now.
      Can I check that Am I correct? In which case I feel this is very misleading line in Codex.

      Codex’s query_posts entry is however, I think very clear and in agreement with what has been discussed in this thread.

      Thanks.

  • Chip Bennett 6:40 pm on November 26, 2012 Permalink | Log in to leave a Comment
    Tags:   

    WordPress 3.5 Guidelines Revisions 

    It is that time of year again: with the upcoming release of WordPress 3.5, the Theme Review Team conducts its periodic review of the Theme Review Guidelines, and proposes any changes, either as necessitated by the new WordPress version, or otherwise as-needed.

    The 3.5 release has little impact on Themes, and as such will be mostly invisible to Theme developers. One minor change will be support for HiDPI (i.e. “Retina”) screenshots. If there are any other 3.5-related changes that we need to account for, please post in the comments.

    Here is the starting point for the discussion regarding changes to the Guidelines:

    • Change Theme Screenshot (screenshot.png) maximum dimensions from 300x225px to 600x450px. (Fixed per comment below)
    • New guideline under presentation-vs-functionality: Themes must not bundle custom post-content shortcodes
    • Change guideline: reduce criticality for Content Sidebar feature from required to recommended. (Themes would still be required to implement core Settings API if Theme incorporates content sidebar feature.)
    • Change criticality of add_theme_support( ‘automatic-feed-links’ ) from required to recommended. (Modified per comments below)

    Please discuss in the comments, and recommend any additions or changes to these proposed Guidelines revisions.

     
    • Andrew Nacin 6:45 pm on November 26, 2012 Permalink | Log in to Reply

      Could you explain the reasoning behind automatic-feed-links?

      • Chip Bennett 6:49 pm on November 26, 2012 Permalink | Log in to Reply

        Sure. I have no particular preference one way or the other. That one is there for discussion, primarily.

        It was suggested to me – and I would tend to agree – that inclusion of RSS feed links is a) not exactly *presentational*, and b) easily enabled via Plugin. So, I’m throwing it out there for the Theme developer community to discuss and to decide. That way, we’ve documented our reasoning for keeping it or removing it.

        • Andrew Nacin 7:15 pm on November 26, 2012 Permalink | Log in to Reply

          I need to do some research to verify my recollection here, but as far as I know, the only reason why it is a theme-support thing is because prior to that line of code, themes would add them into header.php directly. This would cause a double-up. If it weren’t for that, we never would have had the opt-in, and we’d just always do it. I’m game for revisiting this in the future, but I think it makes sense for themes to continue to add the line.

          • Chip Bennett 7:18 pm on November 26, 2012 Permalink | Log in to Reply

            I would consider header RSS feed links to be analogous to the WP version generator and other similar meta data. I’m sure you’re right about the reasoning behind the add_theme_support() implementation. Perhaps a criticality bump from *required* to *recommended* (or *optional*), to help make the point that this functionality lies very close to the presentation-vs-functionality line?

            • Samuel Wood (Otto) 7:53 pm on November 26, 2012 Permalink

              I would say that you could put this in the category of if you use them, then you must use them correctly by using the theme support bit instead of putting them in the header.php manually yourself. But we would definitely say that using automatic-feed-links is recommended.

              I would also say that it is definitely not plugin territory. If anything, core should be doing it automatically, all the time, period. However, because themes traditionally used hard-coded feed links, there was no way to do that and be backwards compatible.

            • Samuel Wood (Otto) 7:55 pm on November 26, 2012 Permalink

              In other words, ban hardcoded RSS links in theme headers, and require use of automatic-feed-links for themes that add feed links (which, IMO, should be all of them).

            • Chip Bennett 8:17 pm on November 26, 2012 Permalink

              I’m with you, Otto. I don’t think anyone is advocating *prohibiting* automatic feed links; but rather more like what you said: adding feed links is *recommended*, *must not* hard-code feed links, and if adding feed links, *required* to use add_theme_support().

            • Vicky Arulsingam 1:03 am on November 27, 2012 Permalink

              I’d prefer it be bumped down to recommended.

              If a user has a plugin for this feature and feed links are added in the theme, would this result in the links being displayed twice?
              If this is the case then a recommendation/requirement to perform a ‘current_theme_supports’ check would be helpful

            • Andrew Nacin 2:49 am on November 27, 2012 Permalink

              They should remain required. Think about it this way: The theme *must not* hard-code feed links, and the theme *must* tell core that they are not hard-coding feed links. That’s really the only meaning of automatic-feed-links.

            • Samuel Wood (Otto) 2:49 am on November 27, 2012 Permalink

              Vicky: If both the theme and the plugin are using automatic-feed-links, then no, they would not be added twice.

            • toscho 11:19 am on November 27, 2012 Permalink

              Core should ask for opt-out and apply the feed links automatically. Legacy themes should not force theme authors to use non-presentational functions in their new themes.

            • Edward Caissie 3:19 pm on November 27, 2012 Permalink

              Quoting Otto:

              I would say that you could put this in the category of if you use them, then you must use them correctly by using the theme support bit instead of putting them in the header.php manually yourself. But we would definitely say that using automatic-feed-links is recommended.

              I agree this is the best method going forward on the implementation of automatic-feed-links

      • mrwweb 7:05 pm on November 26, 2012 Permalink | Log in to Reply

        I moved automatic-feed-links to my functionality plugin a year ago for this reason. If a site needs them, they shouldn’t disappear and reappear depending on the theme.

    • Chip Bennett 7:13 pm on November 26, 2012 Permalink | Log in to Reply

      Other things I’d like to discuss:

      • Timing for making do_settings_sections() required (as opposed merely to recommended) as part of Settings API implementation
      • Removing public-facing credit links, or making them follow Plugin rules: user-configurable, and disabled by default
      • Reformatting the Guidelines as a checklist (either replacing the existing Guidelines entirely, or creating a companion tool to aid reviews)
      • Ian Stewart 7:54 pm on November 26, 2012 Permalink | Log in to Reply

        Removing public-facing credit links, or making them follow Plugin rules: user-configurable, and disabled by default

        Can you elaborate on some of the reasoning behind this?

        • Chip Bennett 8:07 pm on November 26, 2012 Permalink | Log in to Reply

          I’m curious what the Theme developer community thinks about the idea. I think that there is an argument to be made that the negatives far outweigh the positives with respect to displayed-by-default footer credit links. It attracts an inordinate share of of Bad Things, and leads to an inordinately high number of headaches for reviewers and developers alike, under the false premise that such footer credit links help developers’ SEO.

          Obviously, there *is* real benefit to be gained, through actual humans seeing and following those links, but I have long-questioned whether that benefit outweighs the volume of crud Themes that get submitted solely in an attempt to spread footer credit links.

          I’m really just interested in finding out if the Theme developer community would be even partially amenable to the idea, or if it’s something that remains completely off the table for discussion.

          • Emil Uzelac 8:24 pm on November 26, 2012 Permalink | Log in to Reply

            As developer and TRT admin I strongly believe that this is not necessary. Credit Links are the “connection” between the site and the author and many of us here are making a living out of that.

            • Chip Bennett 8:41 pm on November 26, 2012 Permalink

              Agreed, and I don’t want to give the idea of wanting to throw the proverbial baby out with the bath water.

          • CyberChimps 1:16 am on November 27, 2012 Permalink | Log in to Reply

            I think it is a good thing that we are not letting themes into the repo that were submitted on the premise of generating SEO. If we remove the credit links we will be punishing honest authors, and lose the ability to spot the spammers more quickly. It is a lose-lose situation.

            The rules do not matter to spammers, there will always be spam submissions no matter what the rules are we shouldn’t punish honest authors from having a connection to their work.

          • Edward Caissie 3:30 pm on November 27, 2012 Permalink | Log in to Reply

            I would say we leave the credit links in, as is.

            My concerns are not so much in the continued efforts of spammers trying to “game the system” but more so for the developers and designers who may lose interest in updating and/or submitting new themes to the repository without any credit for their works.

            An option to “turn off” credits may be feasible, or even something to be suggested, but I would never get to the point of it being recommended.

            If “Code is Poetry”, how can you expect the poet to not openly sign their work?

        • Ian Stewart 8:18 pm on November 26, 2012 Permalink | Log in to Reply

          I think it’s an interesting idea. My two cents: I think an option is too much cruft for a problem that doesn’t really affect the user and that not allowing public facing credits will probably discourage submissions from designers — especially ones that aren’t quite aware that a theme developer community exists. I don’t think designers do it for the SEOs. I just think it’s natural for them to want to put a credit line on their work in the same way that an artist naturally tends to sign their work.

          • Ian Stewart 8:21 pm on November 26, 2012 Permalink | Log in to Reply

            I don’t think designers do it for the SEOs

            Though obviously some spammers with not-the-best themes are. :)

          • Chip Bennett 8:22 pm on November 26, 2012 Permalink | Log in to Reply

            Is there a way to provide the benefit (which is certainly deserved), without attracting the bad?

            • Ian Stewart 8:34 pm on November 26, 2012 Permalink

              Probably not.

            • Chip Bennett 8:36 pm on November 26, 2012 Permalink

              Is it something worth further consideration, to try to come up with a better alternative, or is it just something that we just have to continue to deal with, because it can’t be fixed?

            • Ian Stewart 8:40 pm on November 26, 2012 Permalink

              There may be some way to make it easier to spot/flag these themes beforehand (automatically diffing against the default themes and coming up with a percentage that flags a theme? Flagging first time themers that have some sort of commonality to theme?). I can’t think of any alternatives to it beyond getting better at spotting the bad guys and just dealing with the fact that there are bad guys.

            • Ian Stewart 8:41 pm on November 26, 2012 Permalink

              … sort of commonality to theme?

              s/theme/them

              For some reason that’s a common spelling mistake with me.

            • Chip Bennett 8:49 pm on November 26, 2012 Permalink

              I often “audit” the Priority #4 queue, for just this sort of review. I look for spammy/inappropriate credit links and landing pages, and obvious knock-offs of known Themes.

              Honestly, child Theme support helps greatly in this regard, since we can spot Twenty Ten and Twenty Eleven derivatives, and require them to be resubmitted as proper child Themes. That’s helped cut down on a good bit of the knock-off Themes. But a lot of the pattern recognition you describe is purely manual, and requires familiarity with Themes prone to being forked.

            • Emil Uzelac 9:29 pm on November 26, 2012 Permalink

              We can reduce the numbers from 4 priorities to only 2. #1 Previously Approved and #2 All others, this way the process would be much faster and we can “scan” for SPAM easier. Does that make sense?

          • Philip Arthur Moore 12:13 am on November 27, 2012 Permalink | Log in to Reply

            Big +1.

        • Daniel 8:40 am on November 27, 2012 Permalink | Log in to Reply

          I have a bad feeling an unintended consequence of this would be many developers not updating theor themes anymore to circumvent this guideline.

        • Konstantin Kovshenin 11:19 am on November 27, 2012 Permalink | Log in to Reply

          Will adding “nofollow” to such links help avoid the “Bad Things”? If it does we can make it a recommendation or even a requirement.

      • Ian Stewart 7:54 pm on November 26, 2012 Permalink | Log in to Reply

        Reformatting the Guidelines as a checklist (either replacing the existing Guidelines entirely, or creating a companion tool to aid reviews)

        I think this is a great idea.

      • kwight 8:08 pm on November 26, 2012 Permalink | Log in to Reply

        I’ve volunteered to help the Documentation team with the Theme Review handbook: http://make.wordpress.org/updates/2012/11/20/docs-team-intro/#comment-22

        I’m a little unclear as to how this relates to the current posted Guidelines; I’m hoping the handbook eventually /becomes/ the posted guidelines. Is this what you’re referring to, or are you suggesting an interim step?

        • Chip Bennett 8:10 pm on November 26, 2012 Permalink | Log in to Reply

          As I understand it, the Theme Review Handbook is more intended to be a “how to get involved with the Theme Review Team” kind of thing?

          • kwight 8:24 pm on November 26, 2012 Permalink | Log in to Reply

            Ah, perhaps I’ve misunderstood; so the Handbook is more of an onboarding tool, while the Guidelines exist separately in the Codex?.. Either way, I’m in, the current format could certainly be improved.

            I think it would be more effective for each guideline to have a What Why How approach: “What” is the guideline, “Why” is it required/recommended, and “How” is it implemented (actual code example). I think it would reduce a lot of confusion both for reviewers and submitters.

            • Chip Bennett 8:27 pm on November 26, 2012 Permalink

              I like that approach; the problem is that the Codex doesn’t necessarily present the best means to implement such an approach. We would have to have separate entries for the Guidelines themselves (essentially what we have now), and for the What/Why/How information; otherwise, it would be even *more* difficult for new Reviewers to read/parse the Guidelines.

              But, I am absolutely in favor of providing more code examples, wherever we can.

            • kwight 8:51 pm on November 26, 2012 Permalink

              True; in my fancy designer head, each of the What Why How would be a tab for each guideline, but AFAIK, that’s not possible with the Codex. If only the Codex was WordPress :|

              The best thing I guess, could be having a “more detail” link for each guideline that goes to a more lengthy What Why How page, with code examples.

    • Ian Stewart 7:41 pm on November 26, 2012 Permalink | Log in to Reply

      Change guideline: reduce criticality for Content Sidebar feature from required to recommended. (Themes would still be required to implement core Settings API if Theme incorporates content sidebar feature.)

      Could explain this one a bit more? I’m not quite clear what it refers to.

      • Chip Bennett 7:48 pm on November 26, 2012 Permalink | Log in to Reply

        In other words: Themes don’t *have* to include dynamic-content sidebars (whether as a traditional sidebar, or a footer sidebar, etc.) .

        This came out of a discussion about Appearance -> Widgets no longer displaying if Themes don’t call register_sidebar(). Dynamic Sidebars would thus be treated as analogous with Custom Backgrounds or Custom Header Images.

      • Ian Stewart 7:49 pm on November 26, 2012 Permalink | Log in to Reply

        Awesome. Thanks.

      • kwight 8:11 pm on November 26, 2012 Permalink | Log in to Reply

        +1. It would be great (particularly for stripped-down/minimalist themes) to not be forced in to implementing widget areas.

      • Danielx64 3:57 am on January 24, 2013 Permalink | Log in to Reply

        -1 for the sidebar removal, like I said on the mailing list, I wouldn’t be happy to download a theme only to find out that it doesn’t support widgets.

    • kwight 7:57 pm on November 26, 2012 Permalink | Log in to Reply

      Ack! I already changed the guidelines re: screenshots, after noticing the new hiDPI screenshot for Twenty Twelve works in 3.4.2. Since it’s stating a maximum, would be a problem keeping it like that unless something comes up?.. Let me know if I’ve really jumped the gun, I’ll set it back.

    • shawn 8:09 pm on November 26, 2012 Permalink | Log in to Reply

      New guideline under presentation-vs-functionality – anyplace I can get more info on these guidelines

    • shawn 8:11 pm on November 26, 2012 Permalink | Log in to Reply

      New guideline under presentation-vs-functionality: Themes must not bundle custom post-content shortcodes

      Any place I can get more info on this???

      • Chip Bennett 8:16 pm on November 26, 2012 Permalink | Log in to Reply

        What sort of information are you looking for? This is probably the best place to get it. :)

        • shawn 8:38 pm on November 26, 2012 Permalink | Log in to Reply

          Are we talking just shortcode(s) or any custom post content code….

          A clearer definition of presentation vs functionality guidelines standard for either themes or plugins in WP are not exactly up to common PHP standards. I would love to know what exactly the guidelines are.

          • Chip Bennett 8:45 pm on November 26, 2012 Permalink | Log in to Reply

            Are we talking just shortcode(s) or any custom post content code

            What other post-content code do you have in mind? As a general rule, if you’re manipulating post content in any way other than presentationally, that manipulation probably belongs in a Plugin.

            A clearer definition of presentation vs functionality

            In some regards, that is the million-dollar question. But for the purposes of Themes, 99% of the time it isn’t difficult to determine whether something is functional or presentational.

            Do you have any specific examples where you’re unclear about whether something is one or the other?

            • Sayontan Sinha 9:13 pm on November 26, 2012 Permalink

              Themes that are framework-based (like Hybrid) have a lot of bundled shortcodes. Are those acceptable? What exactly differentiates a “custom post-content” shortcode from a regular shortcode?

              Along the lines of the Hybrid question, is it acceptable if the author provides a shortcodes plugin which is simultaneously offered with the theme (I do so, mainly to help users transition out of the theme without impact).

            • shawn 12:36 am on November 27, 2012 Permalink

              Most of my custom post-content runs from generic class located in a theme plugin toolkit, themes decided what is run, when, on a case by case basis, this allow me to customize post types based on the needs the theme.

              The problem with this method as far as I am aware is that themes with dependencies like these cannot function in the theme repository, now that it is policy, has this changed?

              Do you have any specific examples where you’re unclear about whether something is one or the other?

              I am unclear about everything here, since most theme developers already separate presentation from functionality what I see happening is the creation of another theme dependency and I not sure I like it.

            • shawn 2:23 am on November 27, 2012 Permalink

              Since the purpose of Themes is to define the presentation of user content, Themes must not be used to define the generation of user content, or to define Theme-independent site options or functionality.

              Sorry if I sound confused but this new guideline completely caught me off guard, theme dev/designers agreed to this???

            • Chip Bennett 2:28 am on November 27, 2012 Permalink

              The presentation-vs-functionality criterion is not a new guideline. It has been an operating principle since the beginning of the Theme Review Team’s efforts.

              What part of it do you disagree with?

            • Chip Bennett 2:30 am on November 27, 2012 Permalink

              Themes that are framework-based (like Hybrid) have a lot of bundled shortcodes. Are those acceptable? What exactly differentiates a “custom post-content” shortcode from a regular shortcode?

              As far as I’m aware, Hybrid does not bundle post-content shortcodes, but rather uses a custom shortcode for user configuration of footer text, etc. Such “shortcodes” are perfectly acceptable.

              The differentiation is post-content. If the shortcode is used in the post content – i.e. if it is added by the user to the post content editor, such as or [ref] or [two-columns] – then it belongs in a Plugin rather than in the Theme.

            • Sayontan Sinha 6:09 am on November 27, 2012 Permalink

              As far as I’m aware, Hybrid does not bundle post-content shortcodes, but rather uses a custom shortcode for user configuration of footer text, etc. Such “shortcodes” are perfectly acceptable.

              The shortcodes that come with Hybrid are entry-title, entry-author, entry-terms and several others, which to me seem very much like post-content shortcodes. These are by design to be run where the global $post is available. Where else would you invoke these if not in the post content? Hybrid has a host of other shortcodes that can be used in comments.

              So if this is made a requirement, then all themes that have such existing shortcodes have to pull them from the theme, risking sites breaking as as a result.

              I see no reason for any Theme ever to bundle post-content shortcodes.

              Except that, as I mentioned, several themes already include them, and they are in very heavy use. Trying to cull the shortcodes from such themes will only result in frustration for the users of the themes. I thought the aim of the theme review team is to make things easy for users, while disallowing what already exists only serves the opposite purpose.

              Of course, one way could be to disallow new shortcodes, but forcing theme authors to remove every existing post content shortcode is going to the extreme.

            • Chip Bennett 12:49 pm on November 27, 2012 Permalink

              The shortcodes that come with Hybrid are entry-title, entry-author, entry-terms and several others, which to me seem very much like post-content shortcodes.

              Those sound like template shortcodes to me. Key point: where does the user use those shortcodes: in the Visual/Text post editor, or elsewhere?

              These are by design to be run where the global $post is available. Where else would you invoke these if not in the post content?

              You are misunderstanding “post-content” shortcodes. A “post-content” shortcode is one that the user places in the post Visual/Text editor, that lives in the database in $post->post_content, and that is parsed by do_shortcode() upon display.

              Hybrid has a host of other shortcodes that can be used in comments.

              And Justin explicitly says that the Theme’s shortcodes are not intended to be used in the post content:: “These shortcodes are not meant to be used with the post content editor. Their purpose is to make it easier for users to filter hooks without having to know too much PHP code and to provide access to specific functionality in other (non-post content) shortcode-aware areas.

            • shawn 2:49 pm on November 27, 2012 Permalink

              What part of it do you disagree with?

              Practically all of it, with so much discussion and advances in development and understanding of UI/UX, to state the the purpose of a theme is to define the presentation of user content is shallow at best. What even worse is the intent of the statement (Themes must not used to…).

              Simply change a couple words in the statements purpose to read

              Since the purpose of Themes are to define how users interact with a websites content…

              We are having a different discussion about the rule(s) of what themes should be used for, presentation now becomes functional as functionality, as it should be is now defined by the theme!

              New old or whatever this is just sooooo wrong Chip!

            • Chip Bennett 2:56 pm on November 27, 2012 Permalink

              with so much discussion and advances in development and understanding of UI/UX, to state the the purpose of a theme is to define the presentation of user content is shallow at best.

              No. That is precisely the purpose of a Theme. WordPress is designed such that the Theme is the content presentation abstraction layer.

              What even worse is the intent of the statement (Themes must not used to…).

              Simply change a couple words in the statements purpose to read

              Since the purpose of Themes are to define how users interact with a websites content…

              We are having a different discussion about the rule(s) of what themes should be used for, presentation now becomes functional as functionality, as it should be is now defined by the theme!

              Perhaps it would be helpful to shift your paradigm from functionality to content. Properly designed Themes will support most functionality out-of-the-box.

              Asked a different way: what functionality do you think Themes should be defining?

            • Sayontan Sinha 10:34 pm on November 27, 2012 Permalink

              And Justin explicitly says that…

              So in summary it is okay to state something like “Don’t use these in your post content” in the comments, but it is not okay to state, “If you decide to stop using this theme you can use this alternative plugin”.

              The point that I have been trying to get you to see is that there are active themes with huge user-bases that have shortcodes built in them. Some theme authors actively try to make the transition out of their themes painless by providing plugins for various modules. Forcing them to pull the shortcodes out will affect a LOT of users. If this isn’t sufficient for getting an exception on existing themes with existing shortcodes, I don’t know what is.

            • Frank Klein 11:34 pm on November 27, 2012 Permalink

              As a general rule, if you’re manipulating post content in any way other than presentationally, that manipulation probably belongs in a Plugin.

              Exactly. I can see why this new proposed guideline is controversial, since a lot of developers think of themes as “website packages”, that bundle a very custom design with the necessary functionality – custom post types, short codes, etc. But the sole fact that this is practiced by a lot of themes shouldn’t matter for putting a guideline in place for future themes.

              I wonder how many of the heavy shortcode users will get the shock of their life when they switch themes and suddenly all their posts are littered with shortcodes that no longer work.

              It seems to me that most users don’t care about what comes with a theme and what comes with a plugin, all they care about is that it is there. So as developers we should make their life easier by allowing them to switch themes freely without losing any functionality.

              It isn’t that difficult to point users to the right plugin that adds the desired functionality to a theme. If someone is smart enough to use shortcodes, then he will get this too.

              Besides I hope that this will lead developers towards leveraging more existing plugins.S o instead of whipping up your own crappy SEO optimization code in functions.php, why not simply point users toward a great plugin like WordPress SEO? How different can the functionality of your portofolio post type be from that offered by Justin’s plugin?

              Relying on production-hardened, specialized plugins instead of cooking up your own is the way of the future. Not only will this free up time for theme developers so that they can focus on building the best theme possible, but it also over time improve portability and establish de facto standards.

            • shawn 3:58 pm on November 28, 2012 Permalink

            • Justin Tadlock 5:35 pm on November 29, 2012 Permalink

              Just a note about Hybrid Core: Its shortcodes are intended for use in templates. This is stated in the file listing the shortcodes as well as in my theme documentation on my site. Most users aren’t even aware that there are shortcodes in the themes because they are not advertised as a feature. Basically, to even know the shortcodes exist, you must read the notice that they’re not to be used in the post content.

              With that said, I do have some ideas about de-registering the shortcodes specifically when the_content() is called just to outright avoid any potential issues. Not once have I had an issue with this from my users though.

      • kwight 8:31 pm on November 26, 2012 Permalink | Log in to Reply

        Content shortcodes should be plugin territory, so that users don’t lose the shortcode functionality when changing themes.

        • Rizqy Hidayat 3:30 am on November 27, 2012 Permalink | Log in to Reply

          So what ‘s the actual meaning of *content shortcodes*? is it shortcodes in the editor or somekind like what?

          • Chip Bennett 12:51 pm on November 27, 2012 Permalink | Log in to Reply

            Yes: a “post-content” shortcode is a code that the user places in the post content, via the post Visual/Text editor. Shortcodes used elsewhere in the template are fine, because they don’t affect user content upon switching Themes; they’re merely Theme customizations.

      • Sami Keijonen 6:53 am on November 27, 2012 Permalink | Log in to Reply

        What comes to Hybrid Core shortcodes, they are only used in template files. Never in post editor. There is a big difference for me at least.

        • Sayontan Sinha 6:06 pm on November 27, 2012 Permalink | Log in to Reply

          Do you mean “they are only used” or do you mean “they are only *supposed* to be used”? I don’t believe there is anything preventing a user from going ahead and using these shortcodes in the post content.

          • Sami Keijonen 9:39 pm on November 27, 2012 Permalink | Log in to Reply

            Basic, non developer user don’t even know these shortcodes exists. And there haven’t been any question about using them in post content in themehybrid support forum or having problems when changing theme. Chip already pointed out all the others aspects about “post-content” shortcodes.

            But yes you can use them in post content like any other shortcode.

          • Chip Bennett 10:08 pm on November 27, 2012 Permalink | Log in to Reply

            Intended use is what matters here. The shortcodes included with Hybrid are not intended to be used in the post content. End users can do myriad things with any Theme outside of the developer’s intent; such is not our concern (see: software freedoms).

            • Sayontan Sinha 10:53 pm on November 27, 2012 Permalink

              Basic, non developer user don’t even know these shortcodes exists. And there haven’t been any question about using them in post content in themehybrid support forum or having problems when changing theme.

              This argument can be made for any theme. Bear in mind that I am not suggesting that the shortcodes be removed. I am merely saying that shortcodes either don’t matter to users at all because they aren’t aware of them, or the users make fully conscious decisions to use them.

              End users can do myriad things with any Theme outside of the developer’s intent; such is not our concern

              If that is the case, then a simple disclaimer somewhere (like the options panel) should suffice, telling users that some shortcodes are distributed with the theme and that if the users use those shortcodes they run a risk of a lock-in. After all, that takes care of the theme author’s intention. Maybe this could even be built into the core: the way it states on the themes page that a theme uses widgets, there could be something to state that a theme uses shortcodes.

              Not to belabour my point, but nobody seems to be getting that there are themes out there that have shortcodes in active use. Pulling the plug on the shortcodes simply leaves all users of such features in the lurch. And not allowing shortcodes even if there is a separate plugin offering all of them seems even more counter-intuitive.

            • Chip Bennett 11:37 pm on November 27, 2012 Permalink

              …or the users make fully conscious decisions to use them.

              I question whether such decisions are truly “fully conscious”; I don’t think most users realize what will happen to their post content if and when they switch Themes.

              Not to belabour my point, but nobody seems to be getting that there are themes out there that have shortcodes in active use. Pulling the plug on the shortcodes simply leaves all users of such features in the lurch.

              Of course we know that there are approved Themes that bundle shortcodes. Changing the Guideline doesn’t mean that those Themes are suddenly going to get suspended or anything. (Our aim is to *improve*, not to *degrade*, the user experience.) But that doesn’t mean that we shouldn’t or can’t say, “henceforth, no more.”

              And not allowing shortcodes even if there is a separate plugin offering all of them seems even more counter-intuitive.

              I don’t think there is any need to “grandfather” Themes that currently have shortcodes. I don’t see any problem with providing a transition for existing Themes with shortcodes. In your next update, make them pluggable in your Theme, and instruct users to install/activate the Plugin. Then in the subsequent update, you can safely remove them from your Theme.

            • Sayontan Sinha 11:57 pm on November 27, 2012 Permalink

              I question whether such decisions are truly “fully conscious”; I don’t think most users realize what will happen to their post content if and when they switch Themes.

              Themes are supposed to prefix their custom functions with a slug. I have always extended this to mean that their custom shortcodes should be prefixed with a slug. At least that is what I have practised always and I have even made a suggestion to this effect on the WPTRT list. If that is the case, using a shortcode from the theme becomes a very conscious choice, particularly since there is no UI provided to insert the shortcode.

              In your next update, make them pluggable in your Theme, and instruct users to install/activate the Plugin. Then in the subsequent update, you can safely remove them from your Theme.

              You are assuming that all users upgrade whenever a new version is available. I am pretty sure that there are several users who skip 5-6 versions before upgrading even if a theme is stable and from an active developer (I have even seen instances where people wait several months before upgrading).

              Regardless, if a rule is being set, there should be clear cut distinctions in the review guidelines between what is a permissible shortcode vs. what isn’t, with specific examples. Very often with other vague requirements I have had to go back and forth with a reviewer because his/her interpretation didn’t match mine.

            • Chip Bennett 12:25 am on November 28, 2012 Permalink

              If that is the case, using a shortcode from the theme becomes a very conscious choice, particularly since there is no UI provided to insert the shortcode.

              That still doesn’t make it a “fully conscious” choice, unless the user has been explicitly told “your post content will not display properly if you switch Themes”.

              You are assuming that all users upgrade whenever a new version is available.

              As a matter of principle, we do not facilitate users who choose not to keep their core, Theme, and or Plugin code current. Users are fully within their rights not to update, but that doesn’t mean we must accommodate that decision.

              Regardless, if a rule is being set, there should be clear cut distinctions in the review guidelines between what is a permissible shortcode vs. what isn’t…

              I’m not sure how much more explicit we can be with respect to shortcodes.

              If the Theme instructs or implies to users that bundled shortcodes are to be used in the post content, they are not allowed. If the shortcodes are intended to be used for other purposes (extending the Theme via hooks, or for user-configuration of template elements, etc., then they are allowed.

            • Sayontan Sinha 1:24 am on November 28, 2012 Permalink

              That still doesn’t make it a “fully conscious” choice, unless the user has been explicitly told “your post content will not display properly if you switch Themes”.

              I disagree. Regardless, I did make recommendations for this on this very thread:

              1. Make the users specify explicitly in their options page or in the readme.txt file that the shortcodes are not portable. You take your pick where you want them to specify this.
              2. Or make a modification to the core to show that a theme is defining shortcodes in the Appearance → Themes page. I am willing to write a patch if if this has takers, because that way it will not matter where a user has got a theme – the message will give the user fair warning even if the theme author hasn’t put it in.

              I’m not sure how much more explicit we can be with respect to shortcodes.

              Sorry, but this is not at explicit from any point of view:

              Themes must not bundle custom post-content shortcodes

              It makes no effort to define what a post-content shortcode is and to say that it leaves itself open to misinterpretation is an understatement. To me something like entry-title is a post-content shortcode, simply because it is defined in the context of a post. But you interpret this differently. I have multiple shortcodes of this sort, which if I went with my definition, I would have to pull from the theme, but based on your description they are fine because most of them don’t need to be executed in a post’s content.

              You could consider appending your own text from the above to the messaging:

              If the Theme instructs or implies to users that bundled shortcodes are to be used in the post content, they are not allowed. If the shortcodes are intended to be used for other purposes (extending the Theme via hooks, or for user-configuration of template elements, etc., then they are allowed.

            • Chip Bennett 2:31 am on November 28, 2012 Permalink

              You could consider appending your own text from the above to the messaging

              Oh, I certainly will.

              In case it hasn’t been apparent, I do try to go back to the OP and update the list based on the outcome of discussion in the comments. But, I try to wait until some consensus becomes clear, or until all questions have been answered regarding clarity/intent/etc. (For example, I think it would be more clear to refer to $post->post_content or the_content() rather than “post-content”, to indicate the shortcodes to which the guideline will apply.) I just want to make sure everything is clear before I edit the OP.

      • shawn 3:50 pm on November 28, 2012 Permalink | Log in to Reply

        Perhaps it would be helpful to shift your paradigm from functionality to content. Properly designed Themes will support most functionality out-of-the-box.

        Asked a different way: what functionality do you think Themes should be defining?

        I think we should all shift our paradigm not to content but its content usability and consumption, realizing that themes are more that just a presentation layer but the UI, disseminating and distributing content.

        The role of the theme while understated by its definition in the rule is very important to not only the success of the application but the site it powers. Themes should therefore be able define all “non out of the box” functionality or at least have a role in saying how it affects functionality of the theme.

        No. That is precisely the purpose of a Theme. WordPress is designed such that the Theme is the content presentation abstraction layer.

        That maybe so, but the design and implementation of the layer is functional and requires functionality. What abstraction does is hide that functionality from the end user, attempt to remove then the applications becomes static, useless.

        The problem I am having is that WordPress has now officially separated presentation from functionality, so the installation of a WP blog / site is becoming more and more windows-esque Drivers (plugins) Required, taking 100 year (computer years) step backwards.

        Look I get the problem mixing design and code is bad, but lets fix it the standard way by encouraging devs to separate design from data and code and not by penalizing theme dev/designers for their innovation!

        • Chip Bennett 4:21 pm on November 28, 2012 Permalink | Log in to Reply

          Shawn, that is a discussion, and a paradigm shift, that is far outside the scope of this periodic guidelines review process. Such a shift would fundamentally alter the underlying principles of the guidelines, and not something that we’re going to consider as part of this exercise.

          If you do feel passionately enough about it, though, I would recommend starting a discussion on the Theme-Reviewers mail-list, where the discussion can be given a more full and proper treatment.

          • shawn 5:20 pm on November 28, 2012 Permalink | Log in to Reply

            I not sure I understand why, if a guideline is fundamentally flawed it should be automatically reviewed or at least redefined.

            You simply cannot separate presentation from functionality, it would be like trying to create a graph without the data.

          • Chip Bennett 5:27 pm on November 28, 2012 Permalink | Log in to Reply

            I disagree that the presentation-vs-functionality guideline is “fundamentally flawed”. Again: if you do feel passionately about the matter, please start a discussion on the Theme-Reviewers mail-list, and we can discuss it at length, with all interested parties.

            • shawn 5:48 pm on November 28, 2012 Permalink

              I will seriously consider putting aside some time for it!

              Thanks for your time and patience Chip.

      • wpweaver 6:51 am on December 1, 2012 Permalink | Log in to Reply

        I missed the start of this discussion, but I do have a few thoughts on this. My theme, Weaver II, does indeed include a quite a few shortcodes, and certainly some of them could be unbundled and put into a plugin.

        But at least two of them, and they are both heavily used by my theme’s users, really would not work outside the context of the theme’s support framework. One is almost an integral part of how users can present content – a show post shortcode. The main reason it can’t go outside of the theme is that it relies on theme settings and display functions to format posts – picking up all the theme local layouts, how to display post information, etc. It truly is integrated with theme design. One could remove it to a plugin, but that plugin would only work when integrated to the theme.

        The other is a shortcode to conditionally display content depending on the if the view is mobile. While my theme is fully responsive, it also can dispay things differently depending on the user agent – so it is really more than responsive. How does one separate the plugin from the mobile display model of the theme? Even if using just the responsive parts, there are still theme settings to determine when various display items switch.

        And as been mentioned before, updating an existing theme that had been forced to eliminate included shortcodes, would mean that literally tens of thousands of sites would instantly be broken upon update.

        I do appreciate the goal of switching theme and having things still work. But my theme does things that no other themes can do, and part of the capability is to provide an integrated environment for the site developer.

        So – I think there needs to be some kind of grandfathering of existing themes. It just would not be reasonable for thousands of existing sites to break just to enforce a rule.

        One possible aid to solving the theme switch problem would be to require themes with built-in content side shortcodes to provide some kind of plugin that provided near-equivalent functionality upon theme switch. This might be difficult in some cases (e.g., my post shortcode or conditional display on mobile devices), but I suppose one could come close. I’ve even had this on my development list to help my own users who might want to switch.

        And not to shoot myself in the foot, but what about Page Templates? My experience is that switching themes that don’t have similar page templates is actually harder than some shortcodes.

        But at the heart of it, I still believe that there is room in the free repository for higher level themes that represent more of a complete environment that includes tightly integrated widgets, page templates, and shortcodes. Not every user is ready to develop their own child-theme, or spend hours hunting through plugins to find the functionality that fits just right with some theme – if they can add their own CSS rules to make the plugin’s styling consistent with the rest of the theme.

        • Chip Bennett 11:58 pm on December 1, 2012 Permalink | Log in to Reply

          Given that Weaver already has an associated Plugin, I don’t see any reason that the bundled shortcodes can’t easily be shunted off to that Plugin. In any case, there are other ways to implement a “show_posts” shortcode (which is really just a wrapper for a custom WP_Query() call) in a custom page template) than having users put the shortcode in $post->post_content.

    • Philip Arthur Moore 12:09 am on November 27, 2012 Permalink | Log in to Reply

      Change Theme Screenshot (screenshot.png) maximum dimensions from 300x225px to 600x480px.

      Should this read 600x450px?

    • Vicky Arulsingam 12:59 am on November 27, 2012 Permalink | Log in to Reply

      Shouldn’t custom post types fall under the “presentation-vs-functionality” rule?

      In terms of exceptions, if the theme author provides a plugin for shortcode/custom post type functionality, is that acceptable?

      • Chip Bennett 2:25 am on November 27, 2012 Permalink | Log in to Reply

        CPTs are a separate discussion, and are already handled by the “special use-case” Theme exception.

        If shortcodes can be placed in a Plugin, and the user directed to install the Plugin if/when he switches away from the Theme, then why not short-circuit the Theme altogether, and just release the shortcodes in Plugin form to begin with?

        Asked another way: what is the compelling reason for a Theme to bundle post-content shortcodes?

    • Sayontan Sinha 1:22 am on November 27, 2012 Permalink | Log in to Reply

      +1 for accepting themes that offer bundled shortcodes/CPTs as plugins.

      • Chip Bennett 2:23 am on November 27, 2012 Permalink | Log in to Reply

        CPTs are a separate discussion, and already handled by the “special use-case” Theme exception.

        I see no reason for any Theme ever to bundle post-content shortcodes.

    • Danielx64 4:02 am on January 24, 2013 Permalink | Log in to Reply

      Can we please add remove “wp_enqueue_script( ‘comment-reply’ )” to the list and make it recommended? One reason is that some people (like me) wants to add a quote button and therefore they don’t need to use the above function.

  • Chip Bennett 3:21 pm on May 8, 2012 Permalink | Log in to leave a Comment
    Tags: ,   

    Proposed WordPress 3.4 Guidelines Revisions 

    As we near the final release of WordPress 3.4, it is time to begin discussion and finalization of the related changes to the Theme Review Guidelines. Below are the proposed changes. Please discuss in the comments. We’ll do our best to keep this proposed list updated based on discussions in the comments.

    New WordPress 3.4 Functionality

    • Custom Headers/Backgrounds
      • New and deprecated functions are already covered by existing Guidelines. Themes may OPTIONALLY provide backward-compatibility with pre-3.4 handling of custom backgrounds and headers
    • Child Themes
      • Child Themes will formally be allowed to be submitted for inclusion in the Theme repository.
      • Child Themes are REQUIRED to use an approved Theme as a Template (i.e. as the Parent Theme)
      • Child Themes are REQUIRED to demonstrate sufficient difference from the Parent Theme to warrant inclusion
      • Stand-alone Themes are REQUIRED to provide basic Child-Theme support, including:
        • Proper use of get_template_directory()/get_template_directory_uri() vs. get_stylesheet_directory()/get_stylesheet_directory_uri()
        • Proper enqueueing of stylesheets, and proper cascading of styles, including no inline styles in the Theme template
    • Backward Compatibility
      • Backward compatibility is covered by existing Guidelines. Per existing Guidelines (2 major WP versions required/1 major WP version recommended):
        • Themes MUST NOT support backward-compatibility for more than two major WordPress versions (i.e. 3.2).
        • Themes are RECOMMENDED NOT to support backward-compatibility for more than one major WordPress version (i.e. 3.3).
    • Theme Settings and Data Security
      • Themes are RECOMMENDED to incorporate Theme options into the WordPress core Theme customizer.

    New Guidelines (REQUIRED)

    • Required Hooks and Navigation
    • Theme Features
      • If implementing a site logo, Themes are REQUIRED to provide user-configuration of the logo via the core custom header feature. (Exception: if incorporating both a site logo and custom header, the custom header is required to support the core custom header feature, and the custom logo is then required to be implemented via custom Theme option.)
    • Function Parameters, Filters, and Action Hooks
      • Themes are REQUIRED to use function parameters, filters, and action hooks where appropriate in order to modify content, rather than hard-coding:
        • wp_title: Themes are REQUIRED to modify output via wp_title filter. (Refer to Codex note.)
        • body_class()/post_class():
          • Themes are RECOMMENDED to modify output via filter
            (body_class/post_class)
          • Themes may OPTIONALLY modify output via function parameter
            (body_class( $class )/post_class( $class ))

    New Guidelines (RECOMMENDED)

    • Code Quality
    • Script Enqueueing
      • Themes are RECOMMENDED to enqueue the comment-reply script at the comment_form_before hook
        function theme_slug_enqueue_comment_reply_script() {
        	if ( comments_open() && get_option( 'thread_comments' ) ) {
        		wp_enqueue_script( 'comment-reply' );
        	}
        }
        add_action( 'comment_form_before', 'theme_slug_enqueue_comment_reply_script' );

    Clarifications

    Clarifications to existing guidelines being enforced:

    • Presentation vs Functionality
      • Themes are REQUIRED to function as stand-alone code. Themes may OPTIONALLY integrate support for third-party Plugins; however, Themes are REQUIRED to degrade gracefully and to function fully and properly without any such Plugins active.

    Feedback

    What else should be included? What should be revised? Let us know in the comments.

     
    • Andy Adams 4:36 pm on May 8, 2012 Permalink | Log in to Reply

      I’m not all too familiar with the .org theme repository requirements, so forgive me if I’m missing any background information. Thanks for all your work putting this together, Chip.

      The piece that I would revise would be the requirement to use the core custom header feature for logos. Many of the themes we develop use logos that don’t span the full width of the page, so it’s technically incorrect to call it a “header”. It comes down to semantics, I suppose. But I don’t like using the word “header” when it doesn’t apply.

      • Chip Bennett 4:52 pm on May 8, 2012 Permalink | Log in to Reply

        And thus, the discussion. :)

        The thought behind the requirement is two-fold: one, consistent UI is ideal for the end user, and two, with the advent of flexible headers, the core custom header feature becomes suitable for variable-sized logos.

        Personally, I think I’d rather see core implement a “site logo” option, because a site logo is Theme-independent (much like the site favicon, title, description, etc.), and then provide a way for Themes to incorporate/support that core feature.

      • Greg Priday 4:59 pm on May 8, 2012 Permalink | Log in to Reply

        3.4 gives you a lot more control over the header size. So it doesn’t need to span the full width of the page. The nice thing about using WordPress’ header functionality is that (I assume) it’ll integrate with 3.4’s theme customizer. Pretty neat.

        I agree though, I think using “headers” as logos might confuse a user. Say the user switches from one theme that uses the header as a header, to another theme that uses the header as a logo. That might not go down too well.

        Having a site logo in the core would be a great solution but for now, maybe this requirement is a bit strict – given it’s essentially a hack.

        • Chip Bennett 5:04 pm on May 8, 2012 Permalink | Log in to Reply

          Which would be easier to migrate in the future, if a “site logo” eventually becomes a core option: a core custom header theme_mod, or a custom Theme option? I don’t know; maybe either one would be equally easy, or equally difficult.

          Also, my thinking with using custom headers for the logo is that it might help differentiate the logo as a site option, rather than as a custom Theme option. But the question of end user confusion may very well be valid…

      • Devin Price 2:22 am on May 12, 2012 Permalink | Log in to Reply

        I agree. If core had a “logo” option, I would say go ahead and make it a requirement. But header implies something different.

        Also, I assume themes that already have a logo option in their theme options would be required to change it, and that could be very confusing for users who update.

    • Konstantin 4:38 pm on May 8, 2012 Permalink | Log in to Reply

      Can we drop the requirement for the following, when loading a textdomain?

      $locale = get_locale();
      $locale_file = get_template_directory() . “/languages/$locale.php”;
      if ( is_readable( $locale_file ) )
      require_once( $locale_file );

      See #20471

      In the comment-reply example, the comments_open() is not necessary (is it?), as it is called just prior to the 'comment_form_before' action.

    • ravi 4:45 pm on May 8, 2012 Permalink | Log in to Reply

      The section on “backward compatibility” is a bit confusing (to me): 2 major WP versions REQUIRED, 1 major WP version RECOMMENDED. That seems contradictory.

      • Chip Bennett 4:50 pm on May 8, 2012 Permalink | Log in to Reply

        Themes are required NOT to provide backward compatibility beyond two major WordPress versions, and they are recommended NOT to provide backward compatibility beyond one major WordPress version. The ideal is no backward compatibility at all, but that ideal simply isn’t practical.

    • Sayontan Sinha 9:37 pm on May 8, 2012 Permalink | Log in to Reply

      So, for the inline styles, consider this scenario:
      1. Let’s say I have some widgets where the users can put in a color that they want some text to show up with in the front end.
      2. There could be several instances of this widget, each with a different ID, which is dynamically assigned at the time of rendering. In such a case how can the user input be captured as an external style?

      I believe that inline styles should be allowed in such scenarios, because you are not taking away the flexibility from a user here: in fact you are offering the user the flexibility to provide such information through the UI.

      Note that the upfront absence of the widget ID makes it almost impossible to determine this information upfront. You could, theoretically parse the array of widgets to find the ID whenever the widgets are updated, then save the information to an external stylesheet, but this is not going to provide any added flexibility, since the method of information entry itself is from the user rather than the developer.

      • Chip Bennett 9:43 pm on May 8, 2012 Permalink | Log in to Reply

        First, remember: in (almost) all cases, exceptions can be requested.

        Second: you’re talking about a Widget, not a template file.

        Third: outputting a user-defined style inline is entirely different from hard-coding inline styles. The point isn’t that there’s anything inherently wrong with inline styles, but rather that hard-coded inline styles are almost impossible to override. User-defined styles output inline don’t fall into that situation.

        I think your scenario is essentially an example of an exception that proves the rule.

    • Bruce Wampler 5:11 pm on May 9, 2012 Permalink | Log in to Reply

      I should have posted a comment from the reviewers list here, sorry…

      But as Chip just said – the guide line applies to front end template files. After re-reading the guideline, it is clear that one of the main goals is to be sure child themes can essentially override anything the need to. Just keeping that goal in mind clarifies where inline styles really matter.

      Rather than widgets, my question was about inline style in the admin side where a child is not as likely to need to override a style. My admin interface code is full of inline styles because it is just kind of difficult to create a bunch of totally arbitrary styles for the admin style sheet anyway.

    • Bruce Wampler 5:19 pm on May 9, 2012 Permalink | Log in to Reply

      Yet another point – partly because recommended often becomes required, so about this one:
      Themes are RECOMMENDED to follow the official WordPress coding standards for all PHP code.

      I have a problem, sort of. Back when I started programming, and tab was based on 8 spaces. So I’ve always programmed with tabs or tabs+4 spaces for indentation. All my files use that – with the help of my IDE (Komodo). While not trivial, it certainly is possible to transform all that to 4 space based tabs which seems to be the PHP “standard”. Same with some of the other conventions, ( space in arg lists ) for example.

      But a problem with massive reformatting like that is that it will essentially make a diff review impossible. Perhaps a solution would be to allow a “reformatting” submission that would be mostly about making the code follow the WP standards?

      • Chip Bennett 6:39 pm on May 9, 2012 Permalink | Log in to Reply

        There are certainly some who want to move in the direction of requiring WP coding standards, but I think we need to have a very long conversation before ever considering that. There are certainly a plethora of best practices in the coding/CSS coding standards, but that doesn’t mean that they should be required.

        One of the primary reasons for core to publish coding standards is to help ensure consistency among disparate patches committed by a growing number of contributors and committers. It is fairly important for the core codebase to be consistent, in order to facilitate troubleshooting, bug-fixing, and future code enhancements and changes. None of these issues apply for non-core-bundled Themes.

        We want to make the coding/CSS coding standards recommended, in order to help raise awareness of those standards among the Theme developer community. I don’t view this recommended status as an intended escalation (unlike, say, the Settings API implementation, which I would prefer very much eventually to escalate to required); rather, I view it merely as awareness and promotion of best practices.

        I think it would be in the community’s best interest to consider each specific standard on a case-by-case basis, to determine appropriateness for inclusion in the Theme Review guidelines as required, rather than a wholesale adoption of those standards. By making the standards recommended, it opens the door to such further discussions within the community.

    • Andrew Nacin 5:07 am on May 10, 2012 Permalink | Log in to Reply

      A few points:

      Both Twenty Ten and Twenty Eleven would fail a number of these guidelines, including: not enqueueing styles, not filtering wp_title(), etc. I would be happy to see a Trac ticket to change these in 3.4 or 3.5. But until we do change them, I’m weary (but okay) with making these requirements.

      The CSS guidelines are still in draft mode, and may not be finalized before 3.4’s release. They were proposed originally by the Automattic theme team and not yet endorsed by the various frontend developers working on core.

      get_template_directory_uri() versus get_stylesheet_directory_uri() is not straightforward and may be tough to judge at times.

      • Chip Bennett 5:07 pm on May 10, 2012 Permalink | Log in to Reply

        I’ll be happy to submit any necessary patches for Twenty Ten and Twenty Eleven. If you see specific places where either would fail, just ping me and I’ll write them up.

        Thanks for the caveat regarding the CSS coding standards. That’s yet another reason that nothing more than recommended is appropriate at this time.

        In some cases, get_template_directory*() vs get_stylesheet_directory*() will be a matter of intended use; most of the time, though, the correct template tag to use is fairly clear. (Can/should be overridden by a Child Theme? Use stylesheet. Can’t/shouldn’t be overridden by a Child Theme? Use template.)

        • Justin Tadlock 6:04 pm on May 10, 2012 Permalink | Log in to Reply

          The use of get_stylesheet_directory*() should rarely be used in standalone/parent themes. It makes the assumption that either a child theme is not being used or that a particular file is housed within a child theme.

          Nearly always, if a regular theme is using *stylesheet*, it should be falling back to *template*.

      • Konstantin 8:29 pm on May 10, 2012 Permalink | Log in to Reply

        Oh, I’d love to contribute too (as a matter of fact, I have a patch prepared).

        @nacin: When you say “enqueueing styles” would that also include style.css?

    • Chip Bennett 5:02 pm on May 10, 2012 Permalink | Log in to Reply

      Please note the recent addition, under Clarifications, regarding stand-alone Theme functionality, and Plugin integration. This is something the WPTRT has been enforcing all along, but is not explicitly spelled out in the current Guidelines.

    • Justin Tadlock 6:01 pm on May 10, 2012 Permalink | Log in to Reply

      Themes are RECOMMENDED to incorporate Theme options into the WordPress core Theme customizer.

      Why recommend this at all? I’m already imagining disastrous scenarios of theme authors going too far. I definitely don’t want to see themes add 100s of options to this thing.

      • Chip Bennett 6:47 pm on May 10, 2012 Permalink | Log in to Reply

        I don’t understand the hesitation. Wouldn’t initial user configuration of custom Theme options via the customizer, upon Theme activation, provide the best-possible user experience?

        Sure, we’ll need to be sensible about how that integration takes place, but I think we can safely play that by ear as developers get their feet wet with the new feature. If we take the same philosophical approach with the customizer tab as we do with the Appearance sub-menu, I think we can reasonably keep things manageable, and avoid such disastrous scenarios as you’re envisioning.

        • Justin Tadlock 12:06 am on May 11, 2012 Permalink | Log in to Reply

          It’s just a question of whether we really need to recommend it, especially until we see how theme authors are utilizing it. I’m neither for or against recommending it. I’d just like to be more cautious with it for a while.

          As far as best user experience goes, I agree, to a degree. It can make for a great user experience as well as a horrible one.

          It’s just something I thought I’d throw out there for discussion.

        • Andrew Nacin 2:35 am on May 11, 2012 Permalink | Log in to Reply

          I agree with Justin. I would not “Recommend” it yet.

          • Chip Bennett 1:42 pm on May 11, 2012 Permalink | Log in to Reply

            I can see where both of you are coming from. Maybe OPTIONAL is a better approach initially? I want the customizer feature to be in the Guidelines (as with basically every other core feature that touches or interacts with Themes), as a basis for establishing future implementation guidelines.

    • Konstantin Kovshenin 6:56 am on May 11, 2012 Permalink | Log in to Reply

      I think it’s also time to make wp_nav_menu required.

      • Chip Bennett 1:44 pm on May 11, 2012 Permalink | Log in to Reply

        well, wp_nav_menu() is required: if the Theme design incorporates a navigation menu. The line we’ve not crossed thus far is dictating Theme design or aesthetic, and I’m not sure we want to cross that line. (Bear in mind that Widget support is required, and that Nav Menu Widgets can be added to dynamic sidebars – so technically speaking, all Themes do support navigation menus, at least in some form.)

    • Konstantin 7:12 am on May 11, 2012 Permalink | Log in to Reply

      I’d love to have a clearer Credit Link guideline with less leeway for both, Theme Authors and Reviewers!

      I’m not too happy about the entire “Credit Link” section of the Theme Review codex page. And when I say not too happy, I mean I hate this part of every review, because of the enormous propability that my findings won’t correlate with the opionion of more seasoned reviewers (as it happened on this one).

      What more is there to a Theme URL, other than it being a page specifically related to the Theme?
      What is relevant and appropriate in a public-facing credit link?
      What we understand under a project/development website?

      As I said before, I think a clarification, and writing up requirements that are currently enforced but not documented, would benefit both, Theme Authors and Reviewers.

      • Chip Bennett 2:01 pm on May 11, 2012 Permalink | Log in to Reply

        I completely understand your frustration. Trying to keep credit link guidelines completely objective, while at the same time avoiding CFR-level detail and breadth, can be a delicate balance.

        Regarding the ticket you linked (and if you want to discuss that one specifically, I’d be happy to do so in-ticket), when I look at the Theme URI, especially for a site that would otherwise not be valid as Author URI, the red flag for me is the ratio of Theme-related content to non-Theme-related content. Another criterion for me is, “how beneficial is this content to the end user?” But these criteria are difficult-to-impossible to quantify objectively. Call it experience-based intuition. (Maybe call it jadedness from dealing with too many Themes with crappy credit links?)

        My personal preference/ideal for an appropriate Theme URI would be Theme-specific landing page on a Theme developer (or Theme shop) site, not an essentially orphaned page, with some Theme-related content, on a site otherwise unrelated to WordPress/Themes. But that preference is not the consensus, so we try to strike a balance regarding appropriateness.

        Theme URI is one of the most subjective guidelines, and as such ends up causing most of the headaches regarding Theme-review observations.

        • Konstantin 3:13 pm on May 11, 2012 Permalink | Log in to Reply

          Please do share your thoughts in-ticket!

          I can see how it is difficult to to come up with objective guidelines, given the variations in Theme URL pages. This is probably why they haven’t been defined in more detail yet.

          But how about starting with someting like:

          Theme page is RECOMMENDED to be on a WordPress/Theme related site.

          I’d love to hear from other reviewers what they look for, when reviewing a Theme and it comes to the Crdit Links! Please share, so we can come to a better understanding on this.

        • Vicky Arulsingam 1:48 am on May 14, 2012 Permalink | Log in to Reply

          The key here is unrelated content.

          I’m okay with the Theme URI being an orphaned page but only if there isn’t unrelated content.

    • Clementine Hobbins 1:00 pm on May 17, 2012 Permalink | Log in to Reply

      Thx for information.

    • Satish Gandham 7:51 am on May 20, 2012 Permalink | Log in to Reply

      Can you please include guidelines for the featured themes, or at least ask the reviewer to say why he thought the theme should be featured.

    • Arie Putranto 8:31 pm on May 20, 2012 Permalink | Log in to Reply

      Well, what if comments.php does not exists but replace by a function which generated the comments list? Is it okay?

      • Justin Tadlock 11:17 pm on August 4, 2012 Permalink | Log in to Reply

        There’s technically not a need for the comments.php template. If your theme doesn’t need it but still handles comments correctly using the appropriate WordPress functions, you’ll be fine.

        • Chip Bennett 11:25 pm on August 4, 2012 Permalink | Log in to Reply

          I disagree. It is a general principle that Themes not rely on legacy template-part file support. And specifically for comments.php, according to source, backward compat for comments.php in comments_template() is intended to be removed, which IMHO is equivalent to it being considered as deprecated:


          else // Backward compat code will be removed in a future release
          919 require( ABSPATH . WPINC . '/theme-compat/comments.php');

          Thus, proper implementation of comments requires use of comments.php, included in the template via comments_template().

          If a Theme has a legitimate reason for an exception to this implementation, then that exception can be handled just like any other guideline exception.

    • @mercime 5:06 pm on May 22, 2012 Permalink | Log in to Reply

      We know now that there are theme authors who add another subpanel, Appearances > More Themes in themes that have been approved/accepted into the WP Theme Repository http://lists.wordpress.org/pipermail/theme-reviewers/2012-April/008791.html

      There should be guidelines surrounding the practice if this (More Themes subpanel) continues and grows, for example:
      1. Maximum number of themes which can be listed in that subpanel.
      2. Links from that subpanel should only go to webpages of approved Theme URL
      3. No affiliate links.
      4. In relation to that, no calling home scripts to find out how many clicked from subpanel links to theme webpage
      5. Best practices for adding subpanel.
      6. Etc.

      Thanks.

    • Emil Uzelac 5:36 am on June 22, 2012 Permalink | Log in to Reply

      Just a very quick note that this 3.4 guidelines will need to be discussed bit more before we actually decide on anything and push this over to http://codex.wordpress.org/Theme_Review

      For example get_template_directory()/get_template_directory_uri() should be recommended, not required.

      The reason is that many users already have Child Themes in place with non get_template_directory()/get_template_directory_uri(), requiring Themes to make a switch will break all of them. If requirements are needed, let’s set this for new submissions only, while only recommending to currently approved ones.

      Yes, this is definitely way to go, but not for currently approved Themes.

      Thanks,
      Emil

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel