Make WordPress Themes

Updates from Frumph Toggle Comment Threads | Keyboard Shortcuts

  • Frumph 6:22 pm on January 28, 2011 Permalink  

    Agenda for 01/29/2010 WPTRT 

    IRC Channel #wordpress-themes
    #freenode
    10am EST. Saturday

    Theme Out Of Date -
    1. Code the search to not include themes out of date, create new search for out of date themes – big “out of date” marker on the theme page for themes that are past a certain point.
    2. Suspension for themes that haven’t updated past a certain point.

    Swap out a couple of the featured themes.
    Finalize Child Themes on repository guidelines for reviewing. (and recommendations to consider to core devs if any implementation is necessary)
    WPTRT Base Theme
    SEO Discussion Site vrs SEO Sales site, author uri, theme uri – this one is a given that a theme uri must point to a page specifically for the theme and author uri must point to a developement page for the author if the main author’s page is not a general blog site for the developer.

    Anything else anyone want to toss in?

     

    • Chip Bennett 7:10 pm on January 28, 2011 Permalink

      Draft Security Guidelines/Checklist
      Review Queue Status / Review Quota Commitments

    • Frumph 7:37 pm on January 28, 2011 Permalink

      ^ Need Otto’s opinion on if theme out of date by date queries can be adjusted, example adding AND DATE > $outofdate and making a seperate search query for those that are out of date, and the out of date button based on the update date on the theme and the global $outofdate that’s set?

      • Frumph 7:44 pm on January 28, 2011 Permalink

        Also child-theme tag and post-formats tags wanted to implement, added to questions for otto

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

      What’s the WPTRT Base Theme?

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

        Tune in tomorrow to find out. ;)

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

        Aw, man. I guess I’ll be reading the logs. :) Or will there be a recap posted here?

    • Frumph 8:01 pm on January 28, 2011 Permalink

      Couple of things, it’s the getting rid of P2 on here and using twentyten – and we’re discussing putting together a theme with best practices that could be used as a reference along with twentyten for various coding functionality

      • Rahul Bansal 5:26 am on January 29, 2011 Permalink

        This seems a great thing to do. Many new theme-developers will save their own time and time of reviewers!

    • Frumph 1:32 pm on January 29, 2011 Permalink

      Addition, look into getting email address for the leads cais and pross, to send email notifications for ‘please update your theme’ and possible future suspensions, etc. – based on Ian’s recommendations below

    • Andrew Nacin 12:53 pm on February 7, 2011 Permalink

      A few notes, as a drive by:
      – Infrastructure and preparation are good, but we’re not sure if we want to see child themes in the directory until we can deal with them from the core side. We’re planning on that for 3.2, and it’s something I’ll work on with Otto from each end of the candle.
      – A base theme sounds kind of like Twenty Ten :-)
      – I think P2 is best here if this blog is about conversation and planning.

      • Edward Caissie 1:27 pm on February 7, 2011 Permalink

        A “blog” using P2 as its theme would generally be “about conversation and planning” but that is not the pidgeon hole the WPTRT had in mind for this site.

      • Chip Bennett 1:58 pm on February 7, 2011 Permalink

        No offense, but shouldn’t the people primarily charged with using this site (i.e. the WPTRT members) be the ones best-suited to determine whether or not P2 is most appropriate?

        We don’t intend to take the same tack as, say, wpdevel, with our use of this site. I think that one of our primary objectives is to use this site as an educational tool/resource, which would include a lot of tutorial-type blog posts. P2 is not so well-suited toward this end.

        I should note, also, that any Theme that supports threaded comments will serve equally well as P2 with regard to furthering discussion.

        Finally: we have had many, many issues with comments not posting immediately/at all with P2 – something that is rather counter-productive to the end of encouraging commenting/discussion. As a function-over-form type of person, this drives me crazy. For all I care, we could run TwentyTen on this site, and it would serve us equally well. (Though I wouldn’t mind giving Pilcrow or Coraline a spin.)

        • Andrew Nacin 2:44 pm on February 7, 2011 Permalink

          If comments aren’t posting, that’s going to be an issue regardless of the theme. It’s something I plan to look into this week and next.

          • Chip Bennett 11:04 pm on February 7, 2011 Permalink

            I respectfully disagree. We are hearing multiple instances of issues with the AJAX-ified comment form simply hanging on submit; also, sometimes comments appear in the backend, but not on the front end – all kinds of wonky problems. Maybe it’s a problem with the make.wordpress.org WP install, but I’m much more inclined to suspect P2. (The easy way to find out, of course, would be to switch Themes and observe whether or not the problem persists.)

            Nevertheless: regardless of our reasons, why should we have to 1) ask, and 2) justify our decision, to switch Themes? (I’m sure this limitation applies to all teams using make.wordpress.org sites; I realize we’re not alone in this regard.)

          • Lance Willett 12:41 am on February 8, 2011 Permalink

            I think it’s not P2 but something weird with this domain and cookies. When I access this site with Safari I appear to be “logged in” here, even though I’m not a user on this site. Is make.wordpress.org using WP.com cookies for anything? When I post from Safari the comment from spins endlessly and doesn’t ever post.

            If I access with Firefox I do not appear to be logged in, and I just enter my details and comment without a problem.

          • Andrew Nacin 1:55 am on February 8, 2011 Permalink

            It’s definitely some funky WP.org stuff we have going on. It’s not P2, and while it may be exacerbated by P2, it’s something we have to fix, not just for this blog.

            The only reason I suggested that P2 makes sense, is that ideally the make.wordpress.org blogs (and there will be more soon) are designed around the need for conversation, collaboration, coordination, and communication among people contributing to, in this case, the theme review process. Informative blog posts sound more like Codex or handbook articles. But we can discuss further.

            It’s not about you needing to justify anything. More to the point, no team is or should be autonomous — we’re all gears in a larger machine, with a lot of overlap. Any recommendations ultimately trickle down and bubble up to affect many other working groups, developers, and users.

            That these various groups (UI, theme reviewers, etc) can operate independently is fantastic. But the’re naturally full of interdependencies, and they all are delegated extensions of the project leadership. This is especially important when fulfilling the various visions and long-term goals of what we want WordPress and wordpress.org to be.

            You guys do great work and I want to help more than I interfere — just looking out for you guys.

            • Edward Caissie 3:27 am on February 8, 2011 Permalink

              The only reason I suggested that P2 makes sense, is that ideally the make.wordpress.org blogs (and there will be more soon) are designed around the need for conversation, collaboration, coordination, and communication among people contributing to, in this case, the theme review process. Informative blog posts sound more like Codex or handbook articles. But we can discuss further.

              This is the sort of communication we need to go forward with … and would have helped to better understand your earlier comment. Do we have any ETA for the “fixes”? This may essentially only be affecting this particular installation but it is a source of frustration and it would be great if it could be addressed sooner rather than later.

          • Edward Caissie 7:24 pm on February 8, 2011 Permalink

            Not sure if this is related to the issues on the site but I keep getting this script issue being reported:

            Script: chrome://afterthedeadline/content/atd.js:675

            … while browsing with Firefox.

      • Chip Bennett 2:15 pm on February 7, 2011 Permalink

        Oh, regarding Child Themes: I don’t think we are intending to drive any particular implementation path or date; we just want to make sure that we’ve got our infrastructure (i.e. Guidelines, workflow, etc.) in place, so that when the “switch” is thrown, we’ll be ready to receive and process submitted Child Themes.

        I like the thought that we’re looking at something at least as far out as 3.2. It gives us both the time to plan properly, and also a tentative target to which to point developers who inquire about implementation.

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

    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?

  • Frumph 9:10 am on January 21, 2011 Permalink  

    Obsolete – No longer active themes – Discussion 

    These themes have been processed by the Theme Review Team to be determined to be justifiable to suspend
    from the repository for one of the following reasons

      • Splog links – links go to spam blogs
      • invalid license information that is not gpl compatible or font license not found (1) or non-gpl restriction with footer credits
      • not-working theme just not function with latest wordpress
      • missing completely, svn not associated to the post of the theme

    Splog Links in theme/author uri or theme uri or SEO seeded or even hardcorded backlinks

    http://wordpress.org/extend/themes/bluesky

    http://wordpress.org/extend/themes/happy-cyclope

    http://wordpress.org/extend/themes/gone-fishing

    http://wordpress.org/extend/themes/yb-auto

    http://wordpress.org/extend/themes/midnight-blue

    http://wordpress.org/extend/themes/the-knife-wp

    http://wordpress.org/extend/themes/studiopress

    http://wordpress.org/extend/themes/black-on-white-serif

    http://wordpress.org/extend/themes/flexi-blue

    http://wordpress.org/extend/themes/yb-light

    http://wordpress.org/extend/themes/nishita

    http://wordpress.org/extend/themes/descartes

    http://wordpress.org/extend/themes/chinese-love

    http://wordpress.org/extend/themes/simple-blue

    http://wordpress.org/extend/themes/styleicious

    http://wordpress.org/extend/themes/jas-personal-publisher

    http://wordpress.org/extend/themes/rotate-text

    http://wordpress.org/extend/themes/diana

    http://wordpress.org/extend/themes/citrus-mix

    http://wordpress.org/extend/themes/clear-seo-blue-eng

    http://wordpress.org/extend/themes/kitten-in-pink

    http://wordpress.org/extend/themes/sharp-orange

    http://wordpress.org/extend/themes/baltimore-phototheme

    http://wordpress.org/extend/themes/citrus-mix

    http://wordpress.org/extend/themes/small-business-seo

    http://wordpress.org/extend/themes/deepblue

    http://wordpress.org/extend/themes/wp-bats-theme

    http://wordpress.org/extend/themes/simple-blog-design

    http://wordpress.org/extend/themes/simple-blog-design-2

    http://wordpress.org/extend/themes/blog-design-studio-newblue

    http://wordpress.org/extend/themes/myblogstheme

    http://wordpress.org/extend/themes/spanish-translation-us

    http://wordpress.org/extend/themes/planetemo

    http://wordpress.org/extend/themes/contrast-style

    http://wordpress.org/extend/themes/shoot-it

    Non-compatible Licenses

    http://wordpress.org/extend/themes/jnb-multicolor-theme

    http://wordpress.org/extend/themes/superfresh

    http://wordpress.org/extend/themes/christmas-1

    http://wordpress.org/extend/themes/harvest

    http://wordpress.org/extend/themes/medieval

    http://wordpress.org/extend/themes/the-lord-of-the-rings

    Theme has no svn

    http://wordpress.org/extend/themes/thistle1

    Unknown – possible copyright infringement on design /maybelist

    http://wordpress.org/extend/themes/facebookwb

    Broken Theme – needs updating

    http://wordpress.org/extend/themes/keke

    http://wordpress.org/extend/themes/black-green

    http://wordpress.org/extend/themes/modern-blue

    The pages we chose to review were based on the furthest updated, the themes are on the last pages found in the repository. There were a total of 120 themes checked, 104 of which were originally written as recommendation of suspension, clearing up the ones that were just no license information and other minor nuances made the list above.

    The themes listed above represent only a small fraction of available themes on the repository that are outdated and way out of bounds for the guidelines.

    This topic is to discuss the plans as such for obsolete themes that remain in the repository that do not meet even the minimal of guidelines that go against most of our opinions of what the free available themes in the repository should be representing as well as how to handle those.

    Beyond this current list of those which are to be suspended, the time allotted to do both the theme reviews and verify older themes in the repository does not make it possible to functionally do both. 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.

     

    • Rahul Bansal 9:21 am on January 21, 2011 Permalink

      Question – If theme “thistle1″ didn’t have SVN, how was it submitted?
      And also in that case – won’t be adding its code into SVN be enough?

      As theme developers we cannot do SVN IMPORT inside wordpress theme repo as far as I know. Right?

      • Frumph 9:37 am on January 21, 2011 Permalink

        It just means it’s a bug, the theme was probably removed without the post being removed due to some situation which warranted it.

        • Peter Westwood 10:01 am on January 21, 2011 Permalink

          Indeed. I suspect if you go back through svn history you will find it there.

        • Rahul Bansal 10:40 am on January 21, 2011 Permalink

          I am not aware of backend of theme repo. Hope its wordpress only!

          In any case SVN Hooks can be used to automatically keep SVN & Repo in-sync. Just my $0.02…

          • Frumph 10:49 am on January 21, 2011 Permalink

            It’s bbpress with svn, and they’re hooks in place, this is just happen to be one that fell out of place, but the topic really is discussing the suspension of outdated themes

    • Peter Westwood 10:02 am on January 21, 2011 Permalink

      I guess we should contact all of these theme authors and ask them if they want to submit an updated version to resolve the issue (within an agreed timeline) or they are happy for us to remove them.

      This ensures they know beforehand that they are being removed.

      • Frumph 10:03 am on January 21, 2011 Permalink

        Is that possible that we can gather emails together from a certain timeline for a form email to be sent?

        • related note, half of those do not have contact information; would have to get their emails from their registered logins –

      • Chip Bennett 4:43 pm on January 21, 2011 Permalink

        For particularly egregious issues (malicious code, spam links, non-GPL license/restrictions, the modus operandi has been to suspend first, then inform. Is there any reason not to do so in this case?

        Note that suspended Themes can be un-suspended if warranted, or a new version can be submitted and approved for the repository.

        But the things listed here really have no business being distributed via the official repository, and when found in on-off circumstances, are suspended immediately.

        • Frumph 4:51 pm on January 21, 2011 Permalink

          ^ I’m in favor of the email first method, at least it gives us ‘reasonable attempt at contact’, which is a good in the eyes of people who are viewing our actions.

          I’m more concerned about the fact that this was a tedious task just to get these ‘samples’ of themes, which unfortunately we’ll never be able to do again to even remotely make a dent in cleaning up the archives of themes.

      • Frumph 7:55 am on January 22, 2011 Permalink

        Emails were sent out, Karen has kindly opted to give her themes up for adoption when the adoption program starts to developers who would like to take them over. Several other responses were all in the positive for the updating of their themes.

    • Edward Caissie 12:32 pm on January 21, 2011 Permalink

      The theme author emails are available from the repo admin, I can marry up a list of author emails to the above themes listing later today.

    • Otto 2:29 pm on January 21, 2011 Permalink

      Question: What is the licensing issue with http://themes.svn.wordpress.org/the-lord-of-the-rings ? I see no mention of license in the theme.

      Ditto for:
      http://themes.svn.wordpress.org/medieval
      http://themes.svn.wordpress.org/harvest

      • Frumph 4:07 pm on January 21, 2011 Permalink

        Daniel noted those 4 including the christmas-1 to be: Licensed under CC-BY 2.5 in the notes so, unsure how she derived to that conclusion, again probably a good reason to have a blanket-by-date update your theme notice sent out.

        • Chip Bennett 4:21 pm on January 21, 2011 Permalink

          Did you check Author URI, to determine if the Theme developer referenced license terms on her website?

        • Frumph 4:26 pm on January 21, 2011 Permalink

          “I’m releasing this under the Public Domain so do with it what you please and enjoy! I would, however, love to hear from you if you do decide to use it.” is all she puts on the theme page for it.

          Love their latest post though “backlinking at no cost” to quote it “Give something away for free with a link to your website embedded in it, like an ebook, report, templates, themes, apps, etc.”

      • Chip Bennett 4:36 pm on January 21, 2011 Permalink

        See here: http://themes.svn.wordpress.org/christmas-1/2.0/style.css

        “License: This theme is released under the Creative Commons Attribution 2.5 license so please leave the credit in the footer intact.”

        The other three by the same author, however, appear not to have any licensing information at all.

    • Sayontan 6:41 pm on January 21, 2011 Permalink

      The author link on these themes directs to a debt relief site:
      http://wordpress.org/extend/themes/flora-relief
      http://wordpress.org/extend/themes/dark-relief

    • Payday Designs 4:38 am on January 22, 2011 Permalink

      Why my theme all-green get suspended? What was the issue there…

      • Frumph 7:10 am on January 22, 2011 Permalink

        I am not seeing all-green on any of my lists for suspension, i’ll inform Cais or Pross to look into it.

        • Payday Designs 7:14 am on January 22, 2011 Permalink

          Thanks friend… I also get amazed when i saw it suspended as I am learning theme development and feedback from you guys is really make my learning easy.

          Thank You again

          • Frumph 7:17 am on January 22, 2011 Permalink

            No worries, I’m sure you’re answer will be handled very shortly the admins are incredibly good at what they do.

            Did you get an email from me or anyone concerning it? There were a few emails concerning some suspensions happening in the future as a notice to please update their theme

            Of course it’s way after midnight out here so might need to give them time wake up and get some coffee ;)

            • Payday Designs 7:18 am on January 22, 2011 Permalink

              I havent received any email

            • Frumph 7:43 am on January 22, 2011 Permalink

              I’ve got your answer for you, it was quite a debate on the theme-reviewers mailing actually.

              Cais the lead suspended it on practically everyone’s recommendation to contact you to update it and that it was a ‘mea culpa’ situation on the accidental approval in the first place. For you not being contacted and having the ball drop on that I do apologize; You are actually the first i’ve heard of this. However I do note that Cais requested someone to email you, apparently no-one did which now falls to me.

              The issue is that the functionality of all-green is that of twenty-ten, it’s basically a child-theme in the matter that all of your coding for the functions.php is that of the twentyten theme, the only thing that was changed was graphics. In these cases derivative works are not permitted on the repository if they are this close; to just being some style and graphic changes – which in all practical purposes makes them a child theme.

              There is a fine line there however, if the theme added a different functionality to the theme even so minute to make it a clear difference from the stock twentyten that would be permitted, unfortunately as I look at this code – this theme does not – on a good note you did change the text domain.

              The suspension is only temporary until you make the theme a clear difference or change in functionality of the twenty-ten theme *otherwise* if you wait a little time you can re-upload it specifically as a child-theme which will be allowed for the theme repository coming somewhat in the future.

        • Payday Designs 7:54 am on January 22, 2011 Permalink

          Ok Fine… I will make it different and will re-upload it… also I have submitted 2nd theme named beauty-dots … its still pending and haven’t received any reply. If it can be approved or feedback on that. I will also help me in my future learning. Thanks

          • Frumph 7:57 am on January 22, 2011 Permalink

            Ah yeah, that one, since we have inadvertently made the mistake of not emailing you in a timely fashion or dropping the ball on the other one, if you go to the IRC channel I can talk up on there and give you a review and help you sort things out right away if you like.

            • Payday Designs 8:02 am on January 22, 2011 Permalink

              ok i join there

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

      I haven’t yet seen any discussion of this point, 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.

      We very much want input and feedback on this proposal.

    • Payday Designs 2:50 am on February 15, 2011 Permalink

      My theme get approved… but not showing in list… Beauty Dots 1.0.6

      Can any one help why?

  • Frumph 5:47 pm on January 5, 2011 Permalink
    Tags: Menu Location,   

    Discussion on menu locations for theme options. 

    This post is to discuss the use of add_menu_page and add_submenu_page usage for theme options.

    When reviewing themes, the thoughts of usage are in several different camps at the moment and we’re looking for your opinions as well.

    The first thought is that the dev and theme team want to strongly push developers to utilize as much of the consistency of the UI and API as possible which means when locating the options for a theme it should be found under the WP-ADMIN -> Appearance section of the menu.

    Another thought is that if the theme itself is large enough to warrant using it’s own top level menu option, what would be the criterion of that, how much is enough? could those submenu pages inside the top level (add_menu_page) be necessary to be placed as a top level and not options tabs of some sort inside the theme options page itself.

    What are the cons of using a top level?

    • It could be using an menu anchor # that a plugin uses to display it’s menu on, so one or the other will disappear.
    • It’s not conducive to the consistency that some people would like to see the wp-admin steer towards, the commonality of finding options in the appropriate places.

    What are the pros of using a top level?

    • Can be described to end users easier? (rough one)
    • Can be used to attach theme-based plugins to, for example a plugin can create a top level submenu item *onto* that top level theme add_menu_page to keep everything nicely bundled together.

    In my opinion a theme developer if they have theme options, it should indeed be found in the appearance -> section of the wp-admin; if that top level itself doesn’t have sub menu pages

    • Looking for feedback, opinion’s and idea’s towards finalizing a recommendation, requirement for the theme review process.
     

    • Devin 6:28 pm on January 5, 2011 Permalink

      I agree that most everything having to do with theme’s presentation should go under the “Appearance” tab. If the theme options are really large, it can have some sort of tabbing mechanism in it on that page- like /wp-admin/themes.php (or many other plugins that do this with links across the top, etc).

      If there’s a ton of customization options for things like breadcrumbs, sliders, etc, the theme author might think about offering plugins that can be downloaded and integrated with the theme, but not make it dependent on them.

      • Frumph 6:36 pm on January 5, 2011 Permalink

        The whole ‘should this theme option be a plugin’ instead of inside the theme options is actually coming up as a different discussion, looking forward to peoples opinions on that one as well.

      • Peter Westwood 11:10 am on January 6, 2011 Permalink

        If the theme options are really large,

        If the theme has too many options to sit on a single setting type sub menu page then it probably has too many options IMHO.

        • Edward Caissie 8:24 pm on January 6, 2011 Permalink

          +1! (Hit too fast.) I absolutely agree some themes have too many options if they cannot get them all onto a single “settings” sub-menu item.

    • Chip Bennett 7:32 pm on January 5, 2011 Permalink

      Can sub-pages themselves have sub-pages?

      I’d like to see a few examples of Themes that currently use top-level menu entries with sub-pages. My suspicion is that Theme sub-pages are not needed for the vast majority of current use cases – though in no way do I think that to be true universally.

      Other Theme developers: what do you see as the pros and cons of top-level versus sub-Appearance menu entries for Themes?

    • Edward Caissie 8:34 pm on January 5, 2011 Permalink

      I would imagine the first place to look for a Theme’s optional features, if they exist, would be under the Administration Panel’s Appearance menu; and, depending on the implementation and setup of a self-hosted WordPress installation, adding a top-level menu may simply create clutter and, as noted, potentially clash with a plugin … but I also see very few plugins that should be creating top-level menu items in the Administration Panels, too.

      • Frumph 8:41 pm on January 5, 2011 Permalink

        Plugins is relevant definitely, On the counter argument on plugins to sidestep is that if you look at the plugin eShop it has how you like it, an options menu item in almost *practically* every top level menu area which would be better if they were all bundled together.

        If we had a line for themes, where would it be the point of crossing?

        • Edward Caissie 1:14 am on January 6, 2011 Permalink

          If it were to be a requirement to keep Theme options under the Appearance menu then it would force designers and developers to adopt (hopefully) better practices, such as using the Setings API; and also push them to create better self-contained option panels as well. Basically following similar methods already being using in the Administration Panels, for example the Install tabs found under Themes and Plugins.

          • Frumph 3:20 am on January 6, 2011 Permalink

            In my opinion, yes, recommended unless good reason not to, good reason being that it is encapsulating special requirements that hook into it.

            As far as Settings API, Background and Custom Header, and the add_theme_page() w/ ‘edit_theme_options’ I would consider those to be 3.1 worth enough to toss as highly recommended. Which does not mean requirement, but stated as such in both the theme-check and the uploader.

    • Justin Tadlock 9:01 pm on January 5, 2011 Permalink

      99% of the time, theme settings pages should go under the Appearance menu. This is the designated WordPress place for it, and WordPress also lists these menus underneath the activated theme on the themes page.

      A theme can also add multiple menus under Appearance, so that can take care of many instances where sub-menus are used but not needed.

      However, there are cases where a top-level menu might be needed, so we definitely shouldn’t rule it out altogether. I just haven’t seen such a case in a theme. And, it only makes sense if this top-level menu needs sub-menus.

      Themes should be using add_theme_page(). The capability parameter should also be edit_theme_options (I’ve seen everything from level checks to edit_posts in different themes).

      Related: We should really be making a push for themes to use the Settings API for theme settings. I’m seeing tons of generic scripts that offer no validation/sanitization of options before inputting them into the database, no nonces, and no escaping on output within form elements.

      • Andrew Nacin 3:39 am on January 6, 2011 Permalink

        I strongly second and confirm everything Justin has said down to every last detail, and have nothing further to add.

        Footnote: In 3.2 I hope to make the Settings API allow for edit_theme_options (it currently forces manage_options). But I feel you should still leverage it, as only Administrators have both by default.

    • Pritam 4:23 am on January 6, 2011 Permalink

      I guess the theme review team should provide a sample theme-options page that comply with all the guidelines. Theme authors can use it to build their own options page. For Shaan WP theme (available in the repository), I tried to build a famework (which has lots of holes and limitations). This options page can be easily modified by even a novice. Something similar can be very helpful for theme authors.

      • Frumph 6:09 am on January 6, 2011 Permalink

        Back to education, of course documentation will have to be provided, although I’m unsure who provides the documentation it should be linked somewhere to tutorials in the least, absolutely.

        • Jane Wells 11:48 am on January 6, 2011 Permalink

          Daisy Olsen has been working on an outline for a Theme Dev Handbook. Will ask her to join this group.

    • Jane Wells 11:54 am on January 6, 2011 Permalink

      It should pretty much always fall under the Appearance menu, because that is where users can count on everything appearance-related being, including theme selection and management regardless of theme. The fact that plugin settings are not standardized in one of the more frequent complaints from users, so I would not like to see us promoting non-standard placement of theme options. That said, some themes go so far into plugin territory that a particular set of options might be better found in Settings than Appearance (such as a theme with a bunch of SEO settings). Once a theme sets up a top-level menu instead, it breaks the pattern that users have learned about how things are grouped in the Admin. Top-level menus generally should only be created if it’s for an entirely new content type (like Products, Real Estate Listings) or an entirely type of utility (like Stats, Backups). Most themes and plugins that create top-level menus seem to do it for branding purposes, not for ease of use, which is not something that should be recommended.

    • Frumph 6:07 pm on January 6, 2011 Permalink

      It looks like we have a mutual consensus of usage and we should implement this into the guidelines and theme review process.

      • Edward Caissie 8:45 pm on January 6, 2011 Permalink

        Agreed. The gist of this discussion should be showing up as a requirement to coincide with the 3.1 release. We can then work from that benchmark furthering the requirements with 3.2.

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