#2365 closed defect (bug) (fixed)
Plugin Directory: Restore links to previous versions of plugin
Reported by: | jimtrue | Owned by: | obenland |
---|---|---|---|
Milestone: | Plugin Directory v3.0 | Priority: | normal |
Component: | Plugin Directory | Keywords: | |
Cc: |
Description (last modified by )
In reference to: #2111
I went looking for this in reviewing the new Plugin Directory and primarily to see where things had moved to and found this particular feature completely missing now. I checked Admin as well to see if maybe I missed it, but nope, the links to previous versions of the plugin are completely gone now.
As a support lead for a very active plugin, we don't always have to send people to an easy download location for prior versions of our plugin, but I can tell you: When something breaks on update, the most important thing to do for that client is to get them working again. That often means (if they don't have a backup) to go download a prior version of the plugin. If you remove this functionality, we have no way of easily getting people to prior versions.
PLEASE reinstate this, even if it's just down under the links hidden under the 'show more' by Contributors/Developers. BTW, hiding anything important (all the Developer Meta) behind a show more window shade is not terribly 'usable'.
Attachments (3)
Change History (53)
#1
@
8 years ago
Being able to access the previous release versions of the plugins zip files, is very useful for users and plugin author support. Having those currently removed makes support harder.
#2
@
8 years ago
Strong agreement. This is a super important feature of the current design. I also send my users there from time to time.
#3
@
8 years ago
@jimtrue: We'll chat about this at the next plugin directory meeting (Wednesday at 0:00 UTC, I believe). /cc @tellyworth
@lukecavanagh: There's no reason to summarize comment:0, which is already clear.
This ticket was mentioned in Slack in #meta by tellyworth. View the logs.
8 years ago
This ticket was mentioned in Slack in #meta by lukecavanagh. View the logs.
8 years ago
This ticket was mentioned in Slack in #meta by lukecavanagh. View the logs.
8 years ago
#9
follow-up:
↓ 10
@
8 years ago
@tellyworth
So just to be clear, close this ticket since this will not be in the updated plugin directory?
#10
in reply to:
↑ 9
@
8 years ago
Replying to lukecavanagh:
So just to be clear, close this ticket since this will not be in the updated plugin directory?
No, that isn't correct. As mentioned previously, the new plugin directory will launch but will continue to receive iterations over time. The directory that ships is not the final directory. There is no reason to close this ticket as the idea will still be considered based on feedback after launch.
#11
follow-up:
↓ 16
@
8 years ago
If you remove this functionality, we have no way of easily getting people to prior versions.
FWIW, it's still relatively easy to get a link to a previous version, even without the UI. Using Jetpack as an example:
- See the list of tagged versions in SVN: https://plugins.svn.wordpress.org/jetpack/tags/
- Substitute the required version in the URL: https://downloads.wordpress.org/plugin/jetpack.4.5.zip
#12
@
8 years ago
@samuelsidler
Okay good to know that this change is not dead in the water just yet. So based on more end-user feedback then that UI change might still happen then.
This ticket was mentioned in Slack in #meta by lukecavanagh. View the logs.
8 years ago
#16
in reply to:
↑ 11
@
8 years ago
"Relatively easy" is not the same as 'efficient', especially when you have no idea which plugin version the person was using and they may need to do a 'stepped' upgrade depending on which version they're having to go back to. The older system was the most efficient way to communicate with end users who are not necessarily technical, but need to be helped in the quickest most efficient way possible because when it's 'go back to a prior version' it's WSOD, client's screaming time.
Honestly, if the best solution to all of these questions like 'where did this go, where did that go' that all seems to apply to Developers ONLY is 'we didn't feel the users needed this and it was confusing', just put it in a Development tab like the Admin Access and be done with it. Plugin Developers are your clients to the Plugin Directory as well. Most of us don't treat it like a 'listing service' only; it's a necessary function of our communication with users in multiple languages.
Replying to SergeyBiryukov:
If you remove this functionality, we have no way of easily getting people to prior versions.
FWIW, it's still relatively easy to get a link to a previous version, even without the UI. Using Jetpack as an example:
- See the list of tagged versions in SVN: https://plugins.svn.wordpress.org/jetpack/tags/ or in Trac browser: https://plugins.trac.wordpress.org/browser/jetpack/tags/ (no need to install any SVN software for that).
- Substitute the required version in the URL: https://downloads.wordpress.org/plugin/jetpack.4.5.zip
#17
@
8 years ago
Thanks Jim for making the strong case that both developers and users need the historical versions in easily downloadable form. Samuel, I notice you have again tried to move discussion away into a relatively closed and inaccessible area:
We'll chat about this at the next plugin directory meeting (Wednesday at 0:00 UTC, I believe). /cc @tellyworth
It would be great if you would come back and answer the questions openly. That's what Trac is here for. Open discussion.
I am really unhappy not to be able to direct our users to older versions, some of which have particular use (for example people who prefer KFM image management to the WordPress Media Library. We removed KFM at one point from Foliopress WYSIWYG but some people may have a valid reason for wanting to run that version.
End user accessible versions is long time functionality which should not be ripped out of the heart of WordPress.org plugin directory.
#18
@
8 years ago
Access to the "Development Version" is crucial as well. Updating trunk and directing users to the Development Version is how I get timely updates out to users affected by a bug or requiring an enhancement. They can test and confirm fixes and improvements before I release an updated version.
#19
follow-up:
↓ 22
@
8 years ago
Hi guys,
Elliot here from ACF.
I would like to see this removed feature added back ASAP. The new plugin repo page is looking good, but without a public page to download previous versions, plugin developers are left without any solution for users who need to rollback.
For those reading this thread, I'm happy to share with you a solution I whipped up this morning. It's a simple function to use on your website that will display a list of downloads for your plugin: https://gist.github.com/elliotcondon/e9dd5118e9eb32f0f0700f94c6349f78
#20
@
8 years ago
I don't think we doing the normal user any favors here by not including at least the last three versions of a plugin as a zip file. You can't expect them to learn and install an SVN client, but you can expect them to want an easy way to roll back to a previous version of a plugin. Be it a screw up by them or a developer releasing a version that causes fatals for some.
Case in point, I've had three different people on the Dutch Slack group ask me how do to this now since the new design went live.
#21
@
8 years ago
Thanks @DeFries @elliotcondon @dglingren @jimtrue for the real world feedback. We've all been telling the new plugin directory team about these issues for months. It's astonishing they went live with what is effectively broken software and the core of the WordPress experience.
Here's some background. Samuel Sidler and Konstantin Obenland both belong to the Apollo Team. They work for Automattic and Automattic's interests and not for the community or plugin developers.
Samuel Sidler describes himself as Apollo Team Lead at Automattic and together with Konstantin Obenland he was the guy leading the very unpopular plugin directory changes. Watch Apollo Team ignore and suppress feedback on screenshots. Watch Apollo Team ignore and suppress feedback on tabs.
Destroying the utility of the plugin directory in favour of "simplicity" is Automattic's agenda. It's not ours. @samuelsidler @obenland @matt. . Restore the links to previous versions of plugins Automatticians. Do not tell us we didn't tell you ahead of time. We did again and again. You ignored our feedback and moved feedback conversations into private Slack meetings where the discussion was less transparent.
The plugin directory is for all users and developers and is a collective service for all of us, not a marketing tool to impress community college design students.
Alec
#22
in reply to:
↑ 19
@
8 years ago
I took the basics of your code and created a shortcode. https://github.com/devzing/plugin-downloads
Replying to elliotcondon:
Hi guys,
Elliot here from ACF.
I would like to see this removed feature added back ASAP. The new plugin repo page is looking good, but without a public page to download previous versions, plugin developers are left without any solution for users who need to rollback.
For those reading this thread, I'm happy to share with you a solution I whipped up this morning. It's a simple function to use on your website that will display a list of downloads for your plugin: https://gist.github.com/elliotcondon/e9dd5118e9eb32f0f0700f94c6349f78
This ticket was mentioned in Slack in #meta by netweb. View the logs.
8 years ago
#24
follow-up:
↓ 31
@
8 years ago
I'm not in favor of bringing back the list of old versions, the times when it's needed are very few, if you booched an update it's better to push a new one with a higher version number so that everyone, not just those capable of a manual downgrade, gets the fix.
By not providing a list of old versions, we help promote the use of recent, up to date, software. This is so important, users will dislike a new feature (and subsequently ignore any security related updates) because of that change, we see this quite often.
In the rare cases where you can't make a fix and -do- need an older version, change the stable tag of your plugin and that'll become the available version in the repository (and if that's not acceptable, for example if you as an author causes fatals, it should be part of your responsibility as the developer to know enough about you own plugin to grab the previous version based on the tag numbers as described in comment:16 and provide it to your users in a forum topic or similar, we could even put it in the plugin handbook if that'd make it easier to remember).
#25
@
8 years ago
@clorith, this obsession with the latest version is really unhealthy. This is how WordPress consultants bilk clients. Everything on the latest version means that something is sure to be breaking, either WordPress 4.7.1 (recent example) or plugins.
Not every version of every plugin (far from it) is a security related update. WordPress consultants with this update frenzy appear determined to bleed our clients to death. People will get tired of WordPress and just move onto something which doesn't require constant consultant bills or endless fiddling to keep running. I don't want that to happen.
We even coded a whole plugin to keep WordPress.org off the back of our clients (reducing update pressure, controlling admin notices, enabling preferences for oEmbed, emojis, XML-RPC, REST API which should be in core). Unfortunately we can't repair the plugin repository ourselves. And you and your friends and should not have broken it against the advice of 90% of the developers who cared to contribute to the discussion.
I.e. your "hard work" workarounds - do them yourself Clorith if you want to but please let us allow our clients to live easier lives. I.e. could not disagree more strongly with both your premises and your conclusions.
Is there anyone else at charge in Automattic who wants to come out and tell all of us doing really work with clients how naive and misguided developers we are and how we aren't willing to work hard enough to be part of the WordPress community?
Alec
This ticket was mentioned in Slack in #meta by lukecavanagh. View the logs.
8 years ago
#27
@
8 years ago
+1 on bringing this feature back. Many corporate customers do not just upgrade to the latest version. And they may even update to an older version that is newer than the one they're on. Not all WordPress users are consumers. Sometimes large companies use WordPress. And in their world, access to older versions is critical.
#28
@
8 years ago
I wanted to give someone the URL to the trunk ZIP, but that's gone as well apparently. :-p
js.
#29
@
8 years ago
I too would really like to have this feature back. If not for all older versions then at least for a few.
By not providing a list of old versions, we help promote the use of recent, up to date, software.
What if the updated version has a soft bug for your specific use case in it, for which the author either has no time or is unwilling to immediately push out a new update?
Hate to be that guy but if we are foregoing usability to encourage users to be on the latest software version, why the hell are we still supporting PHP 5.2? #33381
This ticket was mentioned in Slack in #forums by jan_dembowski. View the logs.
8 years ago
#31
in reply to:
↑ 24
@
8 years ago
I've seen people ask for previous versions of a plugin on the support forums when there is a bug with the current version and that's not always the best approach, so I agree with encouraging the newest version (when there is a botched version).
Replying to Clorith:
I'm not in favor of bringing back the list of old versions, the times when it's needed are very few, if you booched an update it's better to push a new one with a higher version number so that everyone, not just those capable of a manual downgrade, gets the fix.
#32
@
8 years ago
As part of my own plugin support work I often must download older versions of other plugins to investigate and reproduce issues of interactions between my plugin and others. I believe access to older plugin versions is as important as access to the WordPress Release Archive. On the old platform, the Developers tab was easy to access and never got in the way of users who did not need it. I do not understand why popular, useful features must be deleted in the name of progress.
#33
follow-ups:
↓ 34
↓ 35
@
8 years ago
Everyone: Can we not carry on with the "me too" posts? This is coming from someone who wants the feature back :)
Stay on topic. Stay pushing this forward.
WHERE would this be best put?
What's a good place/location for the developer information that doesn't become a massive list of links?
Should we list ALL of them or just the major releases or ... what?
Dropdown or list?
Do we need the SVN links or JUST a download?
My suggestion: Wherever we decide to put this, a simple dropdown with all the available zips would be helpful. Pick a version, it downloads the zip, done. We have another ticket for SVN links, and I think making this more simple, for an end user who just needs the old version for Reasons (™) is a better choice.
#34
in reply to:
↑ 33
@
8 years ago
I hear you. That said, Sam did say, "There is no reason to close this ticket as the idea will still be considered based on feedback after launch." So one of the very real benefits of the "me too" posts is the feedback that says people really do want this feature back.
As to your questions, I think we should present:
a) a list, rather than a drop down
b) the last 5 versions
c) links to the download as a primary action (no idea about SVN links)
d) on the right, under support
Replying to Ipstenu:
Everyone: Can we not carry on with the "me too" posts? This is coming from someone who wants the feature back :)
Stay on topic. Stay pushing this forward.
WHERE would this be best put?
What's a good place/location for the developer information that doesn't become a massive list of links?
Should we list ALL of them or just the major releases or ... what?
Dropdown or list?
Do we need the SVN links or JUST a download?
My suggestion: Wherever we decide to put this, a simple dropdown with all the available zips would be helpful. Pick a version, it downloads the zip, done. We have another ticket for SVN links, and I think making this more simple, for an end user who just needs the old version for Reasons (™) is a better choice.
#35
in reply to:
↑ 33
;
follow-up:
↓ 40
@
8 years ago
Replying to Ipstenu:
Everyone: Can we not carry on with the "me too" posts? This is coming from someone who wants the feature back :)
Stay on topic. Stay pushing this forward.
Honest question. How does one let his voice be heard if all you have is frustration of it not being available, but no vision on how and where to implement this?
Replying to Ipstenu:
What's a good place/location for the developer information that doesn't become a massive list of links?
Personally, either in the Contributors & Developers section or sand a link to the download zip file would work best IMO. I quite like the idea of adding a list of downloads in a dropdown, but I'm woried how friendly this gets plugins with lots of versions. Perhaps just limit the list to the last three available versions?
#36
@
8 years ago
I would be fine with the last five versions listed under browse the code, in the Interested in development? section. Previous version on the developer tab was zip and svn inline, but I fine with just going with zip direct links.
#37
@
8 years ago
Despite comments to the contrary, I'm also in favor of bringing previous versions back, but I do think we need to "hide" them a bit. One idea that came to mind was rebranding "Admin" as something like "Advanced" so that stats would show publicly there as well. On that page, we could add a section for previous versions, along with a disclaimer. I was thinking something like...
<h>Download a Previous Version</h> <p class="warning">Previous versions of this plugin may not be secure or stable and are available for testing purposes only.</p>
I also think we should turn this into a <select>
instead of a list, along with a download button. We can limit to to most recent n (three sounds good, but ten would probably be "safer"). For one, it takes less space, but it also makes the warning seem even more important, which is good from a support perspective.
#38
@
8 years ago
Well considering "Admin" is an Admin ONLY View, it doesn't make sense to show that Section as "Admin", since the only one that will see that is a Committer to the project.
'Advanced' or 'Developers' would be appropriate and (since there's so much antagonism on showing so much information) throw Translations, Contributors, SVN, etc. all in that 'panel'. If the person logged in is a committer on the project, then add their additional capabilities to that panel of the interface.
This is one of those situations where, honestly, the tabbed interface was more 'usable'. Yes it was overkill (way too many tabs), but if you're going to be bringing some kind of 'sections' back anyway, it might be worth coming up with something that works from a usability/accessibility perspective.
#39
@
8 years ago
A quick mockup example.
http://codepen.io/lukeca33/pen/LWvEgV
#40
in reply to:
↑ 35
;
follow-up:
↓ 41
@
8 years ago
Replying to DeFries:
Honest question. How does one let his voice be heard if all you have is frustration of it not being available, but no vision on how and where to implement this?
The watch button that has a star on it. Not kidding. That's SUPER helpful to see that lots of people have interest in this ticket.
One idea that came to mind was rebranding "Admin" as something like "Advanced" so that stats would show publicly there as well.
I like that idea. We can use user-can checks to lock out thinks like commit access to people with commit access, etc. Then it's clear that it's not for newbies. We could also expand on the 'interested in being a developer...' section there, with more information about SVN etc.
#41
in reply to:
↑ 40
@
8 years ago
Replying to Ipstenu:
I like that idea. We can use user-can checks to lock out thinks like commit access to people with commit access, etc. Then it's clear that it's not for newbies. We could also expand on the 'interested in being a developer...' section there, with more information about SVN etc.
Let's move forward with that now, in the short term, to get the download options back up publicly and we can iterate from there.
#48
@
8 years ago
Thank you guys for moving ahead with integrating this sooner rather than later. The new Advanced tab is very helpful and the new download previous versions with warning is very nice indeed.
#49
@
8 years ago
- Owner set to obenland
- Resolution set to fixed
- Status changed from new to closed
In 5255:
#50
@
8 years ago
Thanks Konstantin for adding back this much needed feature. Now we just need the tabs back and we'll enjoy a fit for purpose plugin directory again.
BTW, when both Chris Lema and Foliovision agree on something, you know you've done something really wrong.
Mika you wrote:
Everyone: Can we not carry on with the "me too" posts? This is coming from someone who wants the feature back :)
Everywhere during the development of the new plugin directory, Samuel, Konstantin and Alex used the excuse there was not enough developer feedback and people don't care about these features (I've already left notes above what I think of the development and feedback process). You telling us to quiet down is the height of hypocrisy. If we don't say enough we don't care. If we say something we're too noisy. Lately there's been a lot of talk of WordPress.org and Automattic arrogance. Your post is a perfect example. WordPress.org appears to have moved back to pre-Magna Carta feudalism. The king can take our lands and any baron who raises his/her voice is banned, executed or imprisoned in the Tower.
This though is not just a me too or a complaining post.
I'm very unhappy with the language around these versions. It's very alarmist. These versions are not just for testing purposes.
Previous versions of this plugin may not be secure or stable and are available for testing purposes only.
I'd recommend something more neutral like:
For security reasons, WordPress.org recommends running the latest version of a plugin unless you have good reason not to such as removed features or compatibility.
Or:
Older versions may not be secure. Handle with care.
In any case, the word stable should not be here. Why would the earlier versions not be stable?
We could then go a bit further and start to mark with red asterisk versions which are known insecure. I know there are quite a few databases of WordPress and plugin security issues we could pull from. That's an additional feature and lots of extra work so I just mention it, I do not recommend it. GitHub integration would be much easier to build and more useful.
Alec
Old Developer Tab View