Compatibility is … complicated. Just because a plugin hasn’t been updated, or doesn’t say it works with 3.4, means very little. I have a plugin that basically I just update with the major release of WP. No code has changed since 2.5 (yeah) except adding in a customizer.
I wouldn’t go deleting old plugins, but this feature would act as a good, quick indicator of whether a plugin was still supported or not. If the info was consolidated, I would only have to check on a few plugins that had old dates and versions rather than the whole list.
While there are always exceptions, I would bet more that an old, unsupported plugin would be more likely to break with a new version of WP than a new, recently updated one. As far as your plugin, after a quick search, I found 3 that all say compatible to 3.4. Even if the code hasn’t changed in a long time, I wouldn’t sweat yours because I would see in the list that you were on top of them. It would have been great to see that info in one convenient location.
By the way, looks like you spend a lot of time helping here. Thanks.
this feature would act as a good, quick indicator of whether a plugin was still supported or not
You’d think, wouldn’t you? But no. A lot of plugins are supported when not updated, and vice versa.
I would bet more that an old, unsupported plugin would be more likely to break with a new version of WP than a new, recently updated one
Nope. An old, non-updated, plugin has just as much a chance of still working. Why? Because it’s not the age of the code, but the … doing_it_right() part 🙂 If it’s well written, it may never break. Sure, I’d love it if everyone tested and updated their plugins for each release, but a lot of plugins are written by people who personally need them, so the plugins do what they want, and are updated if they break. If they keep working for the author, they’re probably going to sit, untouched, for a very long time.
I’m not a developer, but I always like to learn if you’re willing to teach. Why would WP issue release candidate notices with this message…
“Our goal is to release WordPress 3.4 early next week, so plugin and theme authors, this is likely your last chance to test your plugins and themes to find any compatibility issues before the final release. We’ve published some resources on the development blog to help you prepare.”
…if there was no chance of a plugin breaking when WP is updated?
I would assume that an unsupported, untested plugin would be more likely to have problems than a supported and tested one that would presumably marked for compatibility. As you mentioned, coding skill is probably more of a factor to failures than age, but both would be more likely to be uncovered when there is an update.
You’re thinking of it in a logical way but it’s weirdly off a bit 🙂
If there are compatibility issues, we update our plugins. If there are not, we don’t. Of course there might be a problem, but you’re trying to prove a negative (which is impossible). There’s no assurance that Joe’s non-updated plugin won’t work, or Bob’s updated one will.
Sometimes a non update means they didn’t test.
Sometimes a non update means they tested and found nothing wrong.
Sometimes an update means they found a problem.
Sometimes an update is coincidental.
You can’t read too much into it.
I know no system is perfect, but if it is so bad, why is the “Compatible up to:” field even posted on the plugin pages? Seems like if it makes sense to have in one location, it would make sense to have it consolidated in the other. I get that without being close to the development process, I might not fully grasp the nuances of compatibility. But I do see a logical flaw in posting it on the plugin pages but not on the admin pages. It seems that the effectiveness of the data would be the same in both locations.
why is the “Compatible up to:” field even posted on the plugin pages
It indicates that the plugin’s author has officially tested the plugin on version x.x of WordPress – that’s all. At best, if the “Compatible up to:” version is well below your version, I’d suggest activating the plugin with caution. That said, I’m using a plugin that has only been officially tested on WP 2.5.1 and it’s still working just fine.
I know no system is perfect, but if it is so bad, why is the “Compatible up to:” field even posted on the plugin pages?
Because it’s not bad. It’s just …
None of the data you get from a plugin, be it “Compatible up to:” or rating or popularity or even support requests that are resolved tell you the whole story.
Look at A Sunday Afternoon on the Island of La Grande Jatte. From afar, it’s simple. A painting of people on the island. But if you walk up to the painting (it lives in Chicago, I love visiting it) you’ll see Seurat painted entirely by dots! As you step in and out, the painting changes and your perspective and understanding of the work as a whole changes. You cannot simply say ‘There is blue paint.’ and make your final decision that this painting will look nice against a blue wall. You have to consider how it will look up close, far away, and will it be better to blend or contrast. Seurat liked the contrast, which is why it has a brown border and a white frame.
With your plugin review, you must consider the whole picture. Who wrote it? What does their personal/plugin site look like? How often is it updated? Is it well documented? What problems have people had? Are those support posts resolved? What’s in the Compatibility Matrix? How many downloads? What’s the popularity? What’s the star rating?
You can’t just take one and say ‘This is compatible with 3.4, therefore it is superior!’ I wish you could 🙂
I like conversations like these.
I agree with the points about the compatibility field being imperfect. No argument there. My initial feature request, though, was just to have it displayed in the admin page as well as on wordpress.org. It is still just one piece of the puzzle, but it is a piece that, at least to me, would be helpful to have conveniently placed. I would certainly not uninstall a plugin that looked unsupported. I would just wait a week or two and do some searches to see if there were any problems reported, look for alternatives in case something crashes, etc.
I am still not sure I am convinced that it is useful in one location when you decide to install a plugin, but not in another location when you are doing site maintenance. My premise is that it should be displayed in both locations or neither one.
As far as the painting analogy, I am also not very good at art. You make good points about assessing a painting. (This conversation is bringing me down–it is highlighting another thing I know very little about.) But I do know that the likelihood of a painting being valuable (note I didn’t say good! A whole different discussion.) is higher if it is maintained on the wall of an art museum than if it was left to mildew in an attic. Support is an indicator, not a guarantee.
Not being on the admin page is the signal to noise ratio 😉 The plugin pages on your personal install should be simple. Direct. Uncluttered. IMO the links to get more info should be more prominent. Then people can do their research.
As for needing it when you’re doing site maintenance, it wouldn’t change our debugging advice: Turn off all plugins. Then turn them on one at a time till it breaks. 🙂
- The topic ‘Last plugin update date & comapatibility’ is closed to new replies.