Cloudron Plugin for Wordpress

[nebulon]

Hm to take a step back, if you imagine the app being configured from the platform side with say 3 domains. Then those 3 domains are listed in the app's environment variables. Now if those are reconfigured, we would restart the app. Wouldn't that mean that adding multisite to the current WordPress app is rather trivial by simply putting the necessary migration steps into the start.sh like we do for many other settings?

This together with likely some flag in the CloudronManifest.json, if the app support multiple domains, just to avoid wrong configuration for other apps.

I have not used multisite WordPress, so I might be totally missing the point.

[Lonkle]

@nebulon I agree with exactly what you said. But, what I didn't think was possible was - how do you "tell" Cloudron that the app reconfigured something if that reconfiguration is within the app itself. My answer was "well, I'll add a plugin and ping the Cloudron API / ask Cloudron to restart the app where it'll pick up the new configuration".

Is there another way for Cloudron to know something important changed (requiring an app restart where start.sh will pick up the new config and set it up correctly) when a change happens solely inside the app (in this case, changing or adding subdomains). Sorry, I'm very new to both Docker and Cloudron as of this month (but 10 years of experience with Wordpress which was why my initial solution was a plugin but I prefer start.sh changes solely if possible).

The WP-CRON Cloudron script would need to be edited as well, but that's on Cloudron's side as well and I'll make those changes if Multisite decides to get supported officially.

[nebulon]

Well if you would configure new domains for an app to be reachable, the platform needs to do other things already like adjusting the reverse proxy settings, setting up DNS if needed, getting an SSL certificate, ... so the platform in such a case can simply assume the app needs to be restarted and trigger just that.

[girish]

At a high level, if we inject a comma separated domain list variable named CLOUDRON_APP_DOMAINS here, is that all that is needed for the app? @Lonk What changes are needed in the WordPress managed or unmanaged app, if such an env var is provided to the start.sh ?

[Lonkle]

@nebulon Yes yes - that's why I needed to use the Cloudron API, but if this can all be done from the Cloudron side, I'd do it. So, tell me, how does Cloudron know that a user changed or added a domain from within Wordpress itself?

My CPanel for Wordpress plugin, for example, sent out a CPanel API call if any domain was added or changed (from within Wordpress, of course) so that CPanel would do all the stuff it needed to do to route it it to the Wordpress installation.

[Lonkle]

@girish Well, at the highest level, yes. But box's reverseproxy.js would need to take into account the new comma-delimited Docker CLOUDRON environment domain variable, right?

Funny, those same CLOUDRON environment variables are where I store all my debug variables for containers while I've been working on my OpenVPN Client.

[girish]

@Lonk Yes, the reverse proxy parts have to be fixed. There is a subdomains table right now, where we track the domains of an app. It's either the 'primary' or 'redirect' type. When 'primary', the reverseproxy serves up the app. When 'redirect', the reverseproxy will do a 301 redirect to primary domain.

If you can tell me roughly if this env var is all that is needed from the app's point of view for multi-domain support, I can provide a quick untested patch for you to try.

[girish]

@Lonk said in Cloudron Plugin for Wordpress:

So, tell me, how does Cloudron know that a user changed or added a domain from within Wordpress itself?

It won't. Currently, configuration changes happen only one way - From Cloudron to the app. Changes made directly inside the app will break configuration. This means that if you want to add 3-4 domains to a WP multi-site install, then you have to add it in the Cloudron UI somewhere (possibly in Location view).

So, just to be in sync with the folow:

1. User goes to Location view of WordPress app. And adds some domains. We will probably allow a user to add more than 1 domain only if the CloudronManifest of the app has some flag say "multiDomain". This is because most apps don't support more than 1 domain. This seems very WP specific at this point (which is fine).
2. Cloudron will configure reverse proxy
3. Cloudron will restart the app with CLOUDRON_APP_DOMAINS env var set
4. start.sh of the app does some magic

[Lonkle]

Yes, the reverse proxy parts have to be fixed. There is a subdomains table right now, where we track the domains of an app. It's either the 'primary' or 'redirect' type. When 'primary', the reverseproxy serves up the app. When 'redirect', the reverseproxy will do a 301 redirect to primary domain.

If you can tell me roughly if this env var is all that is needed from the app's point of view for multi-domain support, I can provide a quick untested patch for you to try.

@girish I'm sorry, but that wouldn't do it because of the reverseproxy.js would have to write them as all "primary" domain config (not the redirection function in reverseproxy.js but the primary one) when that would be a hack, the real solution for box is a new domain type, "alias", and have the reverse proxy treat them the same as a primary...okay, I know that was the same thing, but one of them makes the code more readable.

[girish]

@Lonk said in Cloudron Plugin for Wordpress:

the real solution for box is a new domain type, "alias",

Yes, exactly. +1. It's better than my idea to re-use 'primary'

[Lonkle]

@girish Your idea to re-use primary would work though. It's just, after living my life in docker.js and reverseproxy.js for the past 3 days. I'd be remiss not to suggest a more readable way to code the same solution.

[Lonkle]

@girish said in Cloudron Plugin for Wordpress:

So, just to be in sync with the folow:

User goes to Location view of WordPress app. And adds some domains. We will probably allow a user to add more than 1 domain only if the CloudronManifest of the app has some flag say "multiDomain". This is because most apps don't support more than 1 domain. This seems very WP specific at this point (which is fine).
Cloudron will configure reverse proxy
Cloudron will restart the app with CLOUDRON_APP_DOMAINS env var set
start.sh of the app does some magic

That would be the exact flow.

It won't. Currently, configuration changes happen only one way - From Cloudron to the app. Changes made directly inside the app will break configuration. This means that if you want to add 3-4 domains to a WP multi-site install, then you have to add it in the Cloudron UI somewhere (possibly in Location view).

That's why I figured I needed to build my "Cloudron for Wordpress" plugin anyway just as I did for my "CPanel for Wordpress" (what I've used before starting with Cloudron now). I'll post it here, but I'd suggest it be pre-installed and activated by start.sh for if and when a site is converted into a Multisite. It can even be hidden from the user's view if need be. But I'll post it publicly on the Wordpress Repository so people can install it if they decide to convert their single site into a multisite on Cloudron (just makes the experience more seamless - the domains changed / added directly in Wordpress will sync with the Cloudron domain "aliases"). But it won't be necessary, a user will just have to add the alias in Cloudron (just like they have to do right now in CPanel without my plugin) and after that add the sub-site in Wordpress.

[Lonkle]

Either way, I will be making your minute-ly WP CRON script (which apparently runs in it's own container for some Docker-y reason) detect if the installation is a single or multisite and it will trigger the WP CRONs accordingly (all of the subsite triggers or just the single site trigger).

[girish]

@Lonk That will be perfect. Ideally, we only have 1 app for both single site and multi-site.

[Lonkle]

@girish Awesome, when I'm done with the OpenVPN Client app. I'll provide you guys with:

• An updated WP-CRON script that takes multisite into account and does extra if it's enabled.
• A "Cloudron for Wordpress" plugin that keeps domains in sync between Cloudron and Wordpress (so you can make changes from either in-app or Cloudron and everything is seamless).
• If you haven't already made it, a new start.sh script to account for the new domain "aliases" in Cloudron and anything else Multisite related.

PS. This does not mean I've given up on my fight for webhooks to be built into your API, it's just most things can be done without them.

[jdaviescoates]

I haven't really followed on the developer speak in this thread, but it'd be great if WordPress Multisite were fully compatible with Cloudron!

[Lonkle]

@jdaviescoates Upvote the feature request, my man (https://forum.cloudron.io/topic/3190/official-multisite-support-for-the-wordpress-app-managed-and-unmanaged?_=1601578395450)! ️

Also, do you guys think Multisite support should be only in the "Unmanaged" Wordpress installation for now. Maybe when we guarantee it's stability we trickle it down to "Managed"?

The only difference between the two app packages is automatic WP major updates with "Managed" and then having SFTP access with "Unmanaged", correct?

[d19dotca]

@Lonk said in Cloudron Plugin for Wordpress:

The only difference between the two app packages is automatic WP major updates with "Managed" and then having SFTP access with "Unmanaged", correct?

And LDAP support for Managed and not present for Unmanaged. But yes, I think that's about the only differences between them.

[Lonkle]

@d19dotca Interesting, I almost one to say that they should be one App Store offering with those choices (SFTP, Managed updates, LDAP). Cause as a new user I find Unmanaged and Managed Wordpress to be kind of confusing. I thought until today that Managed didn’t have plugins.

[d19dotca]

@Lonk I agree. Personally I think there should just be one WordPress app on the Cloudron App Store, would make it easier on most people I think (including the developers), but I can also understand why they made the decision for two different routes too.

One can always host Wordpress in the LAMP app stack on Cloudron but unfortunately the LAMP apps don’t allow LDAP tie-ins (which is something I’d really like to see since SSO is one of the selling points to Cloudron after all.)

Definitely room for improvement in the way some apps are packaged, IMO, but it’s honestly all such amazing work they’re doing (especially when it’s basically just two people running the show!) and I’m always happy to contribute in some small ways along with many others who are way more talented and been able to contribute a lot more than I have.

But we digress, lol. Back to the main topic...