What is the best way to ask theme developers to support a plugin?

(Sebastien) #1

I am working on improving theme support for a plugin of mine and wanted to know what is the best way to pique the theme developer’s interest in supporting a plugin? For example: Jetpack’s infinite scrolling.

Would like to hear your thoughts preferably from theme developers but developers in general is good too.

(Leland Fiegel) #2

As a theme developer, I am very selective on which plugins I support in my themes. I believe most plugins shouldn’t even need a theme-specific integration for it to look/function as it should.

For example, many themes used to advertise “Gravity Forms support” …even though Gravity Forms worked fine in pretty much every (sane) theme anyway. It has its own default form styles that can be disabled by the user, which would then allow them to add their own styles and/or let the theme’s input styles take over.

I’d much rather have a list of “tested with” plugins rather than build out a specific integration for each. It can be a slippery slope as the lines between plugin and theme support begin to blur.

Since you mentioned Jetpack, I should note every single one of my themes supports at least one Jetpack module, but Jetpack is a pretty unique case.

  1. WordPress.com themes are required to support Jetpack Infinite Scroll, so that one isn’t much of an option for me, since I sell themes on WordPress.com.

  2. Even if it wasn’t an option, I’d still integrate it anyway, as I really like the experience Infinite Scroll offers. It’s nice to be able to quickly navigate through archive pages without page reloads.

  3. Jetpack has other useful (and not so well-known) modules built specifically with theme developers in mind, such as Featured Content, which lets users select a “featured” tag and automatically excludes those posts later in the loop.

  4. While modules like Portfolio Content Type and Social Menu can be effectively replaced with simple standalone plugins or core functionality, Jetpack has over a million users…making it the perfect plugin for theme developers to “rally around” and give users a more seamless experience switching between themes.

  5. It’s backed by a big company. I don’t have to worry about it shutting down any time soon, leaving me the responsibility somehow migrate my users onto something else. I’d be very hesitant to add integration for a plugin by an unproven entity.

Of course, the leverage Jetpack has just isn’t going to be a realistic option for most other plugin developers.

For everyone else:

  1. Ideally, make sure your plugin works out of the box with any theme. Even though it could be spruced up with additional styles and such, just working out of the box will go a long way in establishing goodwill with theme authors. Nobody is going to spend substantial amounts of time getting a plugin to work with their theme if it doesn’t play nice to begin with.

  2. Before pitching theme authors, it would be nice if there was some adoption already. I realize this is a “chicken and egg” scenario, but I wouldn’t even think of spending any time adding support for some brand new ecommerce plugin when I can support WooCommerce or Easy Digital Downloads instead.

  3. It should add value. For example, I wouldn’t really care to add support for a basic form plugin, when there are plenty of free form plugins like Ninja Forms that work fine without any work on my side. If I was building some sort of “charity” theme, and your form plugin integrated with a payment processor popular amongst non-profits? I’d be willing to spend a little time making sure it was styled all right.

Again, I get it’s a “chicken and egg” dilemma…this is just how I’d evaluate a plugin developer approaching me to add integration for their product.

(Sebastien) #3

This is the key issue that I am trying to improve on. Let me explain. My plugin (Auto Load Next Post) requires the post navigation at the end of a single post so that my JavaScript can then read the link of the previous post in order to fetch that post and then load it at the end of the post just like JetPack only the user does not need to do much setting up if the theme was developed following WordPress theme code standards.

About 25% of the time I come across a theme that does not have a post navigation including some theme frameworks such as Genesis or is not using the proper WordPress theme code standards and has placed a custom post navigation of their own that does not have the proper HTML attributes that I need to detect the previous post link.

About 50% of the time I come across a theme that requires a template loop override because the theme structure to get the templates are also not WordPress theme standard but with the recent release of WordPress 4.7 it has been brought to my attention that this is possibly going to be changing.

For example the past three core WordPress default themes have the same or similar template structure that follows the WordPress theme standards. However, when looking at the template structure of Twenty Seventeen, it is completely different.

It is this template structure architecture that I am struggling to support out of the box because every theme developer handles the templates differently.

Everything else (most of the time) is followed by the WordPress theme standards and the plugin works great.

Now I am wanting to improve support for both those scenarios. At the moment I am doing all of the development and although it does not have that many active installs, I strongly believe that I have a great product that can compete against JetPack`s infinite scroll module.

There is no CSS required or applied on the front-end and if I can get the support or feedback I need to make the plugin work out of the box more then the base of the plugin is complete and I can then expand on it for further features.

I have already had two contributors so far. One found a bug that supports Google Analytics and another added a developer feature that allows them to trigger an event once the next post has loaded. They will be both coming out in an update soon along with other minor corrections and adjustments.

After this update I will be looking into supporting themes that are not WordPress theme code standard but I need the help of theme developers to do that.

At the moment the plugin works once you have added “add_theme_support” for the plugin and made sure that the theme selectors match the active theme. It is after this stage that the plugin may still not work because of the themes template structure so the plugin is unable to locate and get the correct templates to load the post content.

So if anyone can guide me or share a list of template structures that theme developers, use I could perhaps solve this issue without the need of theme developers needing to provide support for the plugin and it would work out of the box.

The project is open-source and is available on GitHub. All contributors are welcome.

(Zackary Allnutt) #4

Thats tricky, for all the reasons that leland has said.

I think you’ll find it hard to get authors to make changes to support it untill its had significant adoption so that enough people are asking for inclusion.

I would general be warey of including support for something, but in this sinario, its something I think themes generally should have anyway. Your not asking for anything special.

Problem is that some themes use alot of custom functions, so even if they have navigation, it may not be the wp functions. Alltough most of the time it probably is.

(Leland Fiegel) #5

Okay, this plugin is actually pretty cool. I’ve always wondered how to do this on WordPress sites, since I’ve seen it so frequently on major publications.

Is this totally necessary? I know in some Jetpack modules, all that’s needed is checking off a box in the backend (like the Portfolio Content Type, for example). That way, themes don’t necessarily need to declare specific support. Maybe include a “use at your own risk” warning with the caveat that the theme may not properly support it.

I don’t really see it as a “competitor” of Jetpack Infinite Scroll at the moment, as that just scrolls through archive pagination, not single post pagination like yours.

I probably wouldn’t add direct integration with my themes. But I could definitely see myself making a tutorial (and possibly a supplementary plugin-based add-on to get the add_theme_support() in there, if necessary) to instruct users on how to get this functionality on their own sites. Since I have a couple magazine themes that this would be a good fit for.

Then there could maybe be a cross-promotion type thing going on with “tested themes” on your end, with a documentation guide on the theme developer’s end. Ideally, no code would need to be added on the theme’s end, just as long as it had a sane the_post_navigation() function included.

(Sebastien) #6

Enabling Infinite Scroll is very similar to adding support for post thumbnails or editor styles because we make use of add_theme_support(). By providing a few key pieces of information when calling add_theme_support(), Infinite Scroll will seamlessly integrate with your theme.

Honestly, I thought JetPack did do single posts also but I’ve never used it my self but even if I did remove the use of “add_theme_support”, and the theme did have a post navigation on the single post, the user still has to do two things in order for the plugin to fully work.

  1. Enter the theme selectors via the settings page.
  2. Check that the loop matches the theme template content for single posts.

This is from https://jetpack.com/support/infinite-scroll/

If you have a well-crafted theme, like the WordPress default themes, adding Infinite Scroll is a breeze. Here is how it’s done for Twenty Twelve:

add_theme_support( 'infinite-scroll', array(
    'container' => 'content',
    'footer' => 'page',
) );

With that you get a fully functioning infinite scroll experience.

I was thinking of having developers do something similar by adding the theme selectors as the arguments so that the user does not have to setup the plugin only activate it. The only thing that the developer also needs to do is simply match the template that is called similar to how JetPack is done only for single posts not the archive.

What do you think?

(Leland Fiegel) #7

You could do that to have theme developers specifically define selectors and stuff. Perhaps there could be an options page where users could define their own selectors as well.

That way, technically-savvy users of themes that don’t explicitly support it could use it as well, without modifying the theme. If the theme declares support, however, that options page could disappear.

(Sebastien) #8

There is already an options page where the user can define the selectors but some users have reported that they didn’t understand it and gave up instead of asking for support or reading the documentation.

Technical savvy users have no problems setting it up.

What I planned to change (as I have other options besides the selectors), that if the theme developer has specifically defined the selectors already that those fields on the options page are disabled or hidden because there is no need to change them.

(Sebastien) #9

Found this theme Bimber on Themeforest.net supports the plugin. After looking at the code it is a lot more than I thought it would take to support the plugin out of the box for but they have done a good job.

(Sebastien) #10

This is the current change log for the next release. Looking to add Twenty Seventeen to the list of WordPress core themes next before releasing.

1.4.8 (25th December 2016)

  • Added: Support for child-themes so they too can also use the plugin.
  • Added: New template location filter.
  • Added: New action hook for when there are no new posts to load.
  • Added: a post count of the posts that have loaded. Can be used to trigger an event after X amount of posts have loaded.
  • Added: a new variable that can be set to prevent further posts from loading.
  • Corrected: Plugin links and improved spelling and grammer.
  • Dev Feature: Can view the console.logs if debug mode is enabled for Auto Load Next Post. Must have SCRIPT_DEBUG set to true also.
  • Dev Feature: JavaScript triggers have been added so developers can do fun stuff.
  • Fixed: Google Analytics bug that prevented more than 3 posts to load.
  • Improved: How Google Analytics is triggered.
  • Improved: The JavaScript now identifies the post ID of each post including the initial post on load.
  • Improved: The JavaScript to remove the comments on load instead if requested.
  • Improved: The default template “content-partial.php”.
  • Removed: The post navigation from the template “content-partial.php” file and applied it via an action hook instead.
  • Removed: The comments from the template “content-partial.php” file and applied it via an action hook instead.
  • Removed: History state on the initial post load. Not required.
  • Removed: All languages except the POT file from the plugin as they will now be downloaded from WordPress.org
  • Updated: The POT file.
  • Updated: The readme.txt file.

(Sebastien) #11

Update was released on Christmas day. I’m currently planning on making improvements for theme developers.

(Sebastien) #12

Created a new repository that users and theme developers can contribute too for supporting Auto Load Next Post.

Started with the Twenty Ten theme for now. It’s an old theme but is still used so I thought I provide support for it as the template structure is a little messy.

This repository will support old themes that are still safe to use and are in use. It will also support new themes but hopefully that will be a temporary measure once I have released another update for theme developers in mind were they will provide the support already.

I hope you will join me on this quest.

(Sebastien) #13

I have just created a new survey using Google Forms. I would very much appreciate your feedback so I can take Auto Load Next Post to the next level. Thank you.