24 Comments


  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.

    Reply

      • 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.

        Reply

        • That asynchronous code for Facebook apps (or for stats/Google tracking/etc.) absolutely belongs in a Plugin. I can’t think of a valid argument for having it in the Theme.

          Reply

          • 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.


          • Gonna have to agree with Chip here. I don’t see social media sharing as something that should be tied to themes.


          • I’m not really good at describing what I”m trying to get across. I’m not saying themes need to be tied to social media. My point seems to be getting missed, entirely.


          • 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.

          Reply

          • I would suggest as a theme author to find a few social media plugins that you do trust and that work well with your theme. When your theme detects one of the recommended plugins then output additional css or whatever that makes the plugin tightly integrated with your themes design. You could even put one click install links on your option pages for the recommended plugin for X.


          • No offense, but if it’s gonna be this way I’d rather write the plugin myself, because I’d know I’d likely be supporting it 5 years down the road. There’s a couple ways I’m thinking about spinning this off, involving either a “complimentary” companion plugin to provide functionality for GA, sharing, and the likes, or a “add-on” at an additional cost.


          • Nick: CyberChimps does this via the Responsive Addons plugin for their Responsive theme. It adds a bunch of functionality to Responsive and is a recommended download after you install the theme, but even if you don’t install it, Responsive will work fine. I like the approach. Addons become an optional upgrade rather than core functionality.


          • That’s actually the same idea that I was thinking on taking as well. It makes sense and happy to comply with best practices.


  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.

    Reply

    • 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.

      Reply

  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.

    Reply
  4. Chris

    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.

    Reply

    • 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.

      Reply

  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.

    Reply

  6. Why dont we just create something new and call it PluginThemes. Then you can put your features and design all in one. Then, we’ll all be happy and still play by rules. :)

    Reply

    • Technically, you can already do that. Just create a plugin. Then, you can set it up to actually contain a theme or multiple themes. It’s fairly easy to do. You can create an all-in-one system to do things however you like.

      Reply

    • I wrote about this issue in a post I wrote a few weeks ago (http://www.peterrknight.com/wordpress-in-2014-predictions-and-frictions/). I wonder if something could evolve that thinks in terms solutions that can be installed as packages. On a file level, you’d maintain the proper distinctions between plugin and theme, but the installation process would be less fragmented and solutions that involve a combination of things would be much easier to install and market.

      Reply

Leave a Reply