What is the point of WordPress (Managed)?

[marcusquinn]

@girish Interesting. I see your point too. Thinking through all the naming options on those difference too, I can't think of anything different to you already have.

I know people can get into a lot of trouble with pluginitis and unmanaged, so it's a fair distinction to put a limit on your support to just for the Managed instance.

I still think Unmanaged could achieve similar lockdown with file permissions.

Equally, anyone just blogging, I highly recommend Ghost, which covers what would probably take a dozen WP plugins to achieve the same.

I think you're answered the main question of the post though.

[d19dotca]

Thanks for tagging me, haha. Yes I've done quite a few migrations (roughly 45+ times between 15+ apps going from managed to unmanaged and back to managed again) over the past 1.5 years or so. Been an interesting experience.

Here's some of what I've learned, for what it's worth:

• Performance: Managed always seems to perform just a bit better than Unmanaged. This is consistent in my testing. Unsure why exactly, but if I used All-In-One Migration plugin to migrate from Managed to Unmanaged or vice-versa and ran GTMetrix tests on it, Managed always won even if only by a bit in some cases. Never figured out exactly why, but it was my consistent experience. Unsure if this would be reproducible for others, may be unique to my environment and how I migrated between versions perhaps.
• Disk usage: Similar to performance above, Managed always used less disk space even for the same site (another All-In-One Migration of data). Assuming this may have to do with the way they're packaged but not certain of why yet. Meant to do more testing on that to see if I could reproduce that if I went back to Unmanaged but never completed that yet.
• SSO/LDAP: As we know, Managed is the only version that includes support for SSO, and since SSO is one of the selling points of Cloudron, it seemed a bit odd to me to use a version of WordPress that didn't have it if I didn't absolutely require Unmanaged for some reason.
• Updates: This is where I preferred Unmanaged and why I initially went to it for a while after having used Managed before, was the ability to have more control over WordPress updates - specifically the core updates (like the recent 5.5 update). Some of the sites I host are considered "mission critical" and I didn't feel comfortable leaving the updates to Cloudron (no offence, lol). But after realizing I can control updates a bit better now with more control over days and times for app updates in Cloudron, and seeing how successful the Cloudron team handles their package updates, I felt comfortable relying on the Cloudron team for that part.

I started with Managed for really no particular reason, went to Unmanaged to better control the WordPress updates, and then decided after a half year or so to go back to Managed because I really wanted the LDAP access not only for me but some clients who want access to their sites and I already host their emails so didn't want to further confuse them with different usernames/passwords (they already don't quite get it sometimes, lol). This was also more feasible once the ability to control app updates was offered for more granular control over those.

My two cents / what I'd love to see going forward for how Wordpress packages are handled:

• Simplify the package options. Find one and offer only that one package. This should save some time on Cloudron team while making it a little less confusing for new Cloudron users.
• Personally I'd recommend taking the Unmamaged one and using that, and adding in LDAP support to it. But I can understand if it's be easier to use Managed instead so version updates are controlled much like other packaged apps, and those needing Unmanaged can simply deploy then in a LAMP stack app. But in that case I'd still want that LAMP stack to have LDAP options to it which it's still missing (I guess for the same reason as Unmanaged is missing it by the sounds of it)
• I'm not certain I fully understand the attack vector that we're trying to minimize with not having LDAP access to an application like Unmanaged WordPress, but I'm sure it's valid. I also assume though that there'd be a better way to tackle it perhaps to avoid the vulnerability we're hypothesizing?

Hope the above helps a bit.

[ruihildt]

I choosed managed most of the time, because as the core WordPress is read-only, it's not susceptible to some hacking and always up to date.

[jdaviescoates]

@girish said in What is the point of WordPress (Managed)?:

One correction is that Unmanaged WP doesn't support LDAP integration (yet). This is because, in theory, it's possible then for a Unmanaged WP admin (some external user) to edit the plugin code and dump passwords in logs etc.

Ah, yes, my mistake, I got that one the wrong way around. Have edited my post.

@girish said in What is the point of WordPress (Managed)?:

WP is clearly an exception since it seems nobody uses WP without plugins unlike other apps. On a related topic, I remember in the past we considered renaming the two WP as - WP (blog) and WP (website) where the former is the managed one and the latter is the unmanaged one. Generally, if you want a host a blog on WP, you don't need gazillion plugins. So, it's in line with our "read only" code model. It's only for building websites that people put in a lot of plugins/themes.

I think you'd be hard pushed to find anyone who doesn't use a few plugins these days even if they are just using WP to blog.

I guess WordPress (Managed) is kinda sorta similar to the hosted WordPress.com offering - but even though you can't install plugins on there (well, I think you can these days if you pay), there are actually already loads of plugins pre-installed (e.g. all the Jetpack stuff).

@robi said in What is the point of WordPress (Managed)?:

I used the Managed version because I want less maintenance and lower exposure footprint.

Given core security updates are automated by WordPress these days anyway, and given that all plugins and themes still need manually updating, imho the Managed version isn't any less maintenance at all.

@robi said in What is the point of WordPress (Managed)?:

As for Wordfence, I don't remember it not working, but recently found WP Cerber which does a great job too and works fine in Managed & has reverse proxy support so you get to see the IPs attacking WP & can block them.

I've never tried WP Cerber, but Wordfence is state of the art imho.

Just having a quick compare of relevant stats on wordpress.org:

• WP Cerber has over 100k installs (quite a lot, I guess), but Wordfence has over 3 million.
• WP Cerber was last updated 2 months ago (not bad), but Wordfence was updated a month ago (even better).
• WP Cerber as 26 out of 50 (52%) support support issues resolved in the last two months. Wordfence has 421 out of 471 (89%).

@d19dotca said in What is the point of WordPress (Managed)?:

Simplify the package options. Find one and offer only that one package. This should save some time on Cloudron team while making it a little less confusing for new Cloudron users.
Personally I'd recommend taking the Unmamaged one and using that, and adding in LDAP support to it.

I agree. And thanks for sharing your experiences. Interesting about performance and disk space stuff, I wonder what all that's about?

@ruihildt said in What is the point of WordPress (Managed)?:

I choosed managed most of the time, because as the core WordPress is read-only, it's not susceptible to some hacking and always up to date.

Given:

• WordPress automatically applies security updates to core (and other plugins you choose it to update), and
• I always install Wordfence which protects against most stuff, and
• Wordfence tell me as soon as something needs updating

I don't feel my WordPress (Unmanaged) is any less secure, and I quite often update it before WordPress (Managed) gets an update

[Lonkle]

@jdaviescoates Okay, so I am a WP developer almost solely, here are my thoughts:

• Unmanaged can actually be more secure than Managed because we have to wait for one of two developers to update Wordpress to it's latest version rather than having it automatically update the minute it comes out (no time for exploits). Though, that's not to say that it's not more secure if only by it's obscurity. I'm guessing the only directory that can be written to is /plugins/ which technically negates the benefit of a read-only filesystem in /app/code/ BUT most hackers out there build scripts to take advantage of vulnerabilities and their scripts expect all the directories to be writable so some scripts will fail if they don't use the plugins directory as their entry point (Docker pun ).

• LDAP integration is possible with the security of passwords and username / emails intact despite all of the directories being writable. For instance, Cloudron can have a Must Use plugin that hooks into the login code and authenticates users based on passwords in Cloudron (meaning the users would be stored in Wordpress DB, but their passwords wouldn't be). There are other alternatives to this method, and though I have no interest in LDAP myself. I look forward to either helping or watching how @girish decides is best to integrate LDAP into Wordpress Unmanaged.

• Small point, but I wanted to second the "Rename Wordpress (Unmanaged)" to just Wordpress because the differences between the two are small enough for the average user to understand that Managed just means Cloudron does the updates and LDAP integration is built in. Their descriptions should actually contain a comparison of the two apps for users to understand better. For example, I'm not particularly dumb but I thought from reading both descriptions that Wordpress (Managed) meant no plugins. Silly misconception, but I truly believed that so their differences could be made more clear in the app store itself. In their descriptions, linking to each other would also be nice.

[marcusquinn]

@girish If you don't like "Unmanaged" as a term, may I suggest "Custom"?

[Lonkle]

@marcusquinn

• Wordpress (Custom)
• Wordpress (Developer Edition)
• Wordpress
• Wordpress (Unmanaged)
• Wordpress (w/ SFTP) <--- once LDAP gets integrated

[marcusquinn]

@Lonk said in What is the point of WordPress (Managed)?:

• Wordpress (Custom)
• Wordpress (Developer Edition)

Either of those feel good to me.

[d19dotca]

I'd propose that the Managed one become just plain "WordPress" so it fits in line with other Cloudron apps, since that deployment model of controlling the app updates is the same as every other app. And no other app like that has "Managed" after it's name.

Then the Unmanaged one becomes either still Unmanaged or perhaps more useful is "Developer" as proposed above (though removed "Edition" in my preference). I like that one.

[girish]

So, the main advantage for us (Cloudron support) with the managed WP is that the WP core files are read-only. This way we can make sure that the user does not change WordPress itself. There is this inclination of many people to go and patch this functions.php and friends. In fact, some plugins go to town by editing wp-config.php even.

If a user edits these files, this install is basically in a state where we cannot manage/update it anymore. This then means that we have to tell the user to update WP on his own (like the unmanaged WP app) and has to track WP updates himself. I am not sure what this means in the big picture but thinking out loud (mostly because one reason people use Cloudron to not have to think about tracking updates).

[girish]

@Lonk said in What is the point of WordPress (Managed)?:

• Wordpress (Developer Edition)

I really like this suggestion . Plus @d19dotca 's idea of removing the "Managed". Atleast, the titles are more positive than the managed/unmanaged

[jdaviescoates]

@girish said in What is the point of WordPress (Managed)?:

I am not sure what this means in the big picture but thinking out loud (mostly because one reason people use Cloudron to not have to think about tracking updates)

But even with WordPress (Managed) they do have to track updates of themes and plugins, which they'll almost certainly want/ need to install.

[Lonkle]

@girish Thanks! I also wanted to put this idea out there which may be a simple solution that covers this entire issue:

• Merge the two apps into one. During installation, just like a user selects LDAP, they should also select SFTP access. If they select LDAP, the SFTP option gets greyed out (until it’s supported of course). Then the third box would be “Have Cloudron manage Wordpress updates, or have Wordpress automatically update itself. Note: That plugins and themes must always be manually updated.”

That’s very very rough wording but then the app can be called Wordpress and it just has two extra options instead of just LDAP and sub domain choices during installation (like every other app).

Do people like this idea at all? I think the conveyance couldn’t be clearer IMO. To me, that solution completely eliminates all confusion and makes certain the user gets the actual installation they want / need because they chose it without having to read two descriptions of two different apps to help them decide. Eases user friction for sure.

[marcusquinn]

@Lonk I was thinking that and just about to say something similar.

I'm getting both of these reviewed this week - if we can make the "Managed" version work for our needs then it might negate the need for Unmanaged.

We have some strict rules on what's writable and by which user group all for security hardening, and they are rules that should never need to be broken. If a plugin doesn't work within them, we patch it or report back to the author. There's no room for exceptions with security.

[Lonkle]

I just found another pro / con of Managed (write only) vs Unmanaged (read only). Unmanaged is guaranteed to work with all plugins:

https://forum.cloudron.io/topic/3331/unable-to-restore-a-wp-site-via-updraftplus

I guess after deciding the way we want to go about listing Wordpress, we'd still want to see if it was easy to make big WP plugins working in Cloudron. I could look at these on a case by case basis when people post in the forums. Or, we could take the approach of, "if you want a plugin that requires read access, blah blah blah."

So during installation we may want to mention that the "Developer Edition" is more compatible with plugins.

[marcusquinn]

@Lonk IMHO there's plugins that should be publicly outed for crimes against sensibility - starting with any that try to write to their own directory instead of wp-content sub-dirs.

Still yet to test them both but I trust file permissions more than I trust wp plugins that don't respect security. No plugin has any business writing files as it pleases that could be executables.

I don't want all plugins to work - just the ones that respect WP standards, practices, file structure and security.

// end of rant

[Lonkle]

@marcusquinn I agree and would argue the best of both worlds is protected app/code but with only wp-config.php access, .htaccess access, and wp-content write access. This is to make sure Wordpress itself isn't changed but you can change the only files you need as necessary (I say that as a developer, you should never touch anything upstream from wp-content except for wp-config and .htaccess. It'd be cool if we had the ability to merge the best of these two world. Making it as secure as possible, but as compatible and developer friendly as possible.

[marcusquinn]

@Lonk I'll DM you to review our scripts for this...

[d19dotca]

Out of curiosity, what is the difference between WordPress Unmanaged and just installing WordPress inside of the LAMP app? It'd be more configuration at first in the LAMP app, that's about all I can think of. Am I maybe missing something?

I did a test today and deployed WordPress in a LAMP app, and it did really well after tweaking some things in wp-config.php and adding in the WP Mail SMTP plugin and modifying it's wp_mail_smtp.php file. The tweaks of course were just using the getenv() PHP variables setup from credentials.txt in the LAMP app, which makes it dynamic so I could setup a template WordPress and copy from there to a different domain without needing to manually setup a bunch of stuff.

This makes me wonder... wouldn't one approach (and I had sort of suggested this earlier in this thread too) be to just publish/manage the Managed one, and those of us who want to use the Unmanaged version can effectively just deploy it in a LAMP stack? Of course, no matter what I still lose LDAP which I hope to see resolved in the future for either the Unmanaged app or LAMP app, but that won't impact the WordPress app either way anyways no matter what the deployment is.

Seems to me Cloudron could just stick to the managed apps (since every other app is managed anyways) and those who want to deviate from that can use the LAMP stack instead, as I was able to do today in a test.

Maybe I'm missing something though?

[robi]

@d19dotca I just see it as a duplication of the M from LAMP.

Not sure if the Mysql DB from WP Unmanaged is independent or using the shared Cloudron one.