Plugin Directory: Restore links to previous versions of plugin

[jimtrue]

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'.

[jimtrue]

Old Developer Tab View

[jimtrue]

Developer Meta View (no Download Previous Versions!)

[lukecavanagh]

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.

[Shelob9]

Strong agreement. This is a super important feature of the current design. I also send my users there from time to time.

[samuelsidler]

@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.

[lukecavanagh]

@tellyworth

So just to be clear, close this ticket since this will not be in the updated plugin directory?

[samuelsidler]

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.

[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:

1. 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).
2. Substitute the required version in the URL: ​https://downloads.wordpress.org/plugin/jetpack.4.5.zip

[lukecavanagh]

@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.

[lukecavanagh]

@jimtrue

Seems like developer is still defined in the class template.

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/class-template.php#L185

[jimtrue]

"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:

1. 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).
2. Substitute the required version in the URL: ​https://downloads.wordpress.org/plugin/jetpack.4.5.zip

[FolioVision]

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.

[dglingren]

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.

[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

[DeFries]

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.

[FolioVision]

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

[WayneAllen]

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

[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.

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).

[FolioVision]

@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

[chrislema]

+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.

[jsmoriss]

I wanted to give someone the URL to the trunk ZIP, but that's gone as well apparently. :-p

js.

[DvanKooten]

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

[anevins]

I've seen people ask for previous versions of a plugin on the support forums only 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.

[dglingren]

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.

[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.

[chrislema]

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.

[DeFries]

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?

[lukecavanagh]

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.

[lukecavanagh]

Previous Versions

[samuelsidler]

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.

[jimtrue]

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.

[lukecavanagh]

A quick mockup example.
​http://codepen.io/lukeca33/pen/LWvEgV

[Ipstenu]

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.

[samuelsidler]

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.

[dd32]

In 5247:

Plugin Directory: When storing the list of plugin tags for a plugin, sanitize them for display uses.

See #2365

[dd32]

In 5248:

Plugin Directory: Rename the Admin section to Advanced and enable all users to view it (including logged out anonymous users).

See #2365

[dd32]

In 5249:

Plugin Directory: Add a previous versions download link.
This is currently badly styled, but is a POC to see how it works. The <select> uses Javascript to change the <a> button's href.
A <a> is used rather than a <button> or form submit to allow copy-paste to work.

See #2365

[dd32]

In 5250:

Plugin Directory: Add a warning to the previous download links that they're only available for testing, and not intended for normal usage.

See #2365

[dd32]

In 5254:

Plugin Directory: Fix a typo in r5248 which caused the wrong sidebar to be loaded.
Plugin committers couldn't see the committer widget.

See #2365

[jimtrue]

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.

[obenland]

In 5255:

Plugin Directory: Improve form field styles

Fixes #2365.

[FolioVision]

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