Hi, I hope this is the right place for a question.
And I hope there is an answer …
In the plugin repository (WP) more and more plugins are marked with “not compatible with your version”.
I saw this now on contactform 7 and others I use. That means no more updates for this plugins.
How is ClassicPress going to handle this trend?
I am getting more and more to a point where it’s more difficult to explane this to customers…
We are aware of this and will be developing our own plugin and theme directory as a priority. I think this is key to addressing the concerns of your customers, as our own directory will show only plugins that are known to be compatible with CP.
We are also working on a marketing campaign targeting WordPress 4.9 developers (and users) with the expectation that many more will commit to ClassicPress.
You may find that plugins that claim to need WP5 (and therefore show as not compatible with CP) do in fact work perfectly well with CP. You would, however, need to update these manually and I strongly advise trying this out in a safe development environment first.
Another thing is to try a completely different plugin that offers the same functionality, especially one whose developers have committed to ClassicPress. For instance, Wordfence used to be my go-to security plugin. Now I use Shield Security since they have confirmed support for CP. Or, for the same reasons, if you use Elementor, use Beaver Builder instead.
Many community members have also been very active developing new plugins and themes for CP.
And of course we have our own e-commerce plugin (Classic Commerce) and SEO plugin (Classic SEO) which will soon be reaching release 1.0.
But rest assured that we are working on our own plugin directory and I’m sure that this will present a much more positive experience. @james may wish to comment further.
Looking at the specific example of Contact Form 7, I am using version 5.1.6 of this plugin on a couple of ClassicPress sites and it is working fine. The current version is 5.2.1 which only supports WP 5.3 or higher.
Here are a few ways we could handle this, again using this plugin as an example:
Reach out to the developer and ask them to either restore WP 4.9.x compatibility or continue to officially support the 5.1.x versions.
List the latest 5.1.x version of Contact Form 7 in our directory, changing the minimum necessary to make it clear that this is supported by the CP community.
Fork the 5.1.x version entirely and give it a new name.
Wait for the CP community to develop alternatives.
Or some combination of the above.
If there are no features in the 5.2.x version of this plugin that you need on your sites then currently the easiest thing to do is to install 5.1.x and ignore the update notices. There are also plugins and code snippets that you can install to hide the update notices altogether. This is not ideal but it will work as a temporary solution.
I’ve recently noticed a few occasions where we have started to suggest using an older version of a WP plugin. This makes me uneasy… it goes against all the advice you can find online. The number one mantra is “update, update, update”. If your site is hacked, one of the first responses is invariably: “Did you have everything fully up to date?”.
It may be fine for experienced devs but you can’t expect the average user to assess whether an older version of a plugin has any security holes.
And the OP is right. It’s getting to be noticeable.
that is why we need to target people and convince them to come and present them with the directory.
plugin devs will certainly know of CP at this point, but they stay where their money (big money) now is. with the bigger user base.
and user won’t shift because plugins…
so having a directory AND inviting people over is the best answer here. we can support a real ecosystem, so we become a new promising market…
users will come and tell plugin devs they want plugins for CP. special plugins only for CP. and they will come and find the directory… it won’t be an easy and fast process, but we can only address things in a long term perspective. As of now people will seemingly feel discouraged. in the long run we will win them over.
My number one mantra is “find a version that works, is secure and stable, and stick with it”. What is being suggested is that ClassicPress users stick with the latest version of the plugin that is known to be compatible with CP. Until we have a more acceptable alternative, I’m not sure what else can be said.
In any case, there’s no guarantee that newer versions of plugins are any more secure than older versions and nothing can ever be 100% secure. As James says, this is a temporary solution, but it’s one that works perfectly well.
Precisely. And that is what we are doing.
We are actively working on a number of approaches. We’ve created new web content, increased social media presence, identified a target audience and we’re working on the new directory.
I agree it is very easy to be discouraged when you keep seeing messages like “X Incompatible with your version of ClassicPress”, especially when it’s one of your go-to plugins (such as CF7). But…
If anyone has any suggestions as to how else we can address this, please do let’s hear them.
I agree, and this is closely related to the point I made in the discussion had here on the forums after the last marketing meeting.
This would be fine if all plugin devs were transparent about backward compatibility. Unfortunately, they’re not… you’re humming along fine doing your regular updates for your client and then suddenly you’re rolling back to an old version because a plugin just broke your site. A frustrating annoyance for those of us who know how to tackle that. A much more difficult task for those who are less experienced.
I’m glad to see this being discussed but I’m not sure what the solution is, but I think that James has offered some good temporary alternatives. The easiest option, IMO, is that we each continue to reach out to the developers of our favorite plugins:
There is power in numbers. If enough people speak up, eventually the plugin devs will take notice.
There may be one or two devs like this but this is certainly not the norm in my experience. Sticking with a specific version of a plugin is a widely adopted practice, not necessarily related to ClassicPress. It happened with CF7 for instance after the dev dropped support for reCaptcha v2 with no notice. In that case, many users chose to stay with version 5.1 but only after they’d already updated to the newer version which subsequently broke many sites.
I’m sorry if I’ve given the impression that sticking with older versions of a plugin is a good look for ClassicPress. That was certainly not my intention. I agree that it does not look good and I also agree that, in the real world, it may not always be practicable, for any number of reasons.
But I do still believe that in certain scenarios, it is the sensible and sometimes only thing to do, though mostly on a short-term basis. It is a potential, temporary solution to address an immediate issue. I am not recommending it as a long-term policy.
In many ways, in terms of security, it is little different than using plugins that have been abandoned or that have not been updated in 8 years (yes, there are some) and yet many of us do this.
Maybe I was a bit flippant for saying what I said, and I apologise for that, but the point I was trying to make is that it is not uncommon for updates to bring new problems, including security holes. And in some cases, as we are finding more and more, there is simply no other option than to stick with an older version.
But putting all that aside, the main message I want to make is this:
It is known there is a problem, but action is being taken to address this.
I’m sorry if anything else that I’ve said may have diluted this message.
I don’t know about you guys but I don’t update my plugins unless I can’t avoid it.
I read the change logs and if it is not a security update, I don’t bother to install anything because most plugin updates nowadays have to do with Gutenberg editor compatibility issues. That as it is obvious below even the plugin developers are unable to deal with them!
See it to believe it!
This is primarily a maintenance release, but one tweak was made.
Tweak: Changed name of meta box title
My comment. We can live with the same meta box title!
But the best are below!
Release to downgrade Featherlight verison until all bugs are worked out.
This is primarily a maintenance release, but one new feature has been added. Display the option to disable the lightbox in Gutenberg!
Here’s a full list of what’s changed since the last release:
Feature: Add back metabox in sidebar
The 1.3.2 update came 12 hours after the 1.3.1 one because the 1.3.1 messed up the universe. I bet that this developer guy is still trying to work out how to disable this lightbox on Gutenberg. I feel for him… Honestly!