What is the point of WordPress (Managed)?
-
• 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).
-
@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 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.
-
@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.
-
@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 -
@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?
-
-
@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.
-
@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
-
Our Brandlight team has started work on moving our WP sites to a Cloudron instance this week. You'll have many WP optimisation experienced devs on this, so we'll bring back our conclusions and optimisations soon. Watch this space
-
https://brandlight.org/ is now running on Hetzner + Cloudron + Wordpress (Unmanaged).
More feedback to follow. Our first challenge is the domain aliases we have for other multi-region / multilingual websites.
Cloudron & WP Apps are about to get a lot more attention from our devs
-
@d19dotca said in What is the point of WordPress (Managed)?:
Out of curiosity, what is the difference between WordPress Unmanaged and just installing WordPress inside of the LAMP app?
Until 2-3 releases ago, the main way to get "code" into the LAMP stack was via SFTP (i.e no file manager). We used to get like one support request everyday asking how to install WordPress into LAMP stack because SFTP will fail in many ways (you have to open port 222, people forget sftp:// in filezilla, cloudron SFTP username has two "@" and is sometimes is rejected by clients etc). Our solution was to make a LAMP stack with WP pre-installed, which is essentially Unmanaged WordPress
The other thing Unmanaged WP app has is the WP CLI. It's very useful for automation.
-
Cool - WP CLI is essential for us - good to know.
