Official Multisite Support for the Wordpress app (managed and unmanaged)
-
@Lonk I am quite curious, as I am not very familiar with Wordpress : what is the advantage of running a single Wordpress install in Multisite mode, versus having multiple wordpress installs, one for each site ?
I completely understand that such a setup was probably way easier to install and maintain in a "traditional" installation, where everything is run on bare metal. But in an environment like Cloudron, where you can setup another Wordpress install in literally < 1min, I must admit it does not seem obvious to me.
-
I'm kind of on the train of thought of why does this matter. Although I do freelance development and basic hosting of other people's wordpress sites off of my cloudron so this would be my guess at a use case:
If you're running more than one wordpress app on cloudron all with different domains (for different clients) it becomes a clusterfuck to go through your apps. Alternatively with a single wordpress multisite install I can have a single app in cloudron dedicated to my client sites, and still assign different domains to the sites. Just streamlines managing the sites.
Unsure if this is what @Lonk was thinking of but I can definitely see that use case. Only reason its not a problem for me is I only host 2 sites for people so far. Im sure this would be frustrating as this number grows (if it does).
-
@mehdi Coming from using strictly stand-alone Wordpress installations to a multisite installation. Here are my reasons (though other user's most definitely will have other reasons for doing so - I worked for a company previously that used Wordpress Multisite to build a site easily and automatically whenever they added a "new location" based on the primary site's data, for example - but I personally don't use it for that reason).
-
100% shared plugin codebase. All of WP Implementers (and Developers) build modular plugins for individual client purposes (or their own). An example is that I build a plugin called "WP-Kit" and update it occasionally and when I do all of my sites instantly use that code base because in multisite there is only one themes folder (front-end code), and only one plugin directory (backend and front end code). So when applying new code you know that every site you have will be using that update. For my deployment method it's a very good thing.
-
Often times, I've needed to re-use a plugin or theme function I created for a new site because it now needs
x
feature, but can't remember which site I made it for so I have to search through my sites, client's sites, etc to find it. Multisite allows me not only find it easily in the plugin page, but instantly activate it on that new site with, again, the same up-to-date codebase for it. -
Data / organization / permissions / access. Example: WP's Multisite feature allows me to have two "WooCommerce" stores, that needed different features despite being the same brand (they were each a subdomain), and at the network page for the Multisite (where you get to view all of your sub-sites), you can check out a culmination of all stores sales (because the network has automatic access to all revenue and other store data, and then you can go to each of their backends to just show the data of that specific (site / product). I've seen a couple brands do this.
-
This one is probably the biggest reason for your average user. Developers have been very creative and have made a ton of Multisite-only plugins as well as Multisite-only features within their plugin(s). This is the biggest reason I've seen in the community for switching to multisite is this very reason.
-
Very much like what @atrilahiji exemplified. It simplifies creation or organization of Wordpress sites, both for the reasons I listed above, and because all of the issues Multisite solves (like my list of four of my main reasons for using it) just hugely scales out of control for a one human to keep track of all of the themes, the plugins, the customizations, etc. This happens with a lot of Wordpress Consulting Firms who are now switching their sites to multisite for this very reason.
Phew, I could probably give other examples, but that should be enough, I think. I'm personally very invested in the Wordpress Community (it's huge tho) and have worked with a lot of companies / clients which is why I have seen the trends over the past decade. Multisite just keeps getting growing and growing. ️ It was largely ignored when Wordpress first introduced it, but the community finally is catching up and I love what plugin developers have been able to do with the feature.
-
-
@Lonk Hey, great reasoning, and I'm all for choice if you have experience and a use-cases. My understanding is that wordpress.com itself is one super multi-site, so it can make sense for SaaSifying WP.
Having been through this decision a few years go, we actually went with single-sites, although we have the advantage of a complete GitLab CI/CD process, so we have single repos for the stack, plugins & themes then deployed to all instances on commits with the GitLab Runners pipeline.
We went this route for a more containerised approach to sites, so that issues would likely not bring down all sites, and each would be portable should the client wish to be involved or have on hosting they control.
-
https://brandlight.org is our site to explain our stack but mostly from a business perspective than technical.
-
https://brandlight.org/i/partnerships/clients/ are the sites we have live so far with this approach.
We have been actively contributing to the Distributor plugin from 10up for replicating content with a Hub & Spoke approach to managing content:
We're intending to open-source the Brandlight stack one day but for now it's a private project. If you're at that level with development then I'd be happy to invite you into our GitLab repos under trust that currently our primary needs are business development. We don't sell code, plugins or themes, and none of our work is intended for that, it's just for our own self-funded sites until we get to a point we can open it up to more clients. We have a backlog of 12 sites to get through before that though.
I have an open-mind for multi-site but actually we're going to use the Cloudron API to launch single-sites for demo & launch needs through an interface on brandlight.org at some point. So clients know they can use our hosting or their own as they prefer, with all the disclaimers that would involve of course.
For interest, with all the https://swanson.co.uk international sites you'll see on the above link and linked in the site footer, they are a single site with domain aliases handled in the code for localisation preferences.
Our overall goal is building an international enterprise Woocommerce stack, highly optimised for speed, with all the groupware features businesses need for information processing and publishing alongside handling products.
Much of what we do is optimisation for uncached speed, fragment caching, ajax etc, since full page caching doesn't work for our primary need to serve logged-in users with dynamic content.
If you like WP dev stuff, be happy to introduce you to our team in Discord. Certainly some collab opportunities for making the Brandlight stack work as a private Cloudron App initially and perhaps a public one later depending on interest.
-
-
@marcusquinn Absolutely, I don't see a need for your GIT since I'm not quite sure what you guys do yet, but I'd love to join your Discord and discuss WP related development. If they have a DM on this (most forums do), you can just DM an invite link. ️
-
I was wrong, aside from adding support for
domain aliases
as noted above, there is one more change needed to make this have feature parity with Wordpress Single Site installations. I was looking up the Cloudron source code and it uses the WP CLI to run cron manually every minute on the base domain, thiscron.sh
script (https://git.cloudron.io/cloudron/wordpress-unmanaged-app/-/blob/master/cron.sh) would need to be edited to something like:WP_PATH="/path/to/wp"; for SITE_URL in $(wp site list --fields=domain,path,archived,deleted --format=csv --path="$WP_PATH" | grep ",0,0$" | awk -F ',' '{print $1 $2}'); do wp cron event run --due-now --url="$SITE_URL" --path="$WP_PATH"; done
So that it runs that same command on every active site.
-
I think the demand for domain aliases is there so this issue will likely just fix itself. But I'll write a modified https://git.cloudron.io/cloudron/wordpress-unmanaged-app/-/blob/master/cron.sh to automatically trigger every site within a multisite's cron jobs (yeah, you have to cron per sub-site, it's silly). Technically, right now, even with subdirectories, I don't think any cron's except for the primary domains are running rn for the people that have multisite installed with subdirectories (like me).
-
I've been thinking, I would be tempted to keep going with separate WP instances (to more finely control resource allocation to specific clients) if we could create some sort of "app folder" system. Or app categories.
Not trying to invalidate this issue because its still important. But this just popped into my head. I can make a request for it.
I'm imagining something like app folders on iOS or Android or like collapsable sections.
-
@atrilahiji I agree that these two would be separate issues. I plan on adjusting the Cloudron Wordpress Project for Multisite support after @girish and @nebulon are finished with 6.0. Which I’m really hoping will come with domain aliases. Cause I can do the rest very easily (domain alias code is needed at the Cloudron level and it turned out to be a pretty popular feature request by itself which was cool). I have a decade of Wordpress (and WooCommerce) development experience and I found a new platform that I really love to work out it in (Cloudron).
The funny thing is, was that this platform was the one cloud panel I found with a no-op for DNS domain lookup which I needed for a specialized project I was working on. And I just fell in love with the platform after that - then even more after being part of the forums here. Everyone here is encouraging and it makes development fun.
-
@atrilahiji But definitely put in a request for folders for apps. That’s will def beneeded in the future with all the apps we’re coming out with now!
-
@Lonk Will do! And same, I am hoping to be able to contribute by packaging some apps and develop some apps (details coming soon) that will be set up to work quite nicely with Cloudron. Huge fan of the platform and the annual cost is a small price to pay to have this wonderful hosting experience and ensure that our lords and saviors @girish and @nebulon are compensated for their hard work.
-
@atrilahiji I may have gotten a little trigger happy with the feature requests today. I already put yours in.
https://forum.cloudron.io/topic/3220/organize-apps-into-folders-via-tags/8
-
I loved WPMU back in the early 2000s and always used to install it with SQLite. Why expose a networked DB?
It's harder to do in Cloudron as each app is tied to a single domain + aliases if set. This goes further with SSL certs and rev-proxy setup.
If all the feedback loops required are addressed it would be a welcome addition as I've just been handed ~278 domains to deal with
-
@robi As soon as Domain Aliases become a thing on Cloudron (right now they're just redirections), I'll hook Wordpress Multisite to the Cloudron API so you don't have to leave Wordpress to create the new domain either (since domain mapping is built directly into WP Multisite now).
I'll merge request the unmanaged and managed Wordpress installations with my Multisite Optimizations. But waiting for Cloudron 6.0 to do so due to Wordpress changes being released on that version, and it's release date is getting closer.
-
@robi said in Official Multisite Support for the Wordpress app (managed and unmanaged):
BTW, for those that still have to manage many WP sites individually, I recently came across something that makes it easier and it's free, called GoDaddy Pro.
I hate GoDaddy. Horrible company.
MainWP is similar and GPL (with premium add-ons):
https://mainwp.com/ -
@jdaviescoates Can vouch for MainWP, it’s a pretty cool concept because it runs inside of another WP installation which makes making add-ons (I make a lot of WP plugins) for it so much easier.