Solved Domain Aliases

[Lonkle]

I'm making this a separate request from WP Multisite Official Support because it actually would cover a lot of use cases way beyond Wordpress. Almost every control panel allows for aliases in this way, and would be very helpful for Cloudron to add this as a base feature in the Location tab of every app (choosing whether you want a domain to be treated as a redirection to the primary domain, or as an alias to the primary domain - to which the web app would handle the routing - and that is currently already built in to Wordpress' Multisite feature).

[girish]

I like the idea of domain aliases in general. We can also carry over this concept to the mail server.

[Lonkle]

@girish Agreed, This is how HSphere and Cpanels use them as well. You already have the GUI for it, just a checkbox and boom.

[marcusquinn]

@girish definitely need for the mail server.

[Lonkle]

@girish said in Domain Aliases:

I like the idea of domain aliases in general. We can also carry over this concept to the mail server.

I was reading this Feature Request and was wondering if you guys have any roadmap, milestone pages in which to see what features make the cut? Or maybe you could use this very forum - if only it had any other status than "Solved" like "In Development" or "Considering". That would be really cool on here.

[marcusquinn]

We need to develop something for aliases this week, will update here if we can do independently or need to look into the box.

[girish]

@Lonk The closest we have is https://forum.cloudron.io/topic/3205/what-s-coming-in-6-0-take-2 . We only plan from one release to the next. From what we have seen, anything more "forward" looking gets obsolete/out of date very quickly. This is why I also proceeded to remove many of the WIP tags in apps. We had 14 previously, it was not a reflection of reality. It's now down to 2 or so now and it is much closer to what we are actually working on coming few weeks (this doesn't take into account all the unstable apps we have pushed out - weblate, calibre, dolibarr, moodle etc which still require work to become stable).

[Lonkle]

@girish said in Domain Aliases:

@Lonk The closest we have is https://forum.cloudron.io/topic/3205/what-s-coming-in-6-0-take-2 . We only plan from one release to the next. From what we have seen, anything more "forward" looking gets obsolete/out of date very quickly. This is why I also proceeded to remove many of the WIP tags in apps. We had 14 previously, it was not a reflection of reality. It's now down to 2 or so now and it is much closer to what we are actually working on coming few weeks (this doesn't take into account all the unstable apps we have pushed out - weblate, calibre, dolibarr, moodle etc which still require work to become stable).

That makes sense. But I do hope domain aliases make the cut. They’re the one thing holding me back! And yes, this is me holding back.

[Lonkle]

@girish I was wondering, since this is the only reason I haven't ported my Wordpress installation over yet - are domain aliases still being considered for 6.0? For me it's for Wordpress Multisite, for everyone else it's to solve the mail alias issue (I don't know the mail system, but I know this was a solution from it from @marcusquinn's comment).

[girish]

@lonk It's too late for Cloudron 6 (which is due in 2 weeks from now). We can think about it for the release after.

[Lonkle]

@girish said in Domain Aliases:

@lonk It's too late for Cloudron 6 (which is due in 2 weeks from now). We can think about it for the release after.

Awesome, I’ll numb this thread in a month or two then. ️

[Lonkle]

Found these posts:
https://forum.cloudron.io/topic/2202/multi-domain-for-the-same-app-such-as-nextcloud
and
https://forum.cloudron.io/topic/2201/domain-alias-not-redirect/4?_=1606813384424

Just to consolidate all the opinions about this request. I think 6.0 was delayed. But I'll post back here after 6.0.

[Lonkle]

@girish You ready to tackle this yet? I'll help and / or even write the code (it's just a new domain "type" in box's very simple database and then, based on that new type, routing the logic differently through NGINX which I begrudgingly dealt with too often with the VPN Client). You'd mentioned wanting to discuss it after 6.0 was out so I thought I'd bring it up as it's the honestly the only thing keeping me from switching to Cloudron.

[girish]

@lonk Sure. I already put out the feature list for 6.1, it's mostly minor things (given holiday, I doubt anything gets done this coming two weeks). So we can do this in the release after that.

Also, this posts says Domain Aliases as the topic heading. This can mean WP multisite support and/or also email domain aliases. Both features are quite different and the latter requires more work. I wouldn't work on domain aliases at the moment. For multisite, please go ahead. If you can make a rough patch and we can move things forward. I guess we inject env vars CLOUDRON_APP_DOMAIN1, CLOUDRON_APP_DOMAIN2 + configure reverse proxy + app deals with it?

[Lonkle]

@girish I forgot this also meant email domain aliases. So, I'll only be working on regular domain aliases for the purpose of WP Multisite Support at some point after the holidays! I'll submit a PR for the feature for you to test. I'll wait till the release of 6.1 to do so, just because I like working on the latest codebase and you'll likely be done with 6.1 by the time I start work on this. ️ Thanks for the go ahead!

Note, if I'm going to be coding Domain Aliases, I'll also be doing a PR for Wordpress (Managed) and Wordpress (Developer) to explicitly tie the Multisite Support together (using the WP CLI to detect if a site is a multisite and adjusting the WP Cron script slightly to account for that, as well as automatically upgrading multisite database tables on WP core updates).

[Lonkle]

@girish Wanted to make sure nothing has changed on your end on this feature request, I may find time to squeeze this feature in there when I update my OpenVPN Client code for 6.0. Depends on how difficult it is, but just seems like a slight nginx and a new database entry for aliases. Looks like the UI only has to change slightly as we only need to add "alias" as an option in the Locations tab.

[jimcavoli]

I realize it would break backwards compatibility, but I'm of the mind that aliasing a domain name should be the default and that redirects should be the opt-in. So an app called xyz.cloudron.example with a second location of abc.cloudron.example would be an alias that resolves abc.cloudron.example straight into the xyz.cloudron.example container's web port, and having the option to check a box or something to make an alias like def.cloudron.example redirect so that name when resolved does the 3xx redirect to xyz.cloudron.example. Whichever is the default is fine, I suppose, but that would strike me as more intuitive. Plus, the iconography is a lot easier (various arrow graphics indicate redirect more commonly than any other symbol indicates "not redirect").

[girish]

@jimcavoli Most apps don't support having them hosted on more than one domain. I think WordPress is just very special in this regard. For example, most of the config files of apps only allow setting a single domain name. I assume that the domain name is used in places, otherwise why ask for it all. And since it's used but they only allow for one, I can only assume that most apps don't support more than one domain. I haven't tested it of course, but just guessing from all the config files I have seen

[jimcavoli]

@girish Makes enough sense to me!

[Lonkle]

@girish Would a checkbox to make a domain a Location an "alias" instead of a "redirect" work for you then? Or would you rather I go in a different direction UX wise?

[girish]

@lonk I guess another section named "Alias" would be a good start (just like Redirections).

Is the multi-site WP app already available somewhere? I would think that is probably the biggest showstopper here and not the UI changes itself.

[Lonkle]

@girish said in Domain Aliases:

@lonk I guess another section named "Alias" would be a good start (just like Redirections).

Is the multi-site WP app already available somewhere? I would think that is probably the biggest showstopper here and not the UI changes itself.

There is no "Multisite Wordpress" Version. Multisite is just a feature inside of Wordpress (I set it up on Wordpress Developer very easily). It's a flick of a switch in the Wordpress app, it converts it's database into a multi-blog / multisite DB. Once the DB is converted tho, it can't be reverted to single site.

So, the only show stopper is the fact that another blog within a multisite uses another domain name and Wordpress itself does the routing so with Redirections, there's no way to access any other subsite in your installation because Wordpress is never given the real URL of which to route to.

Does that make sense? That's why Domain Aliases are the only thing needed for this. I have plenty of quality of life changes I've pre-built (which are really just slight additions to the startup script to account for multiple sites so all features work for all sites but 95% of the features work out of the box rn). But without Domain Alias Support even my slight startup script updates to account for multisite (which are outlined in the multisite thread), this feature actually is the show stopper (not the UI of course, but the routing logic) since multisite literally can't work without it (there is a way to use subdirectories, but most don't choose to do that - I'm doing it temporarily while aliases aren't supported within Cloudron).

[girish]

@lonk I see, let me try to understand who WP multi-site works then. I thought we had to auto configure the domains in the package, maybe that's not needed.

[Lonkle]

@girish said in Domain Aliases:

@lonk I see, let me try to understand who WP multi-site works then. I thought we had to auto configure the domains in the package, maybe that's not needed.

Well, that would be out of scope of Cloudron box code. Multiple domains can be set "per site" in a multi-site Wordpress installation and are configurable / editable. Meaning, the user edits their domain and adds one when they add a new site / blog within their multisite installation. Coincidentally, in Wordpress, they're called URL Aliases (you can even give a single post its own domain if you dig deep enough in Wordpress but most use it the default way via the "Sites" tab and adding aliases to their individual sites within the installation).

I'm currently making Cloudron for Wordpress which I'm guessing I'll add more features down the road, but right now it's only function is that it will add any domain alias additions or changes to the parent Cloudron App Container. It's a very simple plugin. Only a few lines. I'd recommend packaging it into Cloudron's Wordpress Installation like you do the SMTP plugin (but as a Must Use plugin to ensure it's always active and cannot be deactivated).

Tbh, because the UI is technically going to be in Wordpress, we don't need any UI changes in dashboard, just an API endpoint for any given Wordpress container to add domain aliases to itself. Adding an API endpoint for a special type of domain location seems well within the scope of box.

[Lonkle]

And as you can see in: https://forum.cloudron.io/topic/4219/pressbooks-ebook-publishing-based-on-wordpress-multisite?_=1610925351271

Plugins can use Wordpress' routing features as they like, so making this one-way sync of domains from with Wordpress to Wordpress Container makes the most sense to be compatible with all plugins.

Also, side note, I've never seen a web hosting platform that didn't make you add a "CPanel Domain Alias" and then a "Wordpress Native URL Alias" in multisite every time you added or edited a site / alias.

It's confused quite a few people, so this also reduces complexity for users coming into multisite. Not even hosts like WP Engine have that kind of domain integration (yet, I'm sure they will as multisite just keeps getting more popular) so this would be quite a differentiator for your platform when it comes to multisite.

[jimcavoli]

@girish The only technical requirement is that the IP gets hit with the corresponding Host header - the stumbling block is just on the reverse proxy's answer of 3xx vs proxy essentially. I think that was your understanding before, and if so, that still holds.

As far as the note about having to add things twice, that's mostly down to still just that DNS point easier and the second add would generally be to reconfigure the underlying apache running WP (and why WP Engine et al generally require a manual step). In the cloudron case though, we can just have a wildcard server and move on since this isn't a cPanel or similar environment and we do have the reverse proxy and other features keeping the final upstream links "clean." The "traditional" model for this is a server at x.x.x.x with one or many subdomains using that x.x.x.x in their A records.

[Lonkle]

@jimcavoli So, what are you proposing we do differently then a Wordpress-based one-way sync method? We could do it the other way around.

Or we could also just have the user configure their custom domain in both places (in Cloudron as an Location Alias, and in Wordpress as a URL Aliases - tho I don't like this option if only due to common user error).

[Lonkle]

@jimcavoli Or were you just explaining that having the reverse proxy send the correct domain header to the container is all that's needed to support Wordpress Multisite? If so, that's true.

we can just have a wildcard server

Wordpress Multisite supports multiple (as many as you want) top level domains, so wildcards in this scenario don't make sense to me.

[girish]

@jimcavoli @Lonk OK, I learnt a bit more about WP multisite now and tested it on Cloudron! As you said, it's really just a matter of putting a line in the wp-config and then enabling network settings in the WP admin.

I think it's quite straight forward to do something like this:

• Add a multiDomainflag in the manifest
• When present, you can add additional domains in the Location section.

Both the above are trivial to add. In fact, the nginx configuration required for the primary domain and the alias domain is the same as well, so it's easy to generate them.

However, I am stuck with one thing. It seems what WP wants really is *.domain.com (though the actual full domain can be edited after adding the site). I guess this means we should add some check box like Alias all subdomains to this app ? Internally, this will setup *.domain.com as an alias. This requires us to fix the programmatic DNS backends to support '*' as the location but this should not be hard (but a bit of work testing each backend).

Finally, I think this approach will also work for GitLab pages! (cc @atrilahiji and @mario )

[girish]

I have pushed an initial implementation for this now. Essentially, you can add aliases which can be a wildcard or any other domain on Cloudron. As always the DNS, cert setup etc are all automated. I have checked with WP multisite and it works well (I am sure there are possibly package tweaks we have to do further). I will test EspoCRM and GitLab pages tomorrow.

[marcusquinn]

@girish Cloudron simplicity - love it!

[jimcavoli]

This would also enable the Dolibarr CMS to work as well well, in theory. Worth checking on that one too

[girish]

@marcusquinn I tested with EspoCRM portals today and it works well!

[marcusquinn]

@girish Brilliant Espo Portals are going to be a game-changer for me, I'm looking at Espo as a rapid web-app development for business, almost can't believe I overlooked it for so long.

[Lonkle]

@girish said in Domain Aliases:

I have checked with WP multisite and it works well (I am sure there are possibly package tweaks we have to do further).

You da man! This was the big box change to make it all possible. There are some subtle Multisite changes, that I'll submit as PR to WP Developer and WP Managed. They involve:

1. Upgrading the databases of all subsites on on WP Update (by default, it only upgrades the primary sites database on upgrades and overlooks sub-sites which can cause conflicts) - and this requires only a few WP-CLI lines of code after a WP Update (it detects version changes and upgrades all sub-site databases right away to prevent any sites getting out of sync from the primary sub-site which automatically has it's database upgraded when needed).

2. The default WP-Cron script included in Cloudron's package runs every minute and disables Wordpress built-in Cron. Sub-sites need to be accounted for when disabling cron, and luckily, I wrote another WP-CLI that loops and runs the Cron Queue for each sub-site (if they exist).

3. (Optional) I'm writing a "Cloudron for Wordpress" Must Use plugin to make sure if a domain gets changed from within Wordpress, it adds the new domain to the list of aliases in app locations within Cloudron's Dashboard. I see you added an API endpoint for this so it'll be easy enough for me to do, though a user will have to enter in a login token or app token into the WP plugin (UNLESS you'd like to automate this on install).

[girish]

@lonk Sounds great! Let me know if you need help with the WP package changes.

[freetommy]

I try to set multisite wordpress.
but, I can't see aliases/location at wordpress app.
how or when can I set aliases ?
Thanks you very much !

[mehdi]

@freetommy What version is your cloudron ? You must have 6.1.x to be able to use multisite I think

[girish]

@freetommy @mehdi While 6.1 adds aliases support, I haven't fixed up the WordPress package yet to have the multiDomain flag. I was waiting for a PR from @Lonk but I think I will go ahead and look into it today

[girish]

The multiste changes are ready. However, I can only publish the app next week. This week there is already an update on WP developer edition pending (the mail plugin was replaced).

Initial docs are at https://docs.cloudron.io/apps/wordpress-developer/#multisite . There is also a CLI tool to convert a site to multisite (just adding that to the docs).

[Lonkle]

@girish said in Domain Aliases:

The multiste changes are ready. However, I can only publish the app next week. This week there is already an update on WP developer edition pending (the mail plugin was replaced).

Initial docs are at https://docs.cloudron.io/apps/wordpress-developer/#multisite . There is also a CLI tool to convert a site to multisite (just adding that to the docs).

Perfect! As soon as you release this, I'll get to work testing and integrating my multisite quality of life package adjustments and will do a PR for you after I'm finished testing and am satisfied it is ready for production.

PS. I've been frequenting this forum less this year than in fall - was there progress with @MooCloud_Matt in regards to repackaging Wordpress for Cloudron using a more efficient stack?

[girish]

@lonk Yes, thanks! Would love to get it tested first before we announce it to the world I will update this post once I publish it, but the changes itself are pushed to https://git.cloudron.io/cloudron/wordpress-developer-app/ if you want to build it on your own.

For the more efficient stack, what I have seen is installing some file cache for pages like WP Total Cache totally boosts performance numbers. I am wondering if we should just install this by default.

[marcusquinn]

@girish If you were going to make anything default, it ought to be the officially supported WP Super Cache.

Despite it having a lesser review rating on wordpress.org because they're not actively soliciting positive reviews and targeting negative ones for removal or improvement because it's not commercial. We tried all of them and WP Super Cache was the best results, flexibility, only one supporting fragment caching, lots of hooks and good code quality.

[girish]

@marcusquinn said in Domain Aliases:

WP Super Cache

https://wordpress.org/plugins/wp-super-cache/ right? The one developed by automatic.

[d19dotca]

@girish For what it's worth, caching tools tend to be personal preference, so I'd refrain from making anything default in there if it were me making that decision, and maybe just include some general performance recommendations in the docs instead.

[marcusquinn]

@girish Yup, I don't think you can go wrong with the official one, it's as good as core and what they use on wordpress.com

[marcusquinn]

@d19dotca In my experience they tend to be more marketing and reviews bias preferences because the paid-pro versions afford to play to that game. I can only share what we went through testing them all and coming to conclusions.

I also know that they can cause a lot of problems in hiding underlying inefficiencies, creating their own bugs, interfering with debugging.

Add in dynamic content and there really are no other options that will do fragment caching, so you either have full-page caching and no dynamic content or no caching and all the inefficiencies come back to haunt as soon as a user logs in and everything's uncacheable because one tiny part of a page is dynamic.

Granted, most Wordpress websites don't have Woocommerce or other functional features, but as people discover and add them, then then you have to come back to explain their caching plugin doesn't help for dynamic content and the whole stack needs revisiting.

I guess it comes down to what compelling difference would make one trust Automattic's core platform but not their caching methodology?

[Lonkle]

@girish said in Domain Aliases:

For the more efficient stack, what I have seen is installing some file cache for pages like WP Total Cache totally boosts performance numbers. I am wondering if we should just install this by default.

Personally, I have no issues with the current stack (even without the caching plugin, honestly, REDIS is enough for me). I just know you were working with @MooCloud_Matt in revising the stack and since I've been gone for a bit, I wasn't sure if you guys ever came to any solid conclusions in his "Wordpress Stack Comparison" thread.

[d19dotca]

@marcusquinn I agree to most of what you wrote. But just to be clear... my comment wasn't meant to be taken as to why one would or wouldn't trust Automattic's caching functionality, in fact it wasn't really meant to be about caching at all (though I admittedly didn't clarify that at all in my comment haha, my bad).

I fundamentally believe that we should strive to stay away from any kind of "bloat" and keeping it to only required plugins in the app package. This is for a few reasons (of course these are just my own opinions):

1. The WordPress Dev app package should ideally be as close as possible to a default WordPress.org install in a LAMP server.
2. The only plugins that should be included OOTB should be for fundamental requirements such as the SMTP plugin for sending emails.
3. Any plugins that aren't requirements for WordPress to function OOTB, should not be included. This keeps the app package lean, and prevents plugin "bloat".
4. Where do we draw the line of which plugins should be included and which should not? I think it's a fine line, and in my opinion should be placed right between "required" plugins and "nice-to-have" plugins. Maybe some disagree but I personally see caching plugins as "nice-to-have". There's a reason they aren't included OOTB in any WordPress installs.
5. Caching plugins in particular have a history of causing unintended side effects, as you alluded to as well. And while you and I may already understand those side effects and know how to work around them, not everyone deploying WordPress will understand that and will inevitably run into issues between what they see in the backend vs frontend and not understanding why it's behaving that way, etc. To be fair, I suspect most people running the WordPress Developer edition will already be well aware of that whole dynamic, but not everyone will be.

I just fundamentally believe that the WordPress app package should only include required functionality, no nice-to-haves no matter how many people end up installing the nice-to-have plugins anyways. I think going down the route of including caching plugins (or other nice-to-have plugins) is the wrong route to take for the longevity of this app package.

Hopefully that makes sense.

[marcusquinn]

@d19dotca I'm inclined to agree that it might be something better documented - but more-so because caching problems can cause support burdens where they are a common source of issue for the uninitiated.

I like your suggestion that documentations have comments like "we tested this and it worked for us" sort of thing.

[marcusquinn]

Anyone know/tested if domain aliases work for email addresses too/yet?

[girish]

@marcusquinn they don't , no.