I've been thinking about the auto-update and wondering some things... if all is well, it's a good thing, but things are not always well...
There could be some errors:
A different plugin with a higher version could be matched to one of my plugins/themes, either removing my intended plugin or installing an extra product.
An update could contain a bug that may cause a fatal error crashing my website. F.i. the current WPForms Pro crashes when it has no license code. It happened after auto-update.
An update could have an error in it's zip-file, either containing a different product, or have the product in an extra folder in the zip that makes it not installable. Both I have had.
An update can install the update in a different folder so the original is not overwritten and the update keeps on coming back
I'm sure one could come up with some more scenario's in practice.
So how can the auto-update and update process handle such issues, since they can all potentially cause some harm?
I think it starts with the repository (vault) itself, since it doesn't seem to prevent certain manual errors. A check on viruses doesn't prevent erroneous zip-files, only viruses.
I could imagine that after uploading a new version some code on the website could unpack it so it at least checks if the version and basename are as they are intended for that plugin/theme. And the vault admin should alert when there are already plugins with a certain basename or slug to prevent duplicate entries too. Duplicates in the vault will become a problem for the update pages.
Having such fail safes would at prevent the case of putting multiple plugins in a single zip (as a package of sub-dirs), but also other errors that seem to occur and some of them where found by me by just checking the update page list.
But if all is done to make sure that the correct zip-file is matched with the product in FV, then the matching with installed plugins and themes is the next step. I spoke in another issue about that, making the update list show installed plugins and themes and not primairy the FV vault products and matching from there.
It doesn't need to match a lot of items probably, mainly the free products that are from wordpress.org. But also should allow web admins to select themes and plugins that are not relevant or need to be skipped by FV for some reason.
What remains can be matched once to determine the ID in FV and then the ID can be remembered. If installed by FV, the ID should be remembered on install.
So there would probably not be many to consider after that. And the goal there can be to get to a single ID for each installed product or to recognize if it is not in the vault.
Since I've encountered the error of having plugins permanently marked with update signs by faulty matching, I'm wondering how auto-update would handle such scenario if it is allowed to exist and if it will try to reinstall the update every hour although it might not even install the correct plugin or theme? That would consume unnecessary resources to say the least, but is not something anyone would want.
And what is an auto-update crashes the website, will I even notice that, or can it restore the version before the faulty update? I think not, although WP itself seems to want to do that natively, adding extra checks to prevent taking down websites by updates. But auto-update makes the stakes higher, so the content of the vault must prevent more mistakes in some way to make the chance of problems happening at least lower.
I'm not entirely sure I oversee all consequences of this thinking, but I'm fairly sure starting by limiting the FV updates page to show only one item for each installed pluging/theme and using the plugin/themes real name in there would be a great starting point. Having done that, a lot of further challenges will evolve directly from that fact, I'm fairly sure of that.
As we have switched to the Auto Schedule plugin, along with the feature request to completely hide a plugin/theme from the FV update page, we will merge this request together.
I've been thinking about the auto-update and wondering some things... if all is well, it's a good thing, but things are not always well...
There could be some errors:
I'm sure one could come up with some more scenario's in practice.
So how can the auto-update and update process handle such issues, since they can all potentially cause some harm?
I think it starts with the repository (vault) itself, since it doesn't seem to prevent certain manual errors. A check on viruses doesn't prevent erroneous zip-files, only viruses.
I could imagine that after uploading a new version some code on the website could unpack it so it at least checks if the version and basename are as they are intended for that plugin/theme. And the vault admin should alert when there are already plugins with a certain basename or slug to prevent duplicate entries too. Duplicates in the vault will become a problem for the update pages.
Having such fail safes would at prevent the case of putting multiple plugins in a single zip (as a package of sub-dirs), but also other errors that seem to occur and some of them where found by me by just checking the update page list.
But if all is done to make sure that the correct zip-file is matched with the product in FV, then the matching with installed plugins and themes is the next step. I spoke in another issue about that, making the update list show installed plugins and themes and not primairy the FV vault products and matching from there.
It doesn't need to match a lot of items probably, mainly the free products that are from wordpress.org. But also should allow web admins to select themes and plugins that are not relevant or need to be skipped by FV for some reason.
What remains can be matched once to determine the ID in FV and then the ID can be remembered. If installed by FV, the ID should be remembered on install.
So there would probably not be many to consider after that. And the goal there can be to get to a single ID for each installed product or to recognize if it is not in the vault.
Since I've encountered the error of having plugins permanently marked with update signs by faulty matching, I'm wondering how auto-update would handle such scenario if it is allowed to exist and if it will try to reinstall the update every hour although it might not even install the correct plugin or theme? That would consume unnecessary resources to say the least, but is not something anyone would want.
And what is an auto-update crashes the website, will I even notice that, or can it restore the version before the faulty update? I think not, although WP itself seems to want to do that natively, adding extra checks to prevent taking down websites by updates. But auto-update makes the stakes higher, so the content of the vault must prevent more mistakes in some way to make the chance of problems happening at least lower.
I'm not entirely sure I oversee all consequences of this thinking, but I'm fairly sure starting by limiting the FV updates page to show only one item for each installed pluging/theme and using the plugin/themes real name in there would be a great starting point. Having done that, a lot of further challenges will evolve directly from that fact, I'm fairly sure of that.
Hope it helps.