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.
To your bigger question, I have to think about it more. 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.
@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
-
@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
@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 Useplugin 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.
-
@girish If you don't like "Unmanaged" as a term, may I suggest "Custom"?
• Wordpress (Custom)
• Wordpress (Developer Edition)
• Wordpress
• Wordpress (Unmanaged)
• Wordpress (w/ SFTP) <--- once LDAP gets integrated -
• Wordpress (Custom)
• Wordpress (Developer Edition)
• Wordpress
• Wordpress (Unmanaged)
• Wordpress (w/ SFTP) <--- once LDAP gets integrated@Lonk said in What is the point of WordPress (Managed)?:
• Wordpress (Custom)
• Wordpress (Developer Edition)Either of those feel good to me.
-
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.
-
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.phpand friends. In fact, some plugins go to town by editingwp-config.phpeven.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).
-
• Wordpress (Custom)
• Wordpress (Developer Edition)
• Wordpress
• Wordpress (Unmanaged)
• Wordpress (w/ SFTP) <--- once LDAP gets integrated@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
-
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.phpand friends. In fact, some plugins go to town by editingwp-config.phpeven.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 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.
-
@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
@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.
-
@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.
-
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.
-
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.
@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-contentsub-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
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@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-contentsub-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
@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-contentexcept forwp-configand.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 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-contentexcept forwp-configand.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.@Lonk I'll DM you to review our scripts for this...
-
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?
--
Dustin Dauncey
www.d19.ca -
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?
-
@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.
@robi said in What is the point of WordPress (Managed)?:
Not sure if the Mysql DB from WP Unmanaged is independent or using the shared Cloudron one.
It’s using the Cloudron MySQL server, same as all the other apps. It’s shared, not independent, but of course unique databases within MySQL. No duplication exists from what I can tell.
-
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?
@d19dotca said in What is the point of WordPress (Managed)?:
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?
That would be one approach, but I still prefer to not have to manually install on the LAMP. However easy it might be, I'm not actually sure how exactly to do it!
And given the popularity of WordPress it'd be mad to not keep installing WordPress as easy as possible.
Personally I think the best route it to ditch the Managed app and to just rename Unmanaged as simply WordPress.
Of course the downside is then we'd loose LDAP.
But given Managed doesn't seem to auto-update (nor updates plugins and themes and hence actually requires just as much - or even more - manual maintenance as Unmanaged) and can't run all plugins etc, I still don't really see the point of Managed (aside from LDAP).
But of course there'll likely be others who do really want to keep Managed and so we're back where we are
