1. I know I don’t have Justin’s stature in the community, but I hope developers will consider taking a look at the Food and Drink Menu plugin for restaurants that I released a couple months ago. It’s also designed as a framework around which theme authors can build their sites, with a simple templating system, tons of hooks to filter and extend it with your own data, and support for multiple menus, shortcodes, widgets, etc.

    Food and Drink Menu:

    On GitHub:

    An introduction to the template system for theme authors:

    In the long-term, I hope to build a suite of companion plugins that will work as a comprehensive framework for theme authors to build restaurant sites, with support for table booking and other useful features for restaurants.

  2. This presentation-vs-functionality separation has been a struggle at times with the Theme Review Team, so I’m glad to see some of the bigger players making moves in the same direction.

    I believe that this approach will actually result in *more* innovation in Theme development.

  3. I really like this new direction that theme companies are taking. Personally what I think would be good is if the products are not “branded” i.e Projects by WooThemes. This will hinder other theme companies from using it because in the end they’re promoting their competitor’s plugin.

    A solution which I fear would happen is a bunch of forks of the same plugin with different branding. Now what is ideal is what Justin is doing with his plugins.

    A group of theme companies or developers need to join forces and collaborate on standalone projects rather than branding these simple but useful plugins. I think that way the entire community will benefit from it. Just my 2 cents.

    1. I was looking at Projects on WordPress.org and had the very same thought. I personally would not develop a theme with it for this reason. Even if it is only ever used for themes made by WooThemes, it’s still a useful thing, but if the idea is to make things easier for as many users as possible, multiple theme developers need to be using it.

  4. We talk a lot about data portability, but both Chip and Syed hit on some points that are truly at the heart of this for me. On the one hand, it’s about the users. On the other, it’s about designers having the tools they need at hand for creating cool themes.

    At some point in the past few years, theme designers also became plugin developers, mostly because we wanted to build themes that were beyond the standard blog design. So, instead of focusing efforts on actual design, more focus was put on development of features. This shifted the market toward big theme packages. Even though much of the code was open source, it started a dangerous trend toward a closed-source system where everyone had their own scripts that varied wildly. I don’t want to get into the economics of it all, but a lot of extremely good designers couldn’t compete with features.

    What I don’t want to see is a trend of everyone having their own plugin with their own branding. While I think competition is good, we need collaboration around a central project. If we have too many in-house plugins developed, it weakens the concept that many of us have been preaching.

    My ultimate goal is to see growing communities around specific plugins for things like forums (bbPress), e-commerce (Jigoshop, WooCommerce), portfolios, restaurants, and much more. When we have a major plugin or two to handle specific uses, it allows for much more innovation in the theme space. Theme designers can quit worrying about plugin dev and start designing awesome stuff.

    1. I’ve been itching to get a look at your plugin for a while. Great to see you’ve finally released it! I really wish you had responded when I contacted you last year asking to get involved. I was in the middle of writing my own solution, but would have happily jumped on your bandwagon. Without any communication from you regarding what kind of hooks you were planning, the template system you envisioned, long-term development plans, etc, I had to push forward with my own solution.

      I appreciate that the plugin may have been too early in development to bring in contributors/collaborators you don’t know, and fully understand your position. But to help me decide whether to push forward with my platform now or join forces with yours, can you provide some information regarding your plans for the following:

      1. How do you plan to handle the sorting and display demands of a restaurant menu?

      One of the reasons I was dissatisfied with existing solutions is that they all handled menus like any other custom post types — posts with archives. But restaurant managers typically want their online menus to mimic real-world menus, which means precise control over sorting order, categorization, multiple menus (I recently had a client with 3 menus for each of their 8 locations), etc.

      I can see that you plan to add taxonomies for meal times and courses, but from my experience the jump from data structure to presentation is incredibly difficult for lay-users (ie – customers). Have you considered any kind of layout manager? I know you want to keep the base plugin simple. I’m wondering how much of the sorting and display logic you plan to bake into the plugin or whether all of this will need to be handled with separate addons.

      2. Do you have any plans for integrating an addon shop into the plugin, or providing a centralized location for plugin authors to promote and sell their addons? EDD, for instance, provides strong sales opportunities for third-party authors. But not everyone is as welcoming. What are your plans in this regards?

      1. Sorry if I missed a comment you made or anything. I often miss things if they’re left on the blog, which is one reason I’ve moved to GitHub in the past year (for the collaboration aspect). The 95%-finished Restaurant plugin has been up there for several months.

        1) I plan on allowing add-on plugins to handle the more complex items. I’ve actually found the opposite of what you’re seeing. Most of the people I’ve talked to with small mom-and-pop shops and cafes tend to only need a single menu of items. So, that’s the base we started with. We wanted to shoot for the smallest of businesses with the initial plugin. Anything beyond that can be handled with additional plugins.

        For display and layout in general, that’s being left to theme authors. But, actual use cases help in this type of conversation.

        2) Theme Hybrid is already set up to allow third-party users to promote their stuff. Currently, we’re just doing this with themes. But, it’d be easy enough to open this up for plugin authors. However, as of right now, I don’t allow people to sell commercially through the site. Theme Hybrid has always been about $free plugins and themes.

        If we had enough developers on board, I could see the potential of having paid add-ons handled on a separate site. One thing I’d like to avoid is nickle-and-diming users for every feature though. I’d much rather see a healthy community around the free plugin and free add-ons. But, I certainly know that some advanced add-on stuff (reservation system, for example) might be better developed and supported commercially.

        1. Thanks for replying, Justin. I sent a message through the contact form on your site ages ago, so I guess it just went down some rabbit hole for spam. I probably should have followed it up more. Wish I’d found that GitHub repository earlier. Must not have looked properly.

          1) I guess with the display and layout issues, I was referring more to the backend interface a user would interact with. I’m sceptical that the default taxonomy interface is intuitive and easy for an end-user wishing to construct a menu. But this is a broader issue. I’ll spend some more time digging into your setup to see how easy it is to manage the menu.

          2) I certainly appreciate the need to have a robust free solution. And I don’t think restaurants are a large enough niche for there to be much profit in the nickle-and-dime approach to addons. For me, it’s just a question of market access. If I invest time into a plugin, I want to be sure that that plugin is discoverable for its target audience. Otherwise it’s useless for me. (We don’t all have profitable theme clubs. ;) ).

          Unless there’s anything you want to reply to here, I’ll move any future questions/comments to the GitHub tracker.

          1. 1) With the one and only taxonomy included, the WP meta box works. With the other taxonomies I have in mind, they’d probably work better with a custom meta box.

    2. I wonder if developers are concerned that making a free functionality plugin would be helping their competitors too much.

      – You help your competitor save time
      – You make it easier for your users to switch to your competitor

      Maybe these things motivate heavy branding?

      I think the issue of helping a competitor save time is unimportant. Building a theme is a piece of work whether or not a plugin is used.

      It is true that it will be easier for customers to switch to a competitor. I don’t see a big issue though because the competitors users can switch away just as easily. Equally easy is better than equally hard, which is mostly how it has been. Frankly, it will mean more sales all around, because it also means easier switching to a provider’s newer theme from an old.

      Then there are other added bonuses like increased awareness of your brand (even if it’s modest, it’s something), free code contributions from competitors, and the possibility of selling addon plugins to one’s own customers as well as competitors.

      Justin, I like that with Restaurants you say it is basic on purpose and that developers should make addon plugins for more sophisticated features. This completely parallels WordPress as core tool with an ecosystem of free and paid plugins for additional functionality.

      1. I wonder if developers are concerned that making a free functionality plugin would be helping their competitors too much.

        – You help your competitor save time
        – You make it easier for your users to switch to your competitor

        I think that’s short-sided thinking. Not only is the developer saving time for himself, but he’s also making it easier for his competitor’s customers switch to him. And, as you say: he’s also facilitating a larger overall userbase, by driving the underlying data scheme toward a standard.

        Besides: in a GPL environment, it’s not like a competitor can’t already see the developer’s code, and write a conversion/import script anyway. You’re never going to lock in customers by using a proprietary data scheme.

      2. I’m pretty much in agreement with Chip. Every time a competitor integrates his theme with one of my plugins, that’s one more potential customer that I didn’t have before. I can only see that as a good thing.

    3. So I was thinking about this today. There are plenty of theme frameworks and developers that use them. Why can’t there be the same type of effort involved with plugin frameworks? Church Content AudioTheme, and others are the plugin frameworks. They just need developers to be aware of them and use them instead of baking those features into the theme. I think the reality of the situation is that developers won’t stick to using one, two, or three plugins that handle a set of features for themes. Instead, I can see developers creating more and more of these plugin frameworks and now, we all end up in a similar but different rabbit hole.

  5. I so agree with this. It’s bad enough getting locked in with a plugin much less a theme!

Comments are closed.