Repercussions of removing the default "Disable WordPress Core Updates" plugin in managed WordPress app?
-
Hello,
I'd like to ultimately take control of the WordPress updates if possible. I think I can migrate to the Unmanaged WordPress app, but was wondering now that there is no use of the "must-use" plugins, is it okay for me to remove the "Disable WordPress Core Updates" plugin that's there by default and use an updater plugin to update all plugins, themes, and now also the core WordPress updates?
Is there any repercussions or assumed issues with making such a change? I'm wondering what also happens when there is a new app update through Cloudron for the (managed) WordPress app, will this negatively impact things? If anybody has any experience with this type of change, I'd appreciate your insight.
And on a similar topic, what if I chose to leave things the way they were by default... might it be a good upgrade to remove the default "Disable WordPress Core Updates" plugin with a plugin called "Easy Updates Manager" which allows to disable core updates still but auto-update plugins and themes? I know I can just do this anyways for updating plugins and themes but it seems almost redundant to have two plugins that overlap in their goal. So maybe the "Disable WordPress Core Updates" plugin could be replaced in the future with "Easy Updates Manager" to allow automatic plugin and theme updates while still disabling core updates. Just a thought.
-
The general approach for Cloudron apps is, that where possible we disable the built-in updater, not because it might be broken or anything, but it simply makes it impossible on our side to test updates. Also when app internal updaters are used, they do not ensure that a backup is taken prior to updating, which makes it impossible to restore in a timely fashion.
For WordPress we have decided some time ago to add the unmanaged version, since WordPress is just an app with a vast collection of addons, many of them want to change the WordPress instance in ways which make it also impossible for us to ensure tested updates (thus unmanaged, to indicate that the user/admin is on his own if something breaks) -
The general approach for Cloudron apps is, that where possible we disable the built-in updater, not because it might be broken or anything, but it simply makes it impossible on our side to test updates. Also when app internal updaters are used, they do not ensure that a backup is taken prior to updating, which makes it impossible to restore in a timely fashion.
For WordPress we have decided some time ago to add the unmanaged version, since WordPress is just an app with a vast collection of addons, many of them want to change the WordPress instance in ways which make it also impossible for us to ensure tested updates (thus unmanaged, to indicate that the user/admin is on his own if something breaks)@nebulon Thank you for the explanation, that makes sense and is pretty much what I was suspecting. Quick question: If I remove the Disable WordPress Core Updates plugin and you deploy a new app version, will it automatically add it again? I suspect that'd be the same either way even if using Unmanaged, right? Because the Unmanaged has the redis plugin by default for example which I'd have no use for and would want to remove, but would be a bit annoying if it kept coming back with each app update. Can you please clarify how that part works?
-
Generally it makes no sense to try to work around specific behaviors in the app packages. For example we might decide for a package upgrade to move to a different update suppression mechanism and then the behavior around enabling/disabling that plugin is irrelevant.
We try to strike a solid balance on the managed apps, but we simply cannot reliably support all the possible configurations and addons especiallly for WordPress. In such cases if more advanced configs are required, it makes more sense for us to step out, which is why there is the unmanaged flavor for WordPress.
-
Generally it makes no sense to try to work around specific behaviors in the app packages. For example we might decide for a package upgrade to move to a different update suppression mechanism and then the behavior around enabling/disabling that plugin is irrelevant.
We try to strike a solid balance on the managed apps, but we simply cannot reliably support all the possible configurations and addons especiallly for WordPress. In such cases if more advanced configs are required, it makes more sense for us to step out, which is why there is the unmanaged flavor for WordPress.
@nebulon Sure, that makes sense. The only conflict I see there to some extent is the unmanaged version also includes two plugins by default, one of which I think everyone will need which is the SMTP plugin, but the other is a redis plugin which I would have no use for on any of my sites, so I'd want to remove it but it'd kind of be disappointing if it were always pushed back into the plugins list with each app update. I'd almost think the unmanaged version should have zero plugins, possibly the SMTP one only. Otherwise it's a similar boat... try to delete a plugin that's there by default and boom, it comes back again with the next app update.
-
Yes I agree with your comments about the unmanaged one and the current package also pretty much does what you expect: https://git.cloudron.io/cloudron/wordpress-unmanaged-app/-/blob/master/start.sh
So upon first run, it would install both plugins and from that point on will only update their configuration upon restart. This should be harmless when the plugin is disabled or even uninstalled as far as I understand. The SMTP plugin is installed by default to ensure mail delivery and the redis one only since we've also enabled redis Cloudron addon in that to provide a cache method.
It looks to me things are already setup as you wanted them to be then in the unmanaged flavor?
-
Yes I agree with your comments about the unmanaged one and the current package also pretty much does what you expect: https://git.cloudron.io/cloudron/wordpress-unmanaged-app/-/blob/master/start.sh
So upon first run, it would install both plugins and from that point on will only update their configuration upon restart. This should be harmless when the plugin is disabled or even uninstalled as far as I understand. The SMTP plugin is installed by default to ensure mail delivery and the redis one only since we've also enabled redis Cloudron addon in that to provide a cache method.
It looks to me things are already setup as you wanted them to be then in the unmanaged flavor?
@nebulon If I disable or delete the redis plugin, will it come back with the next app update? If so, then no this does not really satisfy the requirements as even in the unmanaged WordPress instance I still don't have full control over the plugins and behaviour of the site. In my case, for example, I'd have zero use for the redis plugin. So I'd delete it, but it's not worth it if it's going to come back again with the next app update, know what I mean?
It definitely fits the use-case for updates to WordPress itself, but it sort of just seems like it creates a different issue then for me where I still don't have full control over the plugins.
Basically, managed or unmanaged, it seems I don't have full control over the plugins.
-
Maybe I wasn't clear in the previous post, but you should be able to uninstall the plugins as you like in the unmanaged one, only on first run it would setup those two plugins for convenience. That's all.
@nebulon Ah, interesting. Yeah I didn't get that out of your last post, sorry if I misunderstood it. I guess I was reading the start.sh script wrong, because in my limited ability to understand it, it seems that it deploys and activates that plugin assuming each time that script is run. So I'd have assumed then that an app package update would have provided that again.
If the start.sh only runs on the very first install of the app and never again, does this mean that the managed one would be okay too if I simply disabled the core update plugin then and used my own? Because if that's the case then I'd just keep using the managed one as I wouldn't see any benefit to going to unmanaged in that scenario.
Maybe a quick clarification on how the start.sh gets run / when it runs might help me better understand.
-
-
The crucial line is https://git.cloudron.io/cloudron/wordpress-unmanaged-app/-/blob/master/start.sh#L15 where it would decide if this is the first run or not. The start.sh is the entrypoint of the app and thus run every time it starts up.
@nebulon Oh! That's awesome, thank you for being patient and clarifying that for me. I appreciate it. So I see that now, it looks like if I'm reading it right it will only run that part to deploy the plugins if that directory does not already exist, and since it will exist of course then it would never be executed. Makes sense. Thanks again! This definitely helps, I appreciate the education on it too.
