Possibly related, unsure, but for what it’s worth I actually preferred the old UI for configuring an app. It seems the new way just involves at least one extra tap/click and doesn’t really solve anything, at least not in my own use of the product. Totally get the minimalism approach and I’m generally a fan of that but in this case the UI for configuring an app seems like it went back a step. Just my two cents. Maybe there’s a “meet in the middle” approach that would work better from how it was before to how it is now? It still works for me so that’s the most important part. Haha.

@nebulon So to confirm then... 4.2 isn't really released at all then yet. It's pretty much in a "beta" state, used for new installs but nobody with an existing install will have received it yet unless we formally request our domain be whitelisted. Is that correct? There seems to be confusion here with the way things are being worded. 17 days ago it was stated "The initial 4.2 was pushed out yesterday" but now you're saying "we don't push out 4.2.0 yet" -- this is creating a bit of confusion.

@nebulon & @girish - my Cloudron still shows 4.1.7 when I check for updates. I would definitely say this should be a feature request then that is a user manually clicks/taps the Check For Updates button, the latest build is presented. It would only generally be used when someone is aware of an update and expecting to install it. I understand the blacklist/whitelist thing but I would say it should be ignored when the button is pressed. The rollout using a blacklist/whitelist should only be done for those who don't manually use the button so it notifies them when it's ready.

@nebulon Okay, I kind of understand that methodology but I would still like to request then that for the future, when a user manually checks for an update it's because they want to update so that should be sort of auto-whitelisted (not to mention it would save you some unnecessary support emails). I can appreciate and totally understand scattering it for automatic download types, but it should be understandable from your side too that when a user is manually tapping the Check For Update button it's because they already know there's a new update out and are ready to deploy it. So it'd be great if that auto-whitelisted the domain.

I had recently already asked this and you may want to see this response: https://forum.cloudron.io/post/4373

@girish how do we force it? I assumed when you said it’s take a while to roll out to existing Cloudron’s I figured that’d only impact the automatic ones, but that it’d still be usable if manually requested in the Settings page using the Check for Update button, however it won’t find it when I do that. Is that intentional?

@nebulon Will it also show email disk usage? It’s not explicitly an app but it’d be very useful to understand how much disk space is used by email accounts and ideally digging deeper into which email accounts are consuming what amount of disk space.

@girish Perfect! No worries, was a long weekend for me too in Canada.

@affinity Ah, okay, that makes more sense now. Thanks for clarifying. I had forgotten about the “unmanaged” WordPress app not having the recommended plugins for LDAP auth and SMTP and stuff.

@affinity - I'm not sure I fully understand, because you stated that you followed my instructions but then "ran into a few issues" but what you stated was what I had already mentioned... that you need to select the "Do not export must-use plugins" option and restart the target WordPress instance afterwards because as my steps indicated "I find access is lost to the main LDAP admin user until a restart". So I wonder if maybe some steps were missed? Because it seems your words for future users was the same as what my instructions already had included. No? With my steps, you would not need to reconfigure any LDAP or SMTP plugins that are included in the managed WordPress app.