WordPress.org

Ready to get started?Download WordPress

Forums

A Smoother Upgrade Process (11 posts)

  1. DigiproveDevelopment
    Member
    Posted 1 year 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.

  2. Barrel rider
    Volunteer Moderator
    Posted 1 year 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.

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

  4. DigiproveDevelopment
    Member
    Posted 1 year 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?

  5. Barrel rider
    Volunteer Moderator
    Posted 1 year 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.

  6. esmi
    Theme Diva & Forum Moderator
    Posted 1 year 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.

  7. DigiproveDevelopment
    Member
    Posted 1 year 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)?

  8. DigiproveDevelopment
    Member
    Posted 1 year 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.

  9. 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 :/

  10. DigiproveDevelopment
    Member
    Posted 1 year 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...

  11. golfnutt12
    Member
    Posted 1 year 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

Topic Closed

This topic has been closed to new replies.

About this Topic