Install any plugin version from the admin

[scribu]

On Extend, there is a link to "Other versions" where users can download older releases of a plugin or a development version.

A similar link should also be visible on the plugin install box and allow users to downgrade or test pre-release versions of plugins without leaving the WP admin.

[dd32]

+1 from me for this, Here's my wp-hackers comment:

I personally see no problem with having a small "Other Versions" link to select which version to install, as well as allowing older version installs, it'd allow "current development" installs too.

Older versions are useful for debugging purposes and times when the latest version breaks something..

[Alphawolf]

+1 for this

As stated in my wp-hackers comment, I actually needed this a couple times for testing purposes before.

[Txanny]

Just have to consider that in some updates a plugin cannot be downgraded. Some can can change the way them save options and do it in a completely new format.

I think about some of my widgets, when changed from single-instance widget to a multiple-instances widget. If you downgrade, perhaps you will loose all the plugin data.

Same for plugins which create and manage it's own database table.

[dd32]

Just have to consider that in some updates a plugin cannot be downgraded

Thats definately true, and the plugin author needs to make it clear that downgrading is not a possibility for that plugin.

Users will downgrade by uploading files if they wish to, thats what i'm thinking needs to be made easier, the choice for the end user.

There'd need to be a notice on the Trunk release too "This is a development release, The author may have incomplete functions or it may not work. Please only use this version if you know what you are doing" ..Obviously written in better terms.

[aaroncampbell]

+1

As for the issue with plugins that can't be downgraded, we could just make the list of available versions filterable.

[carlhancock]

Just remember that people don't read. If you are relying on end users to read a note by the plugin developer that the plugin can't be downgraded... don't hold your breath. What is going to happen is users are going to downgrade and cause issues on their site and then get pissed off at the plugin developer as a result... despite the fact they didn't read the notice.

[aaroncampbell]

Replying to carlhancock:

Just remember that people don't read.

That's why I suggest a filter. Then if the plugin author creates a version that can't be downgraded, they can filter out the incompatible versions from the list.

[carlhancock]

Replying to aaroncampbell:

That's why I suggest a filter. Then if the plugin author creates a version that can't be downgraded, they can filter out the incompatible versions from the list.

Yea, I saw your response after I posted my reply. That is the way to go. That way only compatible downgrades are displayed and the user can't downgrade to a version that could pose compatibility issues.

[Denis-de-Bernardy]

on my own version api I use two versions: stable / bleeding. It works fine. It allows to test betas/RCs, without allowing users to downgrade (to hell with them if they don't have the latest WP).

[dd32]

(to hell with them if they don't have the latest WP).

The WordPress API as it is, Only returns the highest COMPATIBLE release i believe.. Or at least, Thats what the install API does, i think the upgrade API does the same. (Can someone confirm?)

This means, If i release a plugin update requiring 2.9, 2.8 users will not see the upgrade notice.. Combined with supporting the previous stable release of WP for security...

I think this could do with a bit of plugin developer input as well.. Bring it up early in he 3.0 cycle to see what they think?

[Denis-de-Bernardy]

Replying to dd32:

(to hell with them if they don't have the latest WP).

The WordPress API as it is, Only returns the highest COMPATIBLE release i believe.. Or at least, Thats what the install API does, i think the upgrade API does the same. (Can someone confirm?)

Actually, it returns utter junk. It'll return the latest stable version, even if the installed WP version is incompatible with the new plugin. You don't need to pass a user agent in there to get a response, let alone a wp version. which is a fine idea in itself, but it also means that some users might upgrade plugins before they upgrade WP.

[dd32]

Actually, it returns utter junk.

...But it returns correct when a standard unmodified WordPress install calls it... Right?

[Denis-de-Bernardy]

Replying to dd32:

Actually, it returns utter junk.

...But it returns correct when a standard unmodified WordPress install calls it... Right?

woops. indeed it does. :-P

[TobiasBg]

As a plugin developer I want to oppose this feature request.

There are reasons why new plugin versions are released, for example because they fix security issues. And now we are making it easy for users to use old, outdated, and insecure versions? Come on. We are pleading our heads off that users upgrade their WP to the most recent versions, but for plugins we allow them to actually downgrade?!

Regarding the filter for downgradeable versions: This adds even more work to plugin developers! They'll also have to maintain such a list, only to have users use old plugin versions for which they will in turn request support.
I'd rather use my time for actual plugin development and enhancement, than having to deal with downgraded plugin versions...

If you want to set the bar for new plugin developers higher, just go ahead, but I really dislike this idea.
(I acknowledge though that there might be a need for a downgrade of a plugin, but how often does that happen? And if a user really wants to do that, he should be able to go the manual plugin downgrade/installation road.)

[aaroncampbell]

Replying to TobiasBg:

It seems to me that if you have a security fix that is really that major, you could use the filter to not allow a downgrade from it. I know that's another step for the plugin developer, but I *do* see reasons to allow the user to downgrade.

Consider this scenario: You have added feature X. The user upgrades to the new version. They realize that the plugin now conflicts with another plugin they have.

I think in this case the user should be able to decide if feature X is worth removing the other plugin or if they want to just downgrade and report the problem.

Similar to the above scenario, giving the user the ability to "undo" an upgrade may actually cause users to upgrade more often simply because it gives a feeling of security.

[lloydbudd]

-1
Doesn't pass the 80/20 test... this feature would likely be useful to much less than 1% of WordPress users.
Plugin territory.

[dd32]

There are reasons why new plugin versions are released, for example because they fix security issues.

If there was an ability to mark certain version of your plugin as "obsolete" or "insecure" would that change anything? (out of interest)

[Denis-de-Bernardy]

Replying to dd32:

There are reasons why new plugin versions are released, for example because they fix security issues.

If there was an ability to mark certain version of your plugin as "obsolete" or "insecure" would that change anything? (out of interest)

I'm in agreement with him, myself. If it's possible to fetch the latest stable and the nightly for testing purposes, fine. But allowing to grab obsolete and/or insecure plugins seems kind of weird.

[TobiasBg]

Replying to dd32:

If there was an ability to mark certain version of your plugin as "obsolete" or "insecure" would that change anything? (out of interest)

Well, for me personally, all old versions of my plugins are obsolete. Because they potentially are buggy. Therefore I don't like users downgrading to it, because they will ask *me* with their support questions.
Then (as mentioned by someone before) some data structure within the plugin (data storing, option storing, whatever) might change and is not revertable. So I would also need "impossible to downgrade".

(I like the idea of marking old versions as "insecure" though, because that might get people to upgrade faster.)

My point is: With this "feature" we are putting a lot more "administrative" work on plugin authors (mark versions as "something", downgrading users have support questions, downgrading users lose their data and are mad, ...).
And for what? Because a few users are to shy of downloading the zip-file and installing it manually? This gain for few is just not worth the trouble of many.
This effort is better to be put into avoiding the need to downgrade by better testing or whatever.

Regarding usage of this feature for testing development versions (like westi's plugin does for core): If one wants to do this, he should also be able to install the dev release manually. But the average user will just be confused.

[dd32]

I'm starting to consider that adding this might be a bad idea. Whilst originally it sounds like a cool idea.. it does have the issues other posters have mentioned.

I think we need to add some hooks into the plugin info dialogue to allow a plugin to do this properly, I know of 1 plugin which attempts to add a "Install dev version" item, and thats pretty much impossible without JS atm.

[hakre]

Related: #9757, #10596

[dd32]

I'm going to suggest leaving to plugin zone. If anyone attempts the plugin, and finds they need a hook in a specific place in the UI, please open a new ticket and reference this.