Categories
WordPress

WordPress plugins: How to detect use of forks

As a plugin developer, I donate my time and energies to the WordPress community. I make it clear that I don’t support anyone modifying my code or running it on a non-standard variation of WordPress – this includes forks.

Thankfully, some forks make it easy for their use to be detected.

Here’s some code that can be used within your theme or plugin code…

This introduces 2 things…

The idea is that, within your plugin, you’d use the is_fork function to determine if a fork is in use and, if so, not trigger any of your plugin functions – the admin notice is then informing them of why this is. It’s more difficult to achieve the same with a theme, so you’d probably miss out this step and just use the notice to inform the user that the theme isn’t supported on their platform. The notice is non-dismissible for good reason.

  1. A function named is_fork – call this to determine if the current CMS being used is a fork (it returns the name of the fork or false).
  2. An admin notice informing the user that a fork is not supported. The output message defaults to an assumption that this is for a plugin but can be modified to taste.

At the moment, the above script only supports a small subset of forks – I’ll add more as I come across them.

However, many forks remain compatible with core WordPress so running plugins and themes under them shouldn’t cause any issues. Indeed, you could use this code for detection of the fork for other reasons (altering the code flow to better support them, for instance).

7 replies on “WordPress plugins: How to detect use of forks”

What’s your point here David? That developers should intentionally add code to their plugins to prevent them from working with ClassicPress and other forks of WordPress? That’s just a bit mean-spirited isn’t it? Have you conveniently forgotten that WordPress itself is a fork of B2/Cafelog and WooCommerce is a fork of Jigoshop? Just imagine if developers adopted the same attitude when WP and WC were starting out. You seem to be completely missing the point of open source and GPL.

Apologies Tony – I thought I’d made it clear in the opening spiel what the purpose of this was. I’ll go back and review it.

What I’m not doing is suggesting that developers go and just switch off compatibility with it and, indeed, I’ve not implemented this myself for any of my own plugins. The idea here is, where there may be compatibility issues with CP (and I know from the roadmap that such issues are likely in future releases) or if a developer simply doesn’t want to support their code on a fork, here is how to detect CP. Why just CP? Because it’s the only fork that is so easily detectable – if you’re aware of any that do something similar, please let me know and I’ll update this article.

Thanks for clarifying David. So I presume then that you’re OK with the principle of people forking your plugins? And that you’re fine with the fact that forks of WP exist? You just won’t provide support for anyone that attempts to use your code on anything but vanilla WP?

So I presume then that you’re OK with the principle of people forking your plugins?

Of course. All my plugins are GPL (as they have to be to be in the WordPress directory), so are free to be forked. In fact, at least one of my plugins is a fork of another.

And that you’re fine with the fact that forks of WP exist?

Absolutely. The ability to fork code like this is one of the base principles of open source, which I am passionate about.

If you don’t mind me saying, I assume a lot of these questions come from my negativity towards ClassicPress. This has nothing to do with them being a fork of WordPress but my own belief that their direction of travel is wrong. I’d love to see forks of WordPress be successful and so calling out my issues is the kind of feedback that any project needs to be successful.

You just won’t provide support for anyone that attempts to use your code on anything but vanilla WP?

That is my plan although, as I say, I’ve not implemented any checks in own code. Yet. I develop for WordPress and I have no intention of running multiple forks to ensure I can support any other versions.

> If you don’t mind me saying, I assume a lot of these questions come from my negativity towards ClassicPress.

In part yes. I’m still using WP on 12 sites but have recently taken an interest in ClassicPress and will be giving it a try soon. You did seem quite negative to CP and I wondered where that came from. You also gave the impression that you weren’t super keen on forks. I felt compelled to ask.

> I’d love to see forks of WordPress be successful and so calling out my issues is the kind of feedback that any project needs to be successful.

I have no affiliation with CP at all. In fact, it’s only within the last few weeks that I’ve paid any attention to it. But if you’d genuinely love to see forks of WP succeed, then perhaps you could be less negative towards them?

> I develop for WordPress and I have no intention of running multiple forks to ensure I can support any other versions.

That I can understand and that is your prerogative of course.

But if you’d genuinely love to see forks of WP succeed, then perhaps you could be less negative towards them?

I understand what you’re saying but I don’t believe that holding back on your feelings towards something is beneficial – open and honest feedback is the only way for a person, or project, to improve.

Leave a Reply to David Artiss Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.