Changes to WordPress apps
-
There was some good discussion (thanks @jdaviescoates !) about how to best handle the two WordPress packages. We are making some changes thanks to the suggestions there.
Our primary motivation here is to just make Cloudron more WordPress friendly and also make it easier for a user to choose the correct app package. I think we can all also agree the following are needed:
- Make WordPress plugins should just work
- Make migrations/imports from existing sites just work. Sadly, many of the migration plugins bring in source code and not just data.
- Make many of the security plugins which do all sorts of crazy things like adjust the admin URL, modify files etc work. While we personally don't "vouch" for such security practices, we can't deny that WP is still the most installed app in our platform and most people install these plugins. In the spirit of picking our battles, we concede this one to the existing WP ecosystem
- Clarify expectations up front when installing the WP app.
With the above in mind: It's clear that it can only be supported in Unmanaged WordPress realistically. But "Unmanaged" as a word has a bad connotation. So, we will rename WordPress (Unmanaged) to WordPress (Developer) (thanks to @Lonk for the suggestion). We can keep the current WordPress (Managed) with the same name since it indicates it's like a managed service with subset of working plugins. This is similar to any other managed hosting WP service where they have lots of restrictions.
Currently, we don't want to remove WordPress (Managed) as such. It still has strong security benefits.
Feature Parity
We will make both the apps be the same feature wise. The only main difference will be whether you can edit core WP updates and how you do WP updates (you can read more text in the DESCRIPTION below). So, we will have the following in both:
- LDAP
- Optional redis, we will make this part of Cloudron 6.0
- SFTP access. For security reasons, this will come with a checkbox that has to be enabled for non-admins to use SFTP in LDAP mode.
- WP CLI
- Plugin auto-update feature work (which is part of WordPress).
DESCRIPTION changes
We will change the description file for both apps. This is the text that pops up when you install an app (not the postinstall, but in the appstore view).
WordPress (Managed) - See https://git.cloudron.io/cloudron/wordpress-managed-app/-/blob/master/DESCRIPTION.md
WordPress (Developer) - See https://git.cloudron.io/cloudron/wordpress-developer-app/-/blob/master/DESCRIPTION.md
-
I’m honored you chose my suggestion! I’m excited about feature parity between the two.
Would you like any help with LDAP integration for Unmanaged? I just coded a small PHP library for doing so but you mentioned security worries in Wordpress (Developer). If you open another thread, the community can talk about ways to do it securely, but you’d know best about how to do so since you guys made the Managed Version already integrate with LDAP.
-
@Lonk said in Changes to WordPress apps:
Would you like any help with LDAP integration for Unmanaged?
Thanks for the help but it's really just copy/pasting from one app to the other Hopefully, I can get all the changes done by end of today.
-
@girish Also, I read the description for both versions and your rewrites are both perfect. ️
PS. You forgot to write Multisite support for the Developer Edition - I’m still going to be writing
box
changes to support the slight database peculiarities between single site and Multisite so you can change the URL from Cloudron and I’ll be updating your WP-CRON script to work with all sub-sites (if they exist, it will detect if it’s a Multisite installation). -
@girish said in Changes to WordPress apps:
@Lonk said in Changes to WordPress apps:
Would you like any help with LDAP integration for Unmanaged?
Thanks for the help but it's really just copy/pasting from one app to the other Hopefully, I can get all the changes done by end of today.
Woah, that quick! Did you give up on your security worries of Unmanaged LDAP because it’s called Developer Edition or did you solve them?
-
@Lonk said in Changes to WordPress apps:
You forgot to write Multisite support for the Developer Edition
Hopefully, we can add multi-site to both. I have never used a multi-site WP, so I don't know if it's compatible or not with the read-only file system.
-
@girish said in Changes to WordPress apps:
@Lonk said in Changes to WordPress apps:
You forgot to write Multisite support for the Developer Edition
Hopefully, we can add multi-site to both. I have never used a multi-site WP, so I don't know if it's compatible or not with the read-only file system.
It’s compatible with a read only file system. But it would have to be chosen during installation or there would have to be an option in Wordpress Configure within Cloudron to “Convert to Multisite” but I’m more in favor of someone choosing Multisite during installation.
Multisite just adds more databases (which is fine in read only) and more folders in
/upload
(which is fine in read only). -
@Lonk said in Changes to WordPress apps:
Woah, that quick! Did you give up on your security worries of Unmanaged LDAP because it’s called Developer Edition or did you solve them?
Ah right, forgot to mention this. There is no real fix for this. SFTP access when given to normal Cloudron users to edit code..is a security problem. I think we will put a note in the docs/tooltip warning in the UI. The user has to evaluate if this is really a security issue for them. We were thinking we will add a checkbox which user has to click to allow SFTP access for non-admins.
-
@Lonk said in Changes to WordPress apps:
. But it would have to be chosen during installation or there would have to be an option in Wordpress Configure within Cloudron
Ah, it's an install time flag for WordPress? In general, is it possible to convert multi-site to single-site and vice versa (in an automated way) ?
-
@girish No no, not an install time flag. You can convert at any time from single-site to multisite. But there's no converting back once you're on multisite.
I only mentioned that you might want to do it during install time because then you wouldn't have to add an option in
dashboard
asking a user if they'd like to "Convert to Multisite (This Cannot Be Undone)" kinda thing. But doing it at install time, or after install time - just as easy.Because I had SFTP access on the Developer Edition, I was able to just enable it manually. But that does come with caveats - like you cannot change the URL in Cloudron if you're a multisite (it's stores the domain in a different place in the DB with multisite, and also in
wp-config.php
). That, and the WP-CRON that would need multisite support.The only think beyond those two things (which I could code easily to integrate with Cloudron) is real domain aliases (not redirections) would be needed. Which, after looking into reverseproxy.js, shouldn't be hard. I just am horrible at editing
dashboard
code every time I try. -
@robi The databases are shared since MySQL, PostgreSQL, Mongo etc are multi-tenant. You can setup rules to isolate users and apps. Redis is not multi-tenant. For this reason, there is a redis instance per app. Redis is ultra-light weight though, so it's not really a resource hog/issue.
-
I spotted an article recently that reminded me of this debate, and I think I can make the distinction a little more familiar:
- Wordpress (Managed) is more like wordpress.com
- Wordpress (Unmanaged) is more like wordpress.org
-
@girish said in Changes to WordPress apps:
@robi The databases are shared since MySQL, PostgreSQL, Mongo etc are multi-tenant. You can setup rules to isolate users and apps. Redis is not multi-tenant. For this reason, there is a redis instance per app. Redis is ultra-light weight though, so it's not really a resource hog/issue.
I had been wondering this entire time why Redis wasn't shared (I used LAMP a lot in my testing as did I
docker network inspect cloudron
so because you name the containers as hashes, the redis ones made it easier to identify which was which (my VPN client which had noredis
, and the LAMP client), so that was pretty useful to me funnily enough. -
@marcusquinn said in Changes to WordPress apps:
I spotted an article recently that reminded me of this debate, and I think I can make the distinction a little more familiar:
- Wordpress (Managed) is more like wordpress.com
- Wordpress (Unmanaged) is more like wordpress.org
Great comparison and should hit home, I - for no particular reason - think the name should stay, but at the end of each desciption, it could say:
"Think of this as as simple and easy "wordpress.com" but with plugin support."
Something to that affect would work to compare the two for existing Wordpress users looking to switch.
-
@Lonk The worry with wordpress.com, Shopify etc, is always the risk of de-platforming with no recourse, when they are judge & jury.
I'm convinced self-hosting federation is the future. Compared to relying on the whims of a single provider, that can have their abuse processes abused by rogue competitors is a very real risk.
These risks increase the more successful you are when rogue competition or trolls can take a dislike and interrupt innocent people & businesses at any time.
-
@marcusquinn said in Changes to WordPress apps:
@Lonk The worry with wordpress.com, Shopify etc, is always the risk of de-platforming with no recourse, when they are judge & jury.
I'm convinced self-hosting federation is the future, relying o the whims of a single provider, that can have their Abuse processes abused by rogue competitors is a very real risk, that increases the more successful you are and rogue competition or trolls can take a dislike and interrupt innocent people & businesses at any time.
Your belief in open source is one of the many reasons I respect ya, man. I think it's more important than people think or realize. Even I didn't for a lonk time. But it's important to own your future. Understand what you're running on, be able to fix something that the developer doesn't have time to because you have access to what you're running on. But seriously, I gotta brag about Cloudron's API one more time, it's amazinggggg. And half of it's private! I'll think about documenting it one day though if I find there's interest but it seems like I've been the only one interested as much in the API.