Domain Aliases
-
@girish The only technical requirement is that the IP gets hit with the corresponding
Hostheader - the stumbling block is just on the reverse proxy's answer of3xxvsproxyessentially. 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.
@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 aURL Aliases- tho I don't like this option if only due to common user error). -
@girish The only technical requirement is that the IP gets hit with the corresponding
Hostheader - the stumbling block is just on the reverse proxy's answer of3xxvsproxyessentially. 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.
@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 serverWordpress Multisite supports multiple (as many as you want) top level domains, so wildcards in this scenario don't make sense to me.
-
@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 likeAlias all subdomains to this app? Internally, this will setup*.domain.comas 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 )
- Add a
-
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.
-
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.
-
@girish Cloudron simplicity - love it!
-
@marcusquinn I tested with EspoCRM portals today and it works well!
@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. -
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.
@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
boxchange 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:-
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).
-
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).
-
(Optional) I'm writing a "Cloudron for Wordpress"
Must Useplugin 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 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
boxchange 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:-
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).
-
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).
-
(Optional) I'm writing a "Cloudron for Wordpress"
Must Useplugin 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).
-
-
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 ! -
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 ! -
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).
-
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).
@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 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?
@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.
-
@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.
@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.
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@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.
@marcusquinn said in Domain Aliases:
WP Super Cache
https://wordpress.org/plugins/wp-super-cache/ right? The one developed by automatic.
-
@marcusquinn said in Domain Aliases:
WP Super Cache
https://wordpress.org/plugins/wp-super-cache/ right? The one developed by automatic.
@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.
--
Dustin Dauncey
www.d19.ca -
@marcusquinn said in Domain Aliases:
WP Super Cache
https://wordpress.org/plugins/wp-super-cache/ right? The one developed by automatic.
@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
