WordPress.org

Ready to get started?Download WordPress

Review WordPress Themes

Tagged: discussion Toggle Comment Threads | Keyboard Shortcuts

  • Jose Castaneda 5:45 am on February 18, 2014 Permalink
    Tags: , discussion, ,   

    Improving our theme previews 

    As many of you may, or may not, have noticed there are currently over two thousand themes available in the repository. I think that is amazing. Seriously, huge thanks to all those that have contributed not only their time but their efforts as well.

    One thing I noticed some time ago was the mentioning of the theme previews. I can’t recall where it was brought up but I do recall it mentioned that it wasn’t the greatest preview of a theme, or themes really. I do hate to admit it but it is fairly true. The current preview is lacking on some things.

    One of the things being post formats. Currently the theme preview is just a few posts and a few pages. I think we can do a little better now. I’ve brought up a ticket a few times: #30 in the Meta trac.

    Here are some of the things I think we can not only improve upon but can contribute to.

    • Sample data
    • Images
    • Video
    • Audio

    Data

    Simple and to the point. We need posts and plenty of them. How about quick little tidbits like how to set up a front page, or changing the image header. Doesn’t have to be huge.

    Images

    Galleries. Sliders. Single images. We need more boats!! Okay not really but if you have them it would be awesome.

    Videos

    I think we can find a way to contribute a few videos here and there. I know there are some themes that have video format support and I would love to be able to accent that in some way.

    Audio

    I’m thinking podcasters and maybe musicians.

    So there you have it. Let’s discuss!

     
    • Rohit Tripathi 1:51 pm on February 18, 2014 Permalink

      +1 to this Idea. I feel Better theme previews are beneficial for the theme authors and users, both.

      • Jose 1:55 pm on February 18, 2014 Permalink

        I feel the same way. As theme developers and reviewers, how can we improve it? I’ve somewhat begun that content building: josemcastaneda.com/preview

        I would love to hear suggestions on what else can be used.

    • PeterRKnight 5:58 pm on February 18, 2014 Permalink

      This is such a great area to focus on as there is a lot of room of improvement. How often does it happen when a preview comes up really ugly when it is actually a nice theme. Thoughts:

      • I’d love for the preview to occupy the whole screen, maybe using a top bar like how theme shops and marketplaces tend to handle their theme previews.
      • It would be awesome if theme authors could submit their own demo url so that themes with more varied front page layouts can have a more representative way to showcase what the theme can do.
    • Ulrich 6:08 pm on February 20, 2014 Permalink

      I would keep it as simple as possible. So you want to just include samples of all of the features in WordPress.

      Style Guide
      Featured Image
      Custom Post Types
      Gallery
      A few images pages
      Three level drop down menu

      I think whatever we add will better then what we have now. The current content is from 2008, so about 6 years old.

      @jcastaneda I would recommend you extend your version abit and submit it. We can always improve on it afterwards.

    • Jan Dembowski 1:01 pm on February 24, 2014 Permalink

      Given the large amount of themes available this may not be doable: is there a way to get a theme-name-slug.preview.wordpress.org?

      Sometimes members don’t want or can’t to post the URL to their site. Having an easy to reference theme preview link that’s not in a frame might be handy.

      Apologies if this exists already. ;)

  • Jose Castaneda 10:33 pm on February 11, 2014 Permalink
    Tags: , , discussion   

    What is your working environment? 

    I’ve actually wondered as to what most of us like to use when it comes to reviewing themes and possibly even creating themes.

    One thing I would like to see is the use of VVV. I know most of us have never tried it out or even heard of it but I feel we can all benefit from using it. Why? Because as the video states it does make it easier to be on the same page.

    I would love to see what you all use for your testing and development of themes. Or even plugins.

     
    • zamoose 10:35 pm on February 11, 2014 Permalink

      It’s not QUITE there, but I’m getting close.

      http://github.com/zamoose/vagrantrt

      I need to wrangle with rmmcue over how to best do a couple of things upstream in Puppet and then I’ll be ready for a beta release.

      • Jose 10:39 pm on February 11, 2014 Permalink

        Great to hear! Can’t wait. :D

    • Zach Russell Philadelphia 11:30 pm on February 11, 2014 Permalink

      I have been working on my own vagrant setup as well. I’m sure it’s not as extravagant as the one Zamoose is making (I’m building it with my personal development needs in mind), but i’ll post a link here once it’s release publicly.

      • Jose 5:53 am on February 12, 2014 Permalink

        That’s awesome! Please do share when you have it done. :)

    • Rohit Tripathi 12:33 am on February 12, 2014 Permalink

      I prefer localhost, but I am definitely trying out VVV.

    • Frumph 2:43 am on February 12, 2014 Permalink

      I pay for hosting, so using whatever subdomain I create for whatever project I need – also; it helps keeping a methodology that allows clients/users to see what i’m seeing if I link them, can’ setup vvv on my machine to handle that.

      • rahul286 8:35 am on February 12, 2014 Permalink

        We develope on our own localhost and have a demo server with wildcard domains. We have https://github.com/rtCamp/easyengine on server to create demo sites at subdomain using 1-command.

        As of now we are using Grunt, git and some shell script to sync changes from local to remote server sites. Soon we will add this to easyenigne (disclosure: I am from easyengine team).

        This approach help us use a single $5 digitalocean VPS for giving demo of 100 of sites. As soon work is finished, we delete sites using easyengine delete commands.

    • Hari Maliya 8:32 am on February 12, 2014 Permalink

      I prefer localhost . but i try to use VVV.

    • tskk 10:49 am on February 12, 2014 Permalink

      I use web server, but local host seems to be preferred option.

    • Zulfikar Nore 8:24 am on February 13, 2014 Permalink

      For reviews I primarily use a live web server.

      For production its mainly localhost simply for the convenience of being able to readily access the files via explorer for edits.

      VVV looks interesting and some to start exploring soon.

  • Chip Bennett 4:14 pm on November 18, 2013 Permalink
    Tags: discussion,   

    Is the Theme Directory “Blog” Focused? 

    Some recent discussions in the community have indicated that the Theme directory is too “blog” focused, and that the Guidelines actively discourage non-blogging Themes from being submitted.  There are some things that are true, some things that are untrue, and some things that are simply outside of the control of the Theme Review Team, in terms of the Theme directory and “non-blogging” Themes.

    One thing that is true is that the current stance of the Theme Review Team is that the “CMS” use case is not significantly compelling for a Theme to omit support for a blog. From a coding perspective, the differences between a post loop and a static page loop are minimal. From a user perspective, there is no real reason to restrict a “CMS” Theme’s user base only to users who don’t intend to use the core blog functionality.

    Another thing that is partially true is that the current Theme Unit Tests appear heavily blog-centric. But that’s mainly because the unit tests are presented as blog posts. Some things – taxonomies, posts navigation, post formats, etc. – only apply to blog posts; but most of the rest of the Theme Unit Tests apply equally regardless of post type. The Theme Unit Tests are designed as test-every-reasonable-use-case data: to push edge cases and boundaries, to ensure that Themes accommodate the widest possible range of use cases and to see how Themes respond to break points. Generally speaking, the entire suite won’t apply to any given Theme (for example, most Themes don’t add support for all post formats; so the unit tests for unsupported post formats wouldn’t apply).

    By contrast, one thing that is not true is that there is no recourse for hosting a non-traditional Theme in the Theme directory. Want to submit a Theme intended to be used as a support ticket system, a knowledge base, or a presentation slideshow? Those are all welcome in the Theme directory.  We refer to these Themes as “niche” or “custom use” Themes, and we already have a mechanism in place to “whitelist” those Themes so that they can bypass non-applicable upload script tests. All we ask is that developers email the mail-list and ask for an exemption, along with explaining the justification.

    But there are many things that are outside of the control of the Theme Review Team, including anything that deals with the infrastructure of wordpress.org/themes itself. We have one Theme directory to work with. We can recommend filter tags to be added, removed, or modified; but we don’t make the final call on them. We have no control over the each Theme’s page in the directory, the ratings/review system, the algorithms for trending Theme lists, or pretty much anything other than actually marking Themes as “live” in the directory, after completing a review. There are many ways that these things could be improved, but we are dependent on other people who have much higher priorities in the grand scheme of the WordPress project and website.

    I would love to have the ability to host Theme frameworks (in the classic, non-marketing sense of the term: a drop-in code library that facilitates Theme development) in the directory, it would greatly simplify review for Themes that use frameworks such as Hybrid Core and the like; but we currently have no infrastructure to do so. I would love to have the Theme’s directory listing page parse the Theme’s readme file the same way that a Plugin’s listing page parses its readme; but that’s something else that isn’t possible at the moment.

    I would love to explore the idea of having multiple Theme directories, or some sort of “tier” system; but we just don’t have that infrastructure. And that’s one of the primary reasons that we have what appears to be a “one size fits all” approach and mechanism for Theme submission, review, and approval – but that doesn’t mean that we can’t or won’t accept submissions for Themes that don’t fall strictly within the “blogging” genre. If you have an idea or question, mail the Theme Reviewers mail-list and ask. It can’t hurt anything, and you very well may be surprised by the response.

     
    • nofearinc 4:25 pm on November 18, 2013 Permalink

      I’ve already expressed my thoughts last week, and I’m happy for getting this discussion in the public.

      I agree with most of your thoughts here. The only thing I’d like to outline is that: 1) the limitations of the existing infrastructure shouldn’t stop us from proposing new features that would bring value to the Directory, if we all agree on this, and 2) we could express these thoughts of yours (such as “All we ask is that developers email the mail-list and ask for an exemption, along with explaining the justification”) in a more public manner.

      Otto is mostly in charge of http://meta.trac.wordpress.org/ and I believe that we could propose some changes (and texts, which is easy) to improve the process with time. That’s valuable only if we are on the same page when it comes to the state of themes and it makes sense to build a roadmap that slowly gets into the infrastructure.

    • tskk 4:30 pm on November 18, 2013 Permalink

      We need new tags, frameworks can be added under a new tag, KB themes can be added under a new tag etc…

      Getting new tags should be doable and first step.

      • StyledThemes 5:08 pm on November 18, 2013 Permalink

        That would be great. Actually the tags need an overhaul…I already know of one that should be added: responsive

      • StyledThemes 5:21 pm on November 18, 2013 Permalink

        You pretty much got to the point of some changes would be great but as you mentioned as one idea:

        “I would love to explore the idea of having multiple Theme directories, or some sort of “tier” system; but we just don’t have that infrastructure.”

        That would be a great one actually; one for the current basic themes, then another for the more professional designed themes (free of course). It would be nice to also have the theme pages like the Plugins have for layout and information. I’d even like to see that Preview system abolished as it does not do justice for themes…make it a link to a live demo site instead. There’s a lot of ideas that can be presented but as you said, the infrastructure is not there…perhaps this is something that should be looked into at some point and have a scalable solution in place.

        Anyway, as for the Blog or cms topic, I never really noticed that there was focus more on blog themes (or the appearance of) and never gave it much thought. I know for my themes I make them for both uses. I’ve had some people as me if my themes can be used without the blog and the answer is definitely yes. I am seeing a growing number of people looking to the cms theme solution, but it’s still important to maintain a blogging capability within themes should one decide to use it.

        • StyledThemes 5:22 pm on November 18, 2013 Permalink

          sorry…not sure why or how this reply got posted here, it was meant for Chip’s first opening post.

    • Zulfikar Nore 4:34 pm on November 18, 2013 Permalink

      Agreed +1

      I’ve hated each time I’ve had to ask an author to reconfigure their theme so that it handles the “Blog” as intended. Personally I see nothing wrong with a theme having a custom front page with the blog handled on another internal page.

      Not only will this move simplify the review process but it will also facilitate the ability for authors to submit custom (non bloggy <- if that's even a word!) themes. I would totally welcome the chance to do so myself :)

      And since we have from having the TUT being a required element of the theme approval process, dealing with CMS type themes shouldn't too tasking on the team as whole.

      • Zulfikar Nore 4:36 pm on November 18, 2013 Permalink

        EDIT: And since we have “moved” from having the TUT being a required element of the theme approval process, dealing with CMS type themes shouldn’t too tasking on the team as whole.

        • Chip Bennett 4:37 pm on November 18, 2013 Permalink

          We already can deal with “CMS” Themes. But if the only defining difference for a “CMS” Theme is that it omits support for the blog, that’s not a reasonable enough difference to warrant an exception.

          • nofearinc 4:44 pm on November 18, 2013 Permalink

            IMO it’s not really the “omits support for the blog”, but rather focusing on other, business-theme related details, and not covering some details from TUT. The “Recommended” status of the TUT would facilitate that process, especially if there is a major shout-out to theme developers for the new decision and the willingness of the TRT to help CMS theme authors without being too picky and restrictive (just as is with UI comments for reviewers that are subjective).

      • Chip Bennett 4:37 pm on November 18, 2013 Permalink

        But that’s kind of the point: there’s no change happening here. I’m mostly just trying to dis spell some misconceptions.

    • Subharanjan 4:50 pm on November 18, 2013 Permalink

      “”” We have no control over the each Theme’s page in the directory, the ratings/review system, the algorithms for trending Theme lists, or pretty much anything other than actually marking Themes as “live” in the directory, after completing a review. “””
      — Can we have some rules for themes of different kinds to be accepted after approved by 5 reviewers.
      — If approved, it should be allowed to use custom theme unit test data to better match its functionality and design.

      • Chip Bennett 5:04 pm on November 18, 2013 Permalink

        I don’t understand the need for 5 reviewers?

        Also: The Theme Unit Test data are what they are, and they are used only so far as they serve their purpose. There really isn’t a need to “specialized” Theme Unit Test data for custom Themes. Are you referring to the Theme Previewer, by chance? That’s something else we don’t have control over.

  • Chip Bennett 3:21 pm on December 14, 2012 Permalink | Log in to leave a Comment
    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 | 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 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