Repercussions of removing the default "Disable WordPress Core Updates" plugin in managed WordPress app?
-
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.
-
@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?
-
@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.
-
-
@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.
-
-
@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.
