[wp-trac] [WordPress Trac] #32101: Ability to mark plugin as unmanaged

[WordPress Trac]

#32101: Ability to mark plugin as unmanaged
-------------------------------------+----------------------------
 Reporter:  damonganto               |       Owner:  DrewAPicture
     Type:  task (blessed)           |      Status:  assigned
 Priority:  normal                   |   Milestone:  WordPress.org
Component:  Plugins                  |     Version:  4.1.2
 Severity:  major                    |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+----------------------------
Changes (by apedog):

 * severity:  normal => major


Comment:

 I've now had a plugin unceremoniously deleted from a client's website when
 scheduled plugin automatic-update have run (#50034 which was marked a
 duplicate of this).
 The plugin in question uses a custom library to update from a github repo.
 Which it does successfully. It is configured properly. It knows where to
 look when updating. On the Plugins page it does not show update
 information taken from wp.org repo but rather from the correct github
 repo.

 However when this plugin is added to the automatic updates routine (using
 Easy Updates Manager), it results in its deletion. With a single notice
 appearing once:
  **The plugin has been deactivated due to an error: Plugin file does not
 exist.**
 Yup. The update routine failed (not the update of my plugin, which had no
 updates, just the twice-daily version-check routine) and the plugin just
 vanished. ''*poof*''

 This is actually the second time I've encountered this naming-conflict
 problem for a plugin of mine. In both cases I had chosen a plugin name
 with no apriori naming conflict. However at some later point someone else
 had also written a plugin with the same generic name and submitted that to
 the wp.org repository. From that point on my plugin's proper functioning
 is broken.

 This is very much a backward-compatibility breaking defect. And as such
 (bc-breaking) this ticket's severity should be set to ''major'' IMO
 (higher-ups may naturally disagree and set this back to ''normal'').
 Plugins magically disappearing is a bad experience. Not a "normal"
 experience.

 A solution would be to add a new plugin/theme header field:
 {{{
 Plugin Repository: WordPress | Github | github.com | Private
 }}}
 Such a solution would also be extensible/scalable. If at any point in the
 future WP core will elect to support updating plugins from different
 sources, this will be possible.

 With the upcoming auto-updates functionality being added to WordPress
 core, this issue needs to be addressed.
 The solution suggested by some of simply disabling update checks for
 private plugins is at best a stop-gap measure. And its a handicap of the
 plugin's functionalities.
 The suggestions of changing a plugin's name/slug or artificially setting a
 higher version are (''to put it mildly'') insulting.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/32101#comment:64>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform