Cloudron Plugin for Wordpress

[Lonkle]

I'm making this right now mostly for Cloudron Multisite support (distributing Cloudron's minute-ly cron call across all subsites and syncing domains and domain changes up with Cloudron). If the new feature of Domain Aliases passes then I'll also use this plugin to allow for adding subsites with subdomain support.

Anyway, the reason I made this post was #1, to ask if you guys would like it made public for anyone to use as I work on it (just upvote if you want me to make it public)? And #2, do you have any other ideas for integration between Cloudron and Wordpress that you'd personally like me to add while working on this (doesn't matter if it's single site or multisite related)?

[nebulon]

I don't know much about WordPress multisite, however few quick questions:

• Do you plan to package a separate WordPress multisite app package or integrate into the current one?
• Why is a plugin required and can it not be done during start.sh for example?
• In the plugin case, are you intending to call back the Cloudron for subdomains or how would I have to understand this?

[Lonkle]

• Plugin vs WP Unmanaged Cloudron App modification: That's a conversation I wanted to have with you and @girish actually at some point. My changes can be made on Cloudron's side and that would be the ideal path (doing it at the start.sh / Docker level). But Multisite support is undecided as per the "Feature Request" tab so I didn't know if you'd be willing for me to do the work to edit the official Umanaged Wordpress Cloudron app package given what you told me about you guys having to take over "maintenance after the original developer leaves." So, to me, a Multisite plugin is all I have control over unless you guys decided you wanted Multisite support build directly into your official app package in which case, I now have enough knowledge to do so.

• Until you and girish decide if you want the official app to support Multisite, the plugin would use the Cloudron API and as soon as as any domains have changed in the Wordpress Multisite App, it would sync those changes with the Cloudron app via the Cloudron API. Right now, if you use Multisite on the Unmanaged Wordpress installation, and you change the domain from the Cloudron side, the entire installation breaks because the domain in the database is configured differently in multisite mode (my plugin can't account for anything that Cloudron does though, only an updated WP Unmanaged package could fix anything on the Cloudron side so that would still be broken even if I made my plugin...Cloudron webhooks would allow me to account for this from within the plugin but I'm hoping you and girish let me make the necessary edits to your app instead since that's the cleaner approach). This plugin would also distribute your minute-by-minute WP-CRON initiation from just the primary site, to all subsites (which can likewise be done at the Cloudron app level using the WP CLI which you already use for single site installations).

• The only thing that I can't seem to get around when it comes to Multisite where it needs a plugin is if a user:

A) Changes a domain from within Wordpress without adding it as a Domain Alias (an upcoming Cloudron feature) first in Cloudron so Cloudron would need to know this info and my plugin would sync it.

B) Creates a new sub-site and during the process they put in their subdomain but forgot to put the domain alias (or primary domain if they chose to change that) in Cloudron's control panel. My plugin would pick that new subsite domain up and add it to Cloudron's future domain alias feature.

These two situations can happen and a user wouldn't think twice before doing it "the Wordpress way" like they're used to doing. So, at the very least the plugin would just monitor new domain additions (since Wordpress now officially supports internal domain mapping and adding), or domain changes, and syncing them with Cloudron the second they happen on the Wordpress side.

Note: In those two cases, the user would just need to go back to Cloudron and configure their new domains. So A / B aren't that big of a deal. We have to do the same thing with all other "control panels". I, in fact, made a CPanel plugin (before I fell in love with Cloudron) to do A / B using the CPanel API so I'd just be re-using that code. I have no idea if you'd want to make it a mandatory-on-installation plugin (like the pre-configured SMTP plugin), but it would mitigate situation A / B and reduce user's confusion. No other "panel" has that kind of tight integration with domains and their aliases.

[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...

[Lonkle]

@d19dotca Thanks for your input. I happen to feel the same way about this as I do about the LAMP app. In the store, just let me choose my PHP version and only have one LAMP app. I think this method has a better conveyance for new users of Cloudron. But, admittedly, this is harder work than having them separate - but it's food for thought for the developers.