WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#11281 closed feature request (wontfix)

Install any plugin version from the admin

Reported by: scribu Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description

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.

Change History (22)

comment:1 @dd326 years ago

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

comment:2 @Alphawolf6 years ago

+1 for this

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

comment:3 @Txanny6 years ago

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.

comment:4 @dd326 years ago

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.

comment:5 @aaroncampbell6 years ago

  • Cc aaron@… added

+1

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

comment:6 follow-up: @carlhancock6 years ago

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.

comment:7 in reply to: ↑ 6 ; follow-ups: @aaroncampbell6 years ago

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.

comment:8 in reply to: ↑ 7 @carlhancock6 years ago

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.

comment:9 @Denis-de-Bernardy6 years ago

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

comment:10 follow-up: @dd326 years ago

(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?

comment:11 in reply to: ↑ 10 @Denis-de-Bernardy6 years ago

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.

comment:12 follow-up: @dd326 years ago

Actually, it returns utter junk.

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

comment:13 in reply to: ↑ 12 @Denis-de-Bernardy6 years ago

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

comment:14 in reply to: ↑ 7 ; follow-up: @TobiasBg6 years ago

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

comment:15 in reply to: ↑ 14 @aaroncampbell6 years ago

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.

comment:16 @lloydbudd6 years ago

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

comment:17 follow-ups: @dd326 years ago

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)

comment:18 in reply to: ↑ 17 @Denis-de-Bernardy6 years ago

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.

comment:19 in reply to: ↑ 17 @TobiasBg6 years ago

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.

comment:20 @dd326 years ago

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.

comment:22 @dd325 years ago

  • Milestone 3.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.