Make WordPress Themes

Tagged: discussion Toggle Comment Threads | Keyboard Shortcuts

  • Chip Bennett 3:21 pm on December 14, 2012 Permalink | Reply
    Tags: discussion,   

    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 | 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 | 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 | 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 | 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 | 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 | 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 | Reply

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

      • Chip Bennett 3:28 pm on December 14, 2012 Permalink | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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

      • Frumph 5:05 pm on December 14, 2012 Permalink | Reply

        rather use query_posts with a wp_query_reset then get_posts with a foreach loop anyday

      • Justin Tadlock 5:36 pm on December 14, 2012 Permalink | Reply

        Additional loops should be made with a new WP_Query on any page.

    • Justin Tadlock 5:35 pm on December 14, 2012 Permalink | 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 | Reply

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

        • Ryan Duff 5:58 pm on December 14, 2012 Permalink | 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 | 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 | 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 | Reply

          +Like

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

          +1 for that

        • Frumph 6:33 pm on December 14, 2012 Permalink | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 2:48 pm on January 24, 2011 Permalink
    Tags: discussion, , obsolescence   

    Follow-Up: Theme Obsolescence Guideline 

    I haven’t yet seen any discussion of this point in Phil’s post below, so I wanted to highlight it again:

    Some of the review team have brought it up that there should be a time limit for non-updated themes, our general consensus is 2 or 3 major revisions of WordPress before suspension for not keeping themes updated. What this means that currently we’re on WordPress 3.0 previous to that was 2.9, 2.8 which is 2, 2.7 being 3 revisions previous, all themes that are prior to 2.7 (or 2.8) should be suspended as being currently obsolete.

    To be clear, the Theme Review Team is formally proposing an obsolescence Guideline, that any Theme not updated within 2 (perhaps 3) major releases of WordPress be automatically suspended, until a current version is submitted and approved.

    For example, if this guideline were put into place with a timeline of 3 major WordPress releases, when WordPress 3.1 is released, all Themes not updated since before the release of WordPress 2.8 (i.e. since June 2009) would be blanket-suspended.

    Or, if this guideline were put into place with a timeline of 2 major WordPress releases, when WordPress 3.1 is released, all Themes not updated since before the release of WordPress 2.9 (i.e. since December 2009) would be blanket-suspended.

    We very much want input and feedback on this proposal. Would this guideline generally help or hurt – improve or worsen – the Theme Repository? Is the proposed timeline (2 or 3 major WordPress releases, which translates into, generally speaking, 6 or 9 months) reasonable?

     

    • Chip Bennett 3:30 pm on January 24, 2011 Permalink

      (Test Comment)

    • miklb 4:09 pm on January 24, 2011 Permalink

      Maybe have somewhere that these potential obsolete/abandoned themes could be listed, giving others the chance to adopt them and bring them up-to-date.

      I think that 2.9 support should be the minimum, with 2 releases going forward. Far too many features (post-thumbnail anyone?) that if not supported, seems to be doing users an injustice.

      • Edward Caissie 5:01 pm on January 24, 2011 Permalink

        Ideally we will have a relatively current list available from this site … to start. I have been lobbying within the WPTRT to recommend a (second?) repository for these themes to no avail.

        • Chip Bennett 9:48 pm on January 24, 2011 Permalink

          I think I’ve just had an epiphany, and now understand what you’ve been trying to suggest.

          I think I could buy a “Themes For Adoption” repository, provided it has some sort of web interface, so users could see adoption-eligible Themes.

    • Dre 4:11 pm on January 24, 2011 Permalink

      I think this would help with themes and plugins, but If removing them altogether isn’t reasonable, what about segregating them into a specific listing after xx amount of releases without an update?

    • Justin Tadlock 4:27 pm on January 24, 2011 Permalink

      Generally, I like this idea. The only way I would oppose it would be if WP didn’t add anything that themes would need to use. For example, when the comment_form() function came out, themes needed to update to use that function. I don’t think there’s anything in WP 3.1 that themes need to switch over to.

      WP typically adds something like this at least in every two or three versions though, so it shouldn’t be a problem.

      • Edward Caissie 5:03 pm on January 24, 2011 Permalink

        Under this basic premise, using the comment_form() example, I would imagine we could make the “cut-off” time a little more fluid if necessary.

        • Chip Bennett 5:18 pm on January 24, 2011 Permalink

          On the other hand, there is benefit and value to the end user, knowing that the developer of his chosen Theme is at least paying enough attention to the Theme to document that it still works with the most current version of WordPress.

          Has there ever been a Theme developed that is so perfect that it doesn’t need to be updated, modified, or tweaked – at *all* – for six to nine months?

          • Edward Caissie 5:57 pm on January 24, 2011 Permalink

            I think “need” is rather subjective in this case when we are discussing requirements that will have to be taken into consideration. Personally I have a “need to update, modify, or tweak” my themes every three to four months but these edits are not always required to be made … sometimes they’re just nice to do.

            • Chip Bennett 6:05 pm on January 24, 2011 Permalink

              Oh, I’m speaking entirely subjectively here. It is, in part, about the “warm fuzzy” users will feel, knowing that the Theme they currently use is actively being tended to by its developer.

              And if a developer isn’t bothering with even the “nice-to-do” updates, he certainly isn’t bothering with the “must-do-to-keep-current” updates, either.

          • Peter Westwood 6:18 pm on January 24, 2011 Permalink

            Has there ever been a Theme developed that is so perfect that it doesn’t need to be updated, modified, or tweaked – at *all* – for six to nine months?

            Default ;-)

            • Frumph 12:55 pm on January 25, 2011 Permalink

              Let’s try that question again ;) “Is there a theme developed that is so perfect that it doesn’t need to be updated to the current revision of WordPress that was created pre 3.0 release?

    • Devin 6:21 pm on January 24, 2011 Permalink

      I think this is an excellent idea that will bring up the quality of all themes in the repository.

      I’m also wondering if there’s a way to help out theme developers with this process. Here’s some thoughts:

      1) Develop a way for themes to be adopted.
      2) Give SVN access to themes and allow other developers to submit patches
      3) Would there be any way to programmatically suggest patches? For instance, when a function is deprecated and replaced- perhaps a patch could be automatically created for every theme that needs the update so the author could more easily commit it.
      4) Failing #3, perhaps an automated e-mail could be sent out to the theme author letting them know which functions in their theme have been deprecated or certain functionality that has changed. This might even just be updating the theme checker with the new data, running all the themes through it, and sending out the automated e-mails.

      • Chip Bennett 8:24 pm on January 24, 2011 Permalink

        I don’t think core developer or WPTRT resources would be well-spent trying to automate something that the Theme developers really should be responsible for.

        All the tools are there, and available for use: Theme-Check, Log Deprecated Notices, Debogger, Admin Debug Bar, etc. These tools will be kept up-to-date, and all a developer has to do, then, is to keep the Plugins updated, and test their own Theme with them.

        As for Theme adoption: I’d love to get some kind of program like that going. There are a lot of Themes in the Repository that *look* great, but just need to be updated under the hood.

        Theme-SVN commit access: yes, please! (But I don’t think it should be rolled out to every Repository-hosted Theme developer. That kind of access/power needs to have some form of trust/meritocracy structure built into it.

        I like the patch idea, though: let Theme developers submit patches for their Themes, and then someone with commit access (e.g. the WPTRT members) can commit the patch. (Of course, updating already-approved Themes is a fairly quick and painless process now, anyway (hopefully).)

    • jeherve 11:33 pm on January 24, 2011 Permalink

      I like the idea. Such practice would help having higher quality themes in the repo for sure.
      I am a little worried though: do you have a way to estimate how many of the themes in the repo have not been updated since 2.9 went out? Having too few themes in the repository would have a really bad image for WordPress in general, since the available themes is probably one of the first things the newbies have a look at before totry the software. What do you think?

      • Chip Bennett 11:42 pm on January 24, 2011 Permalink

        I can tell you exactly (well, approximately) how many Themes will be left.

        Right now, there are 88 pages of Themes, with 15 Themes per page, for a total of about 1,300 Themes in the Repository. Blanket suspending Themes not updated since before WordPress 2.9 was released would suspend everything after about page 30. So, that would leave about 450 Themes in the repository.

        That’s a significant change, but:

        1) 450 Themes is still a TON of Themes
        2) Any one of the suspended Themes could be made live again, simply by being updated.

        • jeherve 9:28 am on January 25, 2011 Permalink

          Ok, that’s a lot of themes, I expected much less!
          I am all for the idea then! :)

    • esmi 10:36 am on January 25, 2011 Permalink

      Since so many have now commented, I’ll try to keep this short.

      1) Yes to the removal/suspension of themes that haven’t been updated for at least 2 major releases. Users probably expect Repository themes to support the latest & funkiest features in WordPress, so let’s not confuse them by housing older themes that don’t even come close to that.

      2) I was also going to suggest an adopt-a-theme project. It could be a great resource for newer developers who don’t yet feel confident enough to build their own themes from scratch.

    • Lance Willett 9:09 pm on January 27, 2011 Permalink

      What about not removing any themes but adding a big notice to the theme page near the download link that explains that the theme is not up to date? People who really want it can still access it; I think it’s valuable to have older themes around if nothing else than for posterity sake.

      Of course having the out-of-date themes in a separate listing or repository would work, too—but we should be able to access them forever, even if they go extinct.

      I love the “adopt-a-theme” ideas presented above, that would be a great solution to abandoned themes.

      • Chip Bennett 9:31 pm on January 27, 2011 Permalink

        My primary concern with keeping them active on the main repository is the tie-in with the WordPress Add Theme UI. If there were some way either to hide obsolete-flagged Themes from this UI, or else to prevent their one-click installation, then perhaps they could avoid being suspended.

        If the best answer is to provide a second repository, and a separate listing in Extend/Themes, then let’s go that route.

        The intent certainly isn’t to eliminate those Themes forever, but rather to stop facilitating the installation and use of clearly obsolete Themes. (A secondary intent, at least for me, is to raise the reputation of the Repository with respect to the quality of the hosted Themes, and to instill the expectation that developers need to continue supporting and to keep their Repository-hosted Themes current.)

        Which, of course, brings us back to the adopt-a-Theme idea. :)

      • Frumph 5:49 pm on January 28, 2011 Permalink

        I was thinking this exact same thing this morning on what we could do sooner then later. I don’t suppose the bbpress code is up anywhere where we could submit patches ?

        I’m not a fan of a second repository. I think we can accomplish this by removing the outdated themes from the regular search queries and having a second search available for outdated themes so the can still be viewed.

        This will help keep the themes still being available for people to look back and adopt as well as keeping them from the regular search/download. Also to mention it won’t be a torment of a job to incorporate in comparison to a whole new extend section

    • Ian Stewart 7:51 pm on January 28, 2011 Permalink

      There may be older themes in the repo that are perfectly fine and not in need of any update at all (humor me). Has notifying authors of out-of-date themes been discussed? And instead of simply removing themes that are old, how about automatically running theme check on older themes periodically. If an older theme fails, the results could be sent back to the author in an automatic notification. After 3 notifications and no updates, suspend the theme.

      If we were doing that I’d be inclined to voting for decreasing the difference in versions and doing this yearly.

      • Chip Bennett 9:41 pm on January 28, 2011 Permalink

        I would wager real money that you could not find one such Theme… but for the sake of argument: yes, we’ve made initial attempts at contact authors, based on a recent audit of the oldest 200 (or so) Themes. The response was, to put it bluntly, abysmal. Several defunct email addresses, a couple requests to pull Themes, one response agreeing to let Themes be “adopted”, and the rest failed to respond.

        Granted, we only attempted to contact developers of Themes that were found to have particularly egregious issues (non-GPL-compatible license or restrictions, spam links, etc.) – but the rest represent, at a minimum, a demonstrated lack of interest in keeping the Theme updated (we only looked at Themes last updated in 2008).

        Again: “suspending” isn’t permanent. All it means is that a Theme isn’t visible in Extend until it is updated. (We are also exploring alternate implementations that would allow such Themes to be searched separately and downloaded manually, but not available for direct install in the WP-Admin Add Themes UI, and not visible in the default searches in Extend.)

      • Ian Stewart 2:17 am on January 29, 2011 Permalink

        So you will be contacting authors before suspending themes? I’m not worried about the suspension so much as the notification. As noted above, I think you could do this more often if you were contacting authors first and limiting to known broken-ish themes. Basically, I’d hate to see perfectly good themes drop out of circulation just because the author changed his email or stopped developing on the theme.

        Essentially, I’d rather see this be feature/guideline-compliance-based rather than date/version-based.

        • Chip Bennett 3:56 am on January 29, 2011 Permalink

          I would assume that an attempt to contact would be made before suspension.

          That said, I disagree in one regard: I think that a developer stopping development of a Theme to be a perfectly valid reason for suspension. I think that the privilege of having a Theme hosted in the repository brings with it a responsibility and expectation to continue developing and supporting that Theme.

        • Ian Stewart 2:45 pm on January 29, 2011 Permalink

          Right. I agree with your disagreement. Except I’d like to see the criteria be for compliance rather than age. I’m thinking (hypothetically) of an older theme that’s perfectly fine, if you uploaded it today it’d pass a review with flying colors, but it’s going to get suspended because it hasn’t been updated in 2 versions and the author is nowhere to be found? That would seem silly to me.

          Suspend dormant themes left and right if they couldn’t be uploaded today. But if they’re still OK I’d vote to leave them alone.

      • Edward Caissie 12:26 pm on January 29, 2011 Permalink

        I like the idea of contacting the author multiple times. Which makes me think if this was done with an Automattic (or WordPress.org) email address as an automated process it would be much more relevant to the reader.

        Also, some authors may still potentially not be aware of the WPTRT or its members; and, one of us sending these notices from a “personal” email may not be received with the appropriate importance, aw well. Access to an appropriate email address for the WPTRT may also be a good thing to have …

  • Frumph 9:10 am on January 24, 2011 Permalink
    Tags: , discussion,   

    Discussion – Child Themes on the Repository – Guidelines 

    1) Parent themes of child themes that are developed need to be made child-theme ready; proper use of where to find files with get_template_part, get_stylesheet_ and get_template_ functions.
    2) http://codex.wordpress.org/Child_Themes documentation is applied as part of the theme review process when checking child themes, all information is to be considered good practice and required, with addition to the theme review representation of license information.
    3) Parent themes of child themes submitted must have passed the current theme review guidelines for the current revision of WordPress, not if they have passed before, but specifically with the current revision of WordPress.
    4) Child themes are reviewed with the parent theme; must pass current theme review guidelines and associated child theme documentation.
    5) Recommendation to use the parent themes repository slug as the prefix to the child theme’s name. ex. easel-highsociety, atahualpa-wired, this is only the name of the theme & directory name of theme in the zip, not where to find the theme; even as found in the http://codex.wordpress.org/Child_Themes being part of the review process, this naming convention will stay a recommendation; however, declared best-practice.
    6) Description in the style.css must clearly state that it is a child theme example: “This is a child theme for the Easel theme.” – This is for redundancy of recognition that it is a child theme, even though other things will be noted on the repository that it is a child theme, this is for the wp-admin -> themes page for the end user.

    Additional For Developers:
    1) It is the responsibility of the developer of child themes to keep their child themes up to date with the current revision of their theme that is updated. If a developer make changes to the parent theme, it is the developers responsibility to keep the child themes updated as well.

    Changes, word usage, additional guidelines and protocols, as well as information regarding use of child-theme tag requested as part of this discussion.

     

    • Chris 10:33 am on January 24, 2011 Permalink

      Child Themes should / must use filters, hooks, and override functionality provided by the parent theme to change or extend the presentation of the blog content. Overriding the standard templates should only be allowed, if there is no other way to change or extend the presentation of the blog content.

      • Chip Bennett 2:07 pm on January 24, 2011 Permalink

        I think this should be *recommended* only.

      • Chip Bennett 2:37 pm on January 24, 2011 Permalink

        And along these same lines, we’ve batted around the idea of establishing some form of positive reinforcement/encouragement for Stand-Alone Themes that are designed with Child Themes in mind (making as much pluggable/hookable as possible) – not as a requirement, but as some form of recognition (e.g. a tag or other notice in Extend/Themes) that a Theme is “Child-Theme ready”.

    • Peter Westwood 12:16 pm on January 24, 2011 Permalink

      Question: How are updates to Parent Themes going to be reviewed?

      Ideally an update to a Parent Theme needs checking to ensure that is doesn’t break any of the child themes in the repository.

      • Chris 1:14 pm on January 24, 2011 Permalink

        I don’t think that the Review Team is able to handle this request. In addition, imagine a parent theme author embeds a needed change that breaks some or all child themes.

        I suggest to implement an additional version number to the child theme’s readme.txt similar to the ones used for plugins. This would declare that the child theme is compatible with a certain version of the parent theme.

        • Edward Caissie 1:39 pm on January 24, 2011 Permalink

          I’m liking this idea … add a header tag to work with “Template” such as “Template Version” representing the parent theme for which the child theme was developed.

        • Chip Bennett 2:26 pm on January 24, 2011 Permalink

          Great idea! A “Template Version:” header tag.

          What about something akin to the “Requires:” and “Tested Up To:” header tags, such as:

          “Template Required Version:”
          “Template Tested Up To Version:”

          • Peter Westwood 6:21 pm on January 24, 2011 Permalink

            This is an interesting idea – whatever is done though needs to go full circle through a review with the core team to ensure that it will fit in with improvements with the theme installer in core to support child themes.

            We don’t want to end up with too complex a dependency situation to resolve with core/theme/child theme versions.

            • Chip Bennett 8:16 pm on January 24, 2011 Permalink

              On one hand, those potential dependency issues are *going* to exist, if/when Child Themes are added to the Repository.

              On the other hand, I think it should be a given that Child Themes must adopt the *WordPress* “Requires:” and “Tested Up To:” versions listed in the declared Template Version.

              We certainly don’t want a Stand-Alone Theme tested up to WP 3.0.4 serving as a Parent Theme of a Child Theme that Requires WP 3.1. There’s definitely potential for breakage there.

            • Chip Bennett 8:27 pm on January 24, 2011 Permalink

              Westi, would it be possible to get some Mozilla-like enhancements to Extend? With Firefox extensions, the download link changes based on the FF version/Plugin version dependency, in order to make it obvious/more difficult to install a Plugin that is incompatible with the user’s version of Firefox.

              A similar model could work quite well for Plugin/Theme Extend.

        • Lance Willett 9:29 pm on January 27, 2011 Permalink

          Keeping it simple is the key: if it can be done with just “Template Version” that’d be best. If the version number in the child theme stylesheet doesn’t match the parent theme’s version, you know you have a problem. :)

      • Edward Caissie 1:44 pm on January 24, 2011 Permalink

        I would expect Child-Theme authors to “respect their elders” and be prepared to correct their works if a Parent-Theme creates an issue where their Child-Theme “breaks”.

      • Chip Bennett 2:10 pm on January 24, 2011 Permalink

        This request assumes that only the Stand-Alone Theme developer has also developed all Child Themes, which will almost certainly NOT be the case, since *any* Stand-Alone Theme can serve as a Parent Theme.

        It is unreasonable to expect a Stand-Alone Theme developer to be responsible for the maintenance/update of code that he does not own or control.

      • Lance Willett 9:27 pm on January 27, 2011 Permalink

        I agree that the burden of updating the child themes should be on the child theme developer. When submitting a child theme to Extend you assume responsibility to keep up with the changes in the parent. It *should* be as easy as following on RSS feed from Trac for the log of the parent theme (though adding a quick link to that feed from the Extend page might help).

    • Edward Caissie 1:51 pm on January 24, 2011 Permalink

      Other notes to consider for “Developers”:
      1) If a Child-Theme is not updated on a regular basis in conjunction with a Parent-Theme it may be subject to additional administrative actions; time-line to be established.
      2) If a Parent-Theme (for whatever reason) is required to be suspended, it can be expected all related Child-Themes to be, at a minimum, temporarily suspended.

      • Chip Bennett 2:12 pm on January 24, 2011 Permalink

        Bear in mind: a Child Theme may *never* need to be updated, especially if the Child Theme is merely a “skin” (CSS-only modifications).

        • Lance Willett 9:24 pm on January 27, 2011 Permalink

          CSS-only child themes could need updates just like any other theme as HTML structure changes in the parent or HTML elements are added or removed there.

    • Jonnya 7:09 pm on January 24, 2011 Permalink

      The popularity of parent/child theme construction is growing – and has many advantages over traditional custom theme design.

      In an ideal world theme developers would keep their parent and child themes up-to-date with each other. However this becomes an issue when you have third-party developers developing child themes – keeping version compatibility in sync becomes an problem.

      I guess the best way to drive this is putting in structure to handle the updates via the official theme repository – but one big thing to consider is minimum and ‘recommended’ versions when using child/parent themes. Recommended version would be updated by the designer (hopefully) soon after the framework update.

      Another suggestion would be to simply have additional information in style.css – this is the most logical place for users it as there is already the theme version held here, ie:

      Theme Name: My theme
      Theme URI: http://mytheme.com/
      Description: Description here
      Author: My name
      Version: 1.0
      Template: parent-theme
      Template minimum version: 2.32
      Template recommended version: 2.39
      Tags: tag1, tag2
      License: GNU General Public License v2.0
      License URI: http://www.gnu.org/licenses/gpl-2.0.html

      A final way is to set the values in the child theme’s functions.php – not so keen on that one for end users (and hey, very child themes may not even HAVE a functions.php!)

      I am actually creating something similar for a free, open source project I’m working on – once I have completed some functionality worth submitting I’ll certainly be posting up on the Trac. To me this is essential functionality if you want users to really use nice, simple child themes, with a great framework (sorry, child theme!) behind it that gets updated easily.

    • Emil 10:32 pm on January 24, 2011 Permalink

      This is pretty nice, however I would like to recommend that we do some kind of guideline, where the Parent Theme functionality is not changed, extended yes, but not unregistered via Child Theme functions.php. One of the reasons for this is, let’s say user likes everything on TwentyTen, but wants different look only. Maybe TwentyTen wasn’t the perfect example, but you got my point. This will also prevent major updates on children as well. (is not like they should be updated anyways).

      How about this too. Prevent Child Theme updates as far as the design goes? If parents are updated and children need some updates as well that’s fine, however let’s keep the same look. This will be better for users and knowing that the look they chose will not be changed in the future. If author wants new look, one more Child Theme is directory will not hurt anyone.

      What do you think?

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