Theme Review Guideline Revisions Proposed For WordPress 3.9

Chip Bennett has outlined a list of proposed changes and revisions to the WordPress Theme Review guidelines. The changes are listed in two sections, required and recommended. The required changes would take effect immediately while those that are recommended could become guidelines in the future. Some of the recommendations include:

  • Bundled Plugins: Themes must not bundle Plugins.
  • Arbitrary Header/Footer Scripts: Themes must not provide Theme options for arbitrary header/footer scripts.
  • License: Themes are required to document in the Theme readme file the copyright/license attribution for all bundled resources.
  • Theme Credit Links: ThemeURI and AuthorURI, if both are used, must be from distinctly separate sites.

The guidelines and recommendations are currently in the discussion phase. If you’re a theme author and have additional recommendations or guideline please provide your input on the post. There’s already a lively discussion underway.


24 responses to “Theme Review Guideline Revisions Proposed For WordPress 3.9”

  1. The header/footer scripts is a hard one to grasp, only when related to social sharing (i.e., user inputting facebook app id for rich sharing/fb likes) implementation with posts as a specific use case I suppose an extensible theme with actions that a plugin could hook into, to place the social sharing icons/buttons is what is recommended, but this solely depends on the plugin itself being extensible as well. Extensible as in, I want to control 100% of how the icons/buttons look and operate.

    In a sense, relying on a 3rd party to provide social sharing in your theme, and make it look good, is risky.

    Knowing this, it’s easy to understand why this particular use case is common in themes. Why muck around with finding the perfect social plugin to compliment your publicly distributed theme, and take the chance of the plugin either messing up, or straight making the theme look like ass, when you could just as easily build it in yourself.

    It’ll be interesting to see where this goes. While I do agree that functionality is best served in plugins, there is still some justification for theme based functionality, to a certain extent.

      • Yep, I’ve been utilizing that technique for quite a long time. This is actually how the main demo theme of Aesop is run.

        The problem is with Facebook.

        A lot of users have apps associated with their sites, which tracks sharing, etc, and that requires an App ID to be entered by the user.

        That asynchronous code still needs to be in header/footer. Sure you could just use the straight sharing links, but that won’t connect to your fb app.

          • I simply can’t trust leveraging a 3rd party plugin to provide sharing in a publicly distributed theme, and make it look good, without any issues. I’ve been burned by one to many vendors, which in turn reflects badly on the theme author.

            What happens when the plugin isn’t supported anymore? You work more to find another plugin that works with the theme to recommend to users when they are complaining that your theme doesn’t’ incorporate social sharing?

            I don’t see that being sustainable, in the long term.

          • You’re talking about several different things here, all of which may be handled similarly or differently:

            1) Social network profile links
            2) Social content-sharing buttons
            3) Header/footer scripts

            There is an argument to be made that social content sharing links in a Plugin may not be able to be as tightly integrated into a Theme’s design, but there are alternatives: make the Plugin output overrideable via CSS, implement standard template hooks (such as the Theme Hooks Alliance) to allow the Theme developer control over where the links are displayed, etc.

            But for header/footer scripts: those belong in a Plugin. That’s what I’m talking about when I say that I can’t think of a valid argument for having them in a Theme.

            • There is an argument to be made that social content sharing links in a Plugin may not be able to be as tightly integrated into a Theme’s design, but there are alternatives: make the Plugin output override able via CSS..

              Thanks for seeing that point I was trying to make. It depends entirely on the plugin being reliable, trustworthy, and most importantly, extensible.

        • That type of code sounds just like Google Analytics code and how it needs to be within the footer of a theme in order to register stats. It’s not good to have it tied to a theme as I myself found out when I switched themes. Now I have a 2 week gap in my stats data. If it needs to be in the footer or the header, a plugin should do that so switching themes doesn’t alter the functionality of that code.

  2. I believe that there is a fine line between what needs to be bundled and what doesn’t.

    In the case of social sharing, adding a simple set of buttons to the theme, shouldn’t be a big issue and should definitely remain core to the theme. If it is going to be a lot more advanced then maybe it should go into a plugin.

    A mid-way solution could possibly be to have the theme recommend and prompt a set of plugins that best work with the theme. The output of these plugins can be integrated in the theme code so that it doesn’t need a user to try to style them and make them look good.

    • The questions I would ask to determine if social content sharing links are appropriate in a Theme:

      1) Are they related to presentation of user content, or are they related to site functionality?
      2) Would the user have a *reasonable* expectation that they would be retained when switching Themes.

      Social content sharing links are functional, not presentational. They’re (generally) completely agnostic to the Theme. And users *do* have a reasonable expectation that they would be retained when switching Themes.

      IMHO, social content sharing links fall pretty squarely in Plugin territory.

  3. One other thing that I wanted to clarify a bit: The *Recommended* Guidelines serve a couple of purposes: they may be Guidelines that we want to make *Required* in the future, but need to provide time and education for implementation before making them required; but they might also simply be things that we consider as best-practice implementations, and highlight as “Recommended” in order to help facilitate/drive adoption of the practice.

    If it’s something that we’re hoping to make “Required” at some point in the future, we’ll usually mention that, as well as some kind of timeline. If it’s something that we’d *like* to make “Required”, but don’t know if doing so would be feasible, we might just make it “Recommended”, and then gauge adoption and implementation issues.

    But at this point in the maturity of the Guidelines, I’m more interested in helping to drive Theme development best practices. Other than Guidelines changes driven by changes to core or new features in core, the Guidelines don’t generally change that much at this point. We’ve established a pretty solid baseline for Theme quality. We’ve got a great opportunity to engage the Theme developer community, and to be a leader and hub for collaboration, education, and development of best-practice consensus. That’s why things like using custom nav menus for social profile links might show up as “Recommended” in the Guidelines.

  4. I’m so glad that this discussion is finally happening.

    I’ve had to migrate sites with “Themes” that did everything but replace WordPress. And clients can’t understand why the new theme they chose doesn’t have SEO, YouTube Players, Sliders, MegaMenus, FAQs, Advanced Galleries, and smellovision the way their last “theme” did.

    I will be so happy when the standards line is finally clear between theme and plugin as it is between the code and visual.

    I can see a space in the middle where theme plugin interface standards could be managed so that themes could *optionally* control visual aspects of plugin functionality. And where a theme didn’t specify visual control then the plugins could have some freedom.

    I guess theme developers should all be happy that social plugin developers don’t want to control how themes display their plugin’s output.

    “But I want to use CSS to do the FTP.”

    As with haikus, standards and design restraints inspire powerful creativity–not limitations.

    • I’m so glad that this discussion is finally happening.

      We’ve been having this discussion – which in all honesty feels more like “fighting this battle” – for some time now on the Theme Review Team. We have had a “presentation vs functionality” Guideline for a very, very long time; the controversy usually erupts over the question regarding what is functional and what is presentational.

      At times it’s been difficult, but I think more and more developers are understanding the meaning and wisdom of separating functionality and content generation from content presentation. But it’s a discussion – or a fight – I’m willing to participate in, because I believe strongly that it is end users who gain or lose from getting that separation right.

  5. I have said this many times in the past: SOCIAL SHARING on themes is completely wrong.

    What if I switch to another theme? because I want one or the author abandoned it or whatever reason.

    Those sharing tools will not be there on the new theme.

    Right now to all my social media profiles, are on a text widget with old a href img src link. If the theme has it, and I change it then those links go.

    I have never EVER kept a theme for over a year. Partially due to not being compatible with a WordPress version.

    Doesn’t JetPack have a sharing module?

    Edit: All my social media icons are on my uploads folder and not on a plugin’s folder.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: