A Smoother Upgrade Process

DigiproveDevelopment
(@digiprovedevelopment)

13 years, 2 months ago

Background: I am a plugin author. Our plugin needed work to make it compatible with 3.5, which we did as soon as we discovered a problem. However we are still dealing with users being locked out of their sites after upgrading to WP 3.5, without upgrading our plugin beforehand. It seems that 3.5 cost a lot of grief for users; maybe this was no worse than earlier releases, but one would hope it was a one-off.

I think there is much that can be done to avoid such situations in future, but from browsing the “make” forums I don’t see any recognition of this as an issue. I suggest:

1. WordPress upgrade automatically disables plugins or themes not marked as compatible with the new release (or upgrades to a release that is marked as compatible)

2. WordPress addresses the problem where display of warning or notice messages can actually cause loss of display/function (Warning: Cannot modify header information).

3. WP provides a decent error-trapping mechanism that works across plugins and themes, and can include e.g. auto-deactivation of plugins causing warnings on web-page display or leading to loss of function.

4. (Perhaps) Upgrade process (of both plugins/themes and WP itself) has an auto-restore function to previous release if after a period of time user has not logged in and ticked a box to say he is happy.

I realise that the makers of WP are volunteers and it is a community project and I thank them for creating it, but in my experience most of today’s WordPress users are not developers, and if WPs success is to continue we should recognise this.

Viewing 10 replies - 1 through 10 (of 10 total)

Andrew Nevins
(@anevins)

WCLDN 2018 Contributor | Volunteer support

13 years, 2 months ago

It seems that 3.5 cost a lot of grief for users; maybe this was no worse than earlier releases, but one would hope it was a one-off.

That’s a strange way to look at it. WordPress isn’t built to comply with plugins. It’s more the other way around.

Moderator Ipstenu (Mika Epstein)
(@ipstenu)

🏳️‍🌈 Advisor and Activist

13 years, 2 months ago

This was what I’d call a ‘normal’ upgrade for a major release of WP. About the normal amount of problems.

But Andrew’s right. Plugins (and themes) are responsible for keeping up with WP. When a beta comes out, you should test etc etc. If we disabled plugins not marked as compatible, we’d hurt all the plugins that didn’t update that field becuase they didn’t have to. Error trapping is hard, since you can do, literally, anything with a plugin.

And users can always go in via FTP to delete a plugin.

Thread Starter DigiproveDevelopment
(@digiprovedevelopment)

13 years, 2 months ago

If that was a normal upgrade with a normal number of problems then there is no room for complacency about quality. Are there standards or benchmarks to which the commnity aspires?

Yes I agree with both of the points about plugins, they should be following the core and they should be tested against beta and rc releases. Yet there are over 23,000 plugins; being real about it, the vast majority of them wuill NOT be tested in this way.

Again I take the point that automatically de-activating plugins during upgrade is a drastic step. But it would force plugin authors to do that homework before a major release. A similar logic led to the decision to start issuing warning messages in 3.5 for plugins that were non-conformant.

Is it really acceptable to say users can always go in via FTP to delete a plugin? Is WordPress only for IT-savvy users?

Yes, error-trapping is hard, but PHP has those facilities why can’t they be used?

Andrew Nevins
(@anevins)

WCLDN 2018 Contributor | Volunteer support

13 years, 2 months ago

Are there standards or benchmarks to which the commnity aspires?

Yes, a 0.22% monthly complaint rate of the quantity which it was downloaded is something to strive for. A success.

esmi
(@esmi)

13 years, 2 months ago

I take the point that automatically de-activating plugins during upgrade is a drastic step.

I’ll say! What about caching plugins? In many cases, unless they are deactivated following a very specific procedure, deactivation can completely bork the site.

I appreciate the principle but I’m not sure WP can be that heavy=handed in the Real World.

Thread Starter DigiproveDevelopment
(@digiprovedevelopment)

13 years, 2 months ago

Andrew, thanks for that. I’m not sure qualitatively whether .22% complaint rate is actually a good number, but I like it because it is a real number. To WordPress makers: Does WordPress development community measure its performance against this benchmark, and how is the trend (up or down)?

Thread Starter DigiproveDevelopment
(@digiprovedevelopment)

13 years, 2 months ago

How about the most harmless check of all: Check whether any of the active plugins installed are not at an older version that is not marked as compatible with the new WP release but the latest version is marked as being compatible. Suggest to the user to consider upgrading those plugins first.

This would have save some users some pain.

Moderator Ipstenu (Mika Epstein)
(@ipstenu)

🏳️‍🌈 Advisor and Activist

13 years, 2 months ago

Suggest, yes, but what if the plugin doesn’t have an upgrade? Or need one, and the author has yet to update the readme?

It’s a really wonderful idea, but impractical, given that .org isn’t the ONLY place people use to get plugins and themes :/

Thread Starter DigiproveDevelopment
(@digiprovedevelopment)

13 years, 2 months ago

Mika,

This suggestion should only be made if:
– the currently-installed version is not marked as compatible with the WP release now being installed and
– a later version is in the WP repository and
– that later version is marked as being compatible with the new WP version

It is easy to implement, it will reward plugin authors who go to the effort of ensuring their plugins are compatible and updating their readmes, and it will help a lot of users avoid pain.

You’re right it does not help users of plugins whose authors don’t test for compatibility or whose authors do not use the WP repository, nor does it disimprove the current situation for them…

golfnutt12
(@golfnutt12)

13 years, 2 months ago

I keep getting this message after I upgraded. I’m blocked out of my webpage now. Anyone know how to fix this?

Fatal error: Cannot redeclare get_udims() (previously declared in /home/content/g/o/l/golfnutt12/html/wp-admin/includes/image.php:173) in /home/content/g/o/l/golfnutt12/html/wp-admin/includes/deprecated.php on line 73

http://www.memphishomestore.com