Opened 7 years ago
Closed 7 years ago
#3010 closed defect (bug) (fixed)
Plugin Directory: Replace "This plugin hasn’t been updated in over 2 years" banner
Reported by: | SergeyBiryukov | Owned by: | obenland |
---|---|---|---|
Milestone: | Plugin Directory v3.0 | Priority: | normal |
Component: | Plugin Directory | Keywords: | has-patch has-screenshots 2nd-opinion |
Cc: |
Description
In the old Plugin Directory, bumping the Tested up to
value in readme.txt
was often suggested as a way to remove "This plugin hasn’t been updated in over 2 years" banner.
From the "WordPress 4.8 is imminent! Are your plugins ready?" email to plugin authors:
After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme "Tested up to:" value to 4.8. This information provides peace of mind to users and helps encourage them to update to the latest version.
...
For each plugin that is compatible, you don't need to release a new version -- just change the stable version's readme value.
In the new Plugin Directory, bumping the Tested up to
value without releasing a new version no longer removes the banner, as the post_modified
property is only updated if the version is changed.
Per discussion in #meta with @otto42, the banner used to have meaning, because plugin searches were limited to 2 years, so seeing that banner meant your plugin didn't appear in searches. Now that searches no longer have that limit, the banner has no actual meaning and can be removed.
@ipstenu suggested that the banner could be adjusted to check the Tested up to
value instead of Last Updated
.
Attached is a patch implementing the latter option.
Attachments (3)
Change History (19)
#3
@
7 years ago
3010.patch adjusts the banner to check the Tested up to
value instead of Last Updated
, and replaces the current text with: "This plugin hasn't been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress".
This ticket was mentioned in Slack in #meta by sergey. View the logs.
7 years ago
#5
@
7 years ago
I think we should do either:
This plugin hasn't been tested with the latest 3 major releases of WordPress.
or
This plugin hasn't been tested with the latest 3 major releases of WordPress.
The 90% bold of the sentence puts odd emphasis on things.
#6
@
7 years ago
3010.2.patch makes the whole first sentence bold.
This ticket was mentioned in Slack in #meta by tellyworth. View the logs.
7 years ago
This ticket was mentioned in Slack in #meta by sergey. View the logs.
7 years ago
#10
@
7 years ago
Why the new warning says "3 major releases"? If you want to replace "2 years" with new text, it should be 5 or 6 major versions. Normally WordPress has 3 release each year.
#11
follow-up:
↓ 12
@
7 years ago
We know. The thought is that if you're 3 major releases behind, there have been a LOT of changes, more than just two years may indicate.
#12
in reply to:
↑ 11
@
7 years ago
Replying to Ipstenu:
We know. The thought is that if you're 3 major releases behind, there have been a LOT of changes, more than just two years may indicate.
I can understand your thought but I'm not sure this is the right way. I have over 30 plugins, many of them are simple oEmbed plugins, registering different oEmbed providers. Or simple plugins that add a simple shortcode or a metabox.
Those plugin can't really break the site, they are tested on clients sites. Releasing an update for dozens of plugins every 3-4 months is not realistic. At least not from a developer point of view.
Unless the repo can offer an easier way to update the Tested up to
value. In the past there was an attempt to give access to the plugin repo back-end. It was supper easy to update the general setting of my plugins using a meta-boxes. Not sure why it was removed.
#13
@
7 years ago
Those plugin can't really break the site
Sure they can, and you know it. If WordPress has to apply some weird security patch to oEmbed you could wreck display. Experienced devs knows that anything can break, and there's a whole study done on the 'rarely used' aspect of software (the tl;dr is that the stuff you don't use as much tends to break in more obscure ways that are harder to fix, specifically because we're not regularly using and testing it).
Releasing an update for dozens of plugins every 3-4 months is not realistic. At least not from a developer point of view.
I fully agree. Which is why I'm attacking this on multiple fronts. One of which is to figure out a better way to allow developers to flag their plugin as compatible.
That said, a major release happens at most 4 times a year, which means you would then have to update your plugin at most twice a year (more likely you could get away with once - every summer, say). Also you can update your readme, and not release a new version, and that would be sufficient in most cases.
I recommend you update your plugin for every other MAJOR release. 4.8, 5.0, 5.2, and so on. That will keep you always in the green. You could even script this if you wanted. But asking a developer to spot-check their plugins every 10-18 months shouldn't be an onerous task.
Is this the right way? No. But the old way hasn't helped as much as we wanted and 2 years was arbitrary to begin with. Release and iterate, y'see :) We want developers to review and update their plugins regularly - and if you're not, then you are susceptible to rare breakage due to changes in core. Sucks, but that's part of your responsibility. It's the other side of the FUD coin - make users feel good by demonstrating you care and are working on the plugin.
#14
in reply to:
↑ description
@
7 years ago
- Keywords 2nd-opinion added
Replying to SergeyBiryukov:
In the new Plugin Directory, bumping the
Tested up to
value without releasing a new version no longer removes the banner, as thepost_modified
property is only updated if the version is changed.
[6073] restored the ability to remove the banner by bumping the Tested up to
header, so this is no longer an issue.
Do we still want to replace the arbitrary 2 years check with something less arbitrary like 3 latest releases? If not, the ticket can be closed.
@samuelsidler noted that the
Last Updated
date still has an effect on search results, so if we’re going to remove the banner, we also need to remove that part of the search algorithm, or base it on something else likeTested up to
.I think that can be explored in a new ticket.