Plugins as a Platform: The Future of WordPress Plugins

Filed Under

Published

May 13, 2014

7 Comments

Last week, MaxGalleria announced Version 2.0 of their gallery plugin. The update featured a bit of a change in scope for the plugin. The team decided to shift it from a simple plugin to a much more complete gallery platform. Though the core functionality is remaining more or less the same, it’s far more extendable now than ever before, with over a 100 actions and filters for developers to hook into. This means that the core plugin will remain fairly slim, while facilitating a number of add-ons either in the personal or commercial space. MaxGalleria likened the philosophy to that of WooCommerce and Gravity Forms.

Plugins as a Platform

The announcement from MaxGalleria got me thinking about what the future of plugins might end up looking like. After all, WordPress itself is shifting from a blogging platform/CMS to a full application foundation. Eventually, WordPress would like to get to a point where its core functionality can be used to set up the basics, like user authentication, routing, and data schemas. Then, developers can build on top of ad infinitum to create a modern web application. If that’s the case then more niche platforms will need to be developed on top of it. That’s where plugins come in, what the MaxGalleria team called “Platforms on top of Platforms.”

The basic idea is simple. WordPress itself should be getting leaner, not more robust in terms of its core. Its true strength, though, lies in how easy it is to use the WordPress API to do basically anything. But WordPress hooks can’t do everything. If a specialized need comes along, then another platform might have to be molded on top of WordPress to allow for more specialized hooks and finer tuned extendability.

It’s All about Patterns

If you’re a programmer, chances are you’ve heard of DRY programming. But if you haven’t, the concept is pretty simple. DRY stands for Don’t Repeat Yourself, and it’s the foundation of many programming techniques. When a programming pattern is created over and over again by individual developers, chances are it can be modularized and built into a small component that can be fit into any project. For instance, the world would go crazy if developers had to custom code a user authentication system every time they started a new web app. So WordPress makes things easier by offering this out of the box.

But let’s say a developer wants to add a shopping cart to their application. This is a use case that’s fairly common, but not quite common enough to make it into core. Should every developer that wants to incorporate a shopping cart have to code it up from scratch? Of course not. That’s where a plugin comes in. In the past, plugins needed only to provide the functionality itself, and maybe a shortcode or visual editing component. But the demands of WordPressers have increased quite a bit. We need to be able to easily bolt on a shopping cart, but then extend it if necessary. And in order to do that, we need a proper development API.

And that, I believe, will soon become the role of plugins. To identify the reusable bits of code in a standard WordPress install, spin them out into tiny modules, and build an API on top of it so that it can be extended even further. That way if I want my shopping cart to include recommended items or more secure authentication, I just have to use a few actions or filters to get it up and running. This is similar to how Ruby gems or Node modules work. And if WordPress is going to be a platform that competes with other web application platforms, it will need this important bit of modularity.

Appealing to Developers

Ultimately, the future of WordPress will be determined in large part by developers. They will choose what to use the platform to build, and their products will set a precedent for what WordPress can be. And the best way to appeal to developers is with a simple to use API. That’s a lesson that Facebook learned from very quickly. By opening up their API, they became a de-facto user authentication all over the web.

The WordPress API is, in my very humble opinion, extremely easy to work with and build on top of. If a plugin wants to truly be ubiquitous, this is where they will put their efforts. They will build a platform that is familiar to WordPress developers, that uses the same conventions and syntax, but that provides an area of functionality, a pattern, not previously unlocked. Because if two plugins are competing for the same space, the better API wins. More developers will gravitate towards it, will recommend it their peers, will build add-ons for it, and so on.

Not Every Plugin, but Most

There are some plugins that wouldn’t necessarily benefit from the platform model. We don’t need an extensive API for a visual editing plugin. But that doesn’t mean that simple plugins can’t benefit from it. A plugin platform doesn’t need to have hundreds of hooks and dozens of add-ons. It can be as simple as core functionality plus a few isolated actions for more fine-grained use cases. This is similar to how a plugin like SearchWP works.

The good news is that WordPress is open by default. If you build a small module, with an even smaller API, the community will help it grow. There are hundreds of plugins that hit the web every week. But if we start thinking smarter about our plugins, and building small platforms from them, we can add something far more essential to the ecosystem—extendability.

What do you think is the future of plugins? Let us know in the comments.

Jay Hoffmann is a WordPress developer hailing from NYC. In the strictest sense of the word, he is a WordPress enthusiast with an eye for front-end development and design. He has been working with WordPress since 2006 and currently works for a popular children’s media company. This year, Jay started Tidy Repo, a curated list of the best and most reliable plugins from around the web. You can also follow Jay on Twitter.

There are 7 comments

May 13, 2014 #

zenofwp

There are many who say the future of web development lies with javascript and Single Page applications. Where do you think WP stands with respect to the SPA bent on things?
- May 13, 2014 #
  
  Jay Hoffmann
  
  Well BackboneJS is rolled into core now and used quite a bit on the back-end. And there are some theme developers that are making some serious strides incorporating SPA frameworks into WordPress. I think we are almost there, but we won’t actually see the full strength of Single Page Applications until the REST API the core team is working on becomes standard out of the box.
- May 13, 2014 #
  
  Peter Knight
  
  I definitely concur on JS growing in influence.
  
  The Single Page application idea as applied to WordPress is a bit of a mind**** (I couldn’t think of a better word here). I’m trying to think of the ways SP approaches fit within WP. Javascript is becoming more and more dominant in the backend but the core administration isn’t going to resemble a single page application any time soon even if that was the direction things were going.
  
  On the frontend, for themes, the single page approach is a design trend that works well for certain kinds of sites, but I don’t see how it works for content driven sites, which is the typical use case for WordPress powered sites. There are a growing number of themes implementing libraries like backbone.js and techniques like ajax/pjax for making more modern and compelling dynamic themes, but these generally work on top of the standard approach, not replacing it altogether. If JS is disabled for example a good theme will and should still function normally.
  
  For Apps that use WP to power the backend. The REST api Jay mentions will make such things a lot easier. I hope it lands in 4.0.
  - May 13, 2014 #
    
    zenofwp
    
    I honestly do not get what you’re communicating by saying SPA applied to WP is a mind***
    
    Agreed that a huge advantage of using WP is having the backend. Think of having to program a backend as a SPA – AAARRGGGHHH!
    
    SPA works for content driven sites because it makes the site work faster which is very important for SEO and specially important for mobile access. With peoples’ attention spans being so short these days, every amount of speed enhancement is a good thing.
    
    I am not worried about someone disabling their JS. I put that in the same category as someone using an old version of IE. Not worth the time to worry about. This is the 21 Century and having JS enabled is a requirement.
    - May 13, 2014 #
      
      Peter Knight
      
      >>>”I honestly do not get what you’re communicating by saying SPA applied to WP is a mind****”
      Yeah, I mean it does weird things to one’s mind when trying to fit it in with normal WP development. I was recently thinking about what would be required to make an offline-first WordPress site and how that would affect how one creates a theme. It was making me dizzy (but I’m very intrigued by it).
      
      If the goal is say, creating a theme, then you have to figure out how to maintain compatibility with plugins. A lot of things happen server side and all that logic doesn’t easily move to the clientside.
      
      Say a page on your site loads specific scripts than don’t run elsewhere, or different stylesheets even. In a Single Page setup this is a pain to manage. What if a visitor browses to this page. You can do some voodoo and get it to work without navigating to a new page but then the benefits are quickly offset by the added complexity of managing conditional assets, templates and states.
      
      I don’t think SPA reliance of javascript is as simple as requiring users to have js enabled. You also have to think about the overhead that is being added. It takes up more resources in the browser (resources in some contexts are in limited supply) and frankly, JS errors are pretty common, especially when you have 3rd party plugins that may or may not be playing nice. One error and your site can stop functioning. When you have more scripts running, the likelihood of errors/performance issues invariably goes up.
      
      Usually, SPA projects are done where a team has written their own scripts or is in total control of what scripts are used on a page. They create a predictable environment that is tailormade and architected from the ground up. When I’m thinking WordPress development, I’m thinking about this diverse ecosystem and a large userbase that is using any combination of plugins, writing all kinds of content. So site environment is the same.
      
      So I think it really depends on the context whether SPA makes sense for a WordPress project. I don’t think it fits the general content-driven usecase that well. And really, the benefits can be had by doing simpler clientside implementations or just focusing on caching and other factors that speed up a site.
      
      And then there are common SPA issues to think about, you have to worry about whether Google’s spiders are able to properly navigate/parse your site. Users using <IE10 don't support pushstate, which is kind of important too.
      
      We are starting to see some cool backbone/pjax powered WordPress themes (check out the collections by theme foundry), but they are not really trying to be a single page application. They are more about loading content via ajax essentially to reduce page reloads and provide a more pleasing user experience.
      - May 13, 2014 #
        
        zenofwp
        
        What I take away from your post is that SPA development is a huge pain. Agreed! But I am not thinking of the benefits to the developer. I am only thinking of benefits to the user. You wrote, “A lot of things happen server side and all that logic doesn’t easily move to the clientside”. Agreed. But the point of SPA is to move all the processing to the browser! I have not doubts about the desktop browser being able to handled it all. But I do wonder about the ability of mobile device browsers to support it.
        
        There are some in the SPA community championing a javascript solution across the board – meaning not only JS at the browser, but also at the server side.
        
        If SPA takes off, I think there will be a business in refactoring WP sites as SPA, where WP is kept for the admin side of things and for serving data to the SPA. In a case like that, of course, any plugin functionality, where required, will need to be incorporated into the SPA. I envision a future where coders write plugins in the form of jQuery libraries. Perhaps there will even be super WP plugins that will allow a developer to develop a WP based SPA and whose output is a single index.htm file, some css files, and some js files.
        
        The problem of SEO and google is solvable. Two books that explain how are “Single Page Web Applications” and “Developing Backbone.js Applications”
        
        Thanks for your comments
May 13, 2014 #

Peter Knight

Thinking in terms of platforms is really eye opening. I started work on a niche widget plugin a long time ago and have slowly been evolving/refactoring the code base to act as a base off which other plugins can be easily created. So what started out as 1 product now has the potential for dozens of products, all of which can be extended and customized as well. It is challenging to really think through how a code base should and can be extended to support a platform. A 100 hooks/filters does sound like an awful lot though.