Centralized "don't autoupdate" plugin list

[NickGreen]

Problem: A plugin update becomes available which starts bringing down our sites. We want to prevent more of our sites from updating to the bad version on the fly, while the situation is triaged.

Possible solution: have a centralized denylist which this plugin consults before allowing an autoupdate.

[georgestephanis]

We could maintain a rest api endpoint on https://wpspecialprojects.com/ that could be queried -- it would just preclude the plugin from ever being available on the plugin repo if it's hardcoded in.

We could put an admin setting for a url to query where we could paste that url into our own sites to check first, but third-parties using it could choose not to, or choose to have their own urls to ping?

[NickGreen]

What if we had a text file in this repo that it would consult?

[ahegyes]

I think we shouldn't host this on GitHub simply to try and avoid any rate-limiting. If we end up hosting this on Atomic servers, then we'd have more control over things like that. Both GitHub and Atomic could go down for a bit but we have more control/options for the latter.

If we're going to centralize something like this, maybe we should also return false on the auto-update when the fetching of this source fails. Better safe than sorry for a few hours until the file/endpoint is back online...

---

Also, should we maybe include a version parameter in the list? For today's example, don't autoupdate WC to 8.6.0 but anything else is fine (an emergency 8.5.3 patch or straight up to 8.6.1).

---

Since the plugin is open-source, I think a site's endpoint is better. We should also provide a way for anyone to override the source and use their own custom URL. For example, by the use of a constant if we don't want to build a settings UI ...

The endpoint could return a JSON that looks something like this:

{
	"<plugin_slug>": ["<exact_version_to_skip>", ">=<skip_anything_higher_or_equal_to>", "<<skip_lower_than>"]
}

So for today's WC case, we could have something like (any of the examples would do):

{
	"woocommerce": ["8.6.0", ">=8.6.0", "<8.6.1"]
}

---

Maybe another idea would be to prevent auto-updates to a major or minor release on a Friday. For example, an update to 8.5.3 would be ok but to 8.6.0 it wouldn't. Simply because there is a higher risk we might not catch an issue in time to handle it before Monday.

---

[pixel21]

We can host a static file on Cloudflare using either Pages or Workers. Page can be hooked to a GH repo for auto-deploy. Both the Pages and Workers have very generous free limits.

[NickGreen]

Riffing on the idea of having the centralized file be a JSON file, I propose it would look roughly like this:

{
  "pause_all": false,
  "pause_periods": [
    {
      "name": "woo_update_6_1",
      "start": "2024-02-16 00:00:00",
      "end": "2024-02-20 23:59:59"
    }
  ],
  "pause_times": {
    "start": "10",
    "end": "23",
    "friday_end": "19"
  },
  "pause_days": ["Sat", "Sun"],
  "pause_plugins": [
    {
      "slug": "woocommerce",
      "skip_exact_version": "6.0",
      "skip_version_higher_than_or_equal_to": "5.9",
      "skip_version_lower_than": "6.1"
    }
  ]
}

• All of these values would be optional
• If these values are filtered individually by local sites, the local values would take precedence

Plan of action

Step 1

• Get the plugin working with a locally stored version of the JSON file, as a proof of concept

Step 2

• Figure out where to store the json
• have the plugin pull in the data from the remote location

Step 3 (?)

• Build a GUI so that anyone on the team can easily update the JSON.

[NickGreen]

Step 1

PR up for discussion here: #24

[NickGreen]

Closed wrong issue (oops!)