Handling plugins that now require WP 5

Plugins
1

With Elementor requiring WP 5 for the new 2.8 version, I started thinking about how this affects me and how many other plugin developers may make this a requirement.

For plugins that previously worked just fine on ClassicPress, the requirement is really just a formality.

So I started thinking about ways around this. What I ended up doing was downloading the last version that supported WP 4 and modifying it.

I did two things. Firstly, I bumped the version number to a much higher value to prevent update notices, eg: Elementor 5.0.0 and some minor readme.txt changes.

Secondly, I added a check to see if the user is on ClassicPress or WordPress. If they are on WP, the plugin will not activate and they get a warning message in the admin panel.

This ensures people don’t try to install it on a WP site.

I then created a new website cpforks.com to formalize it. Because you are not allowed to use shared hosting for file hosting, I store the actual plugin zip files at box.com

I have also installed the pro version of the File Manager plugin so developers can collaborate on a modification from within the ClassicPress admin panel itself.

For someone who wants a plugin that no longer works with CP for no valid reason, apart from the WP 5 requirement, it offers them a free way to get or request a modified plugin.

Of course it will never get new features or security updates. But the foundation is there for a developer to do that if a customer wishes.

It certainly beats fighting with GitHub to do a simple fork, without it wanting to document every single change you make. A Changelog file could always be added if necessary.

So it’s both a directory and a repository without all the red tape.

6 Likes
2

That’s a really neat idea Graham. I like it!

I would suggest a change on the home page though. You have:

With some plugins such as WooCommerce and Yoast SEO, it has been vital that the CP developers fork the plugins and completely rewrite them to work with CP.

The CP developers are not the ones behind those forks, it’s really the CP community. Also we haven’t forked Yoast, it was RankMath.

2 Likes
3

You may also want to consider how the forked version will handle templates currently being served from the Elementor server.

At some point with their direction and maybe a new API for the template server they are bound to remove/terminate the old one.

1 Like
4

@ozfiddler Thanks for clarifying that. Shows how much I was following the Classic SEO project! I tried to include both the CP developers and private developers (community), but maybe that message isn’t clear.

You have to read it as someone who knows nothing about who does what. They don’t want to know exactly who forked each plugin. I’ll take a more objective look at how I’ve worded it.

@zulfgani The site tries to make it clear that the modified plugins will not receive updates and will remain at the same version.

But the foundation is there if a plugin does need patching, either for security or functionality. Users can request a new version and if a plugin developer wants to make one, we could look at some sort of payment system to have that done.

The idea behind my site is an immediate fix and a method for accessing the modified plugin. Over time, things will grow, as new ideas tend to do, and we then need to look at ways to deal with those things as they arise.

I have already been contacted about using the CP logo and warned that using the WP one may also get me in hot water. As I was told very early in life, if you stick your head up, you’ll get it shot off. But, being an Aussie, we tend to thumb our noses at authority. Probably comes from our convict beginnings, as the English “invaders”.

1 Like
5

It is quite confusing at the moment because both the commerce and seo plugins are being developed under Classicpress Research, so the boundaries are very blurry. :smiley:

1 Like
6

Does this include the one that is included with fork-awesome? :astonished:

1 Like
7

There are some big drawbacks to this: I can’t tell what has been changed from the original plugin, or even what version of the original plugin was used as a starting point. I also can’t tell if one of the modifications introduced a bug, or worse, some malicious code.

If you use a version numbering scheme like 999.1-upstream2.7.6 then that solves one of those issues. Using GitHub or some other form of version control helps with the rest.

1 Like
8

The previous stable version line is left unchanged:

define( 'ELEMENTOR_PREVIOUS_STABLE_VERSION', '2.7.5' );

There are no changes made to the plugin code at all. All I do is add a function to check if ClassicPress is installed. If not, the plugin won’t install.

There is no need for the strict requirements of GitHub, because I am not modifying how the plugin works. That is the whole point of this method.

Certainly, if modifications were actually made to how the plugin functions, that is an entirely different matter. That’s when a developer would need to get involved and the changes documented.

The issue of introducing malicious code is one of trust. People will either trust we don’t do that or they won’t.

2 Likes
9

I’m not actually clear on this. What are developers able to do, and how?

1 Like
10

The File Manager gives you access to a folder tree where the current plugin is uploaded and unzipped.

You can then work on the files from your admin panel. Once the necessary changes are made, the pugin is then zipped again and uploaded to box.com.

The folder for that plugin is then no longer needed and can be deleted.

Because any authorized member can access the folders, they can collaborate with other developers on what should be changed.

There is no access to any other folders on the CP site.

1 Like
11

Hmm. Yes. OK. So, I guess the question is who is “authorized” and how are they chosen and what are they doing and how is it tracked?

I think I’m with James on this. The idea of a repository for “last know plugin example working with CP” is a good idea. But if it’s been subsequently modified in ways unknown then I’d have more reservations about using it. Or do you plan to keep the original as well as the modified versions?

1 Like
12

The only people who will be authorized are developers I trust. Nobody can register and have access to the File Manager, it is an assigned role. In fact, you can’t register for the site at all, it is by request through the contact form.

I get your idea of keeping the original version as well. I will introduce that.

I think everyone is panicking over a problem that doesn’t exist. There are only two things ever done to a plugin:

  1. Bump the version number
  2. Add a function to prevent the modified plugin being installed on a WordPress site.

There is nothing else done to the plugin.

I understand people who are developers may see this as heresy, and it goes against all the training they have received as programmers. But there is really nothing to worry about.

If there is a need to actually modify how a plugin works, that is a different issue altogether and stricter measures would then get involved.

1 Like
13

:+1:

What was the reasoning for this? Wouldn’t it be equally useful for someone deciding to stay on WP4.9?

1 Like
14

This is a service offered to ClassicPress users. It is a value-added product, if you like.

2 Likes
15

I’m not seeing panic here… I think it’s more of pointing out what can/will become problematic and hard to maintain. The more you can get out in front of these things, the less work you have later. :slight_smile:

I’ve been watching this thread to see how it evolved. I think it’s an interesting idea, but, it raises a lots of questions, as well…

  1. What if 2 developers bumped the version number simultaneously in your admin panel? Or, are files “locked” as they’re edited?
  2. How are security updates kept track of?
  3. How/where will such changes be documented?
  4. How will a user know there’s an update, if there is one?
  5. How are these plugins updated, should the code change?
  6. What about internal marketing links that lead back to the original software? This will probably be confusing, perhaps even leading some to break their own sites (or bits of functionality) if the site owner, say, pays for and installs a premium version and overwrites your archived version.

Just a few things off the top of my head. Note that I’m not necessarily seeking answers to all these questions here in the thread – they’re more of an itemized list of additional things to think about and plan for.

3 Likes
16

@anon71687268 Yes, things do get complicated fast.

Normally, there will be no need for anyone but myself to modify the plugin, because of the simple changes. File Manager can send me an email when a file is edited, just in case.

I have your Update Manager in the back of my mind when it comes to update notifications and will see how that pans out.

I can see the need to include a notice that buying addons that don’t work on WP 4 will cause the same problem the original plugin had.

Elementor was probably not a good plugin to use as an example, because of its complexity and the wide range of addons available. Most plugins won’t have that problem.

It’s early days for my site and only time will tell if it remains feasible. You can only try. If it turns out a dumb idea, then so be it.

4 Likes
17

Interesting that today I heard from an old friend and she has this as her email footer:

Surely, in the light of history, it is more intelligent to hope rather than to fear, to try rather than not to try. For one thing we know beyond all doubt: Nothing has ever been achieved by the person who says, “It can’t be done.” Eleanor Roosevelt

4 Likes
18

Can’t argue with that :slight_smile:

No panicking here either, just pointing out that you’re reinventing ways to solve some problems that have already been solved more fully elsewhere, and as @anon71687268 says, there will probably be more of these in the future.

I’d still like to know the equivalent version of a plugin that I’m downloading from cpforks.com - I think this should be its own column in your table, for Elementor it should say 2.7.5. Or you can bake this into the version number directly, using a scheme like 999.0-upstream2.7.5.

In any case thank you for taking a shot at this problem, needing to stay on older plugin versions because of software vendors doing silly things is a pretty common issue in both the ClassicPress ecosystem and the larger WP ecosystem these days.

19

That is there. Maybe you’re seeing an old, cached version of the site?

1 Like
20

Indeed it is, thank you :+1: