Skip to main content

FluentCommunity on a Subdomain with a Single WordPress Installation

We run a single WordPress installation at domain.com and are considering installing FluentCommunity on that same WordPress site.

Can FluentCommunity be served publicly under a different hostname, for example:

https://support.domain.com/portal/

while WordPress itself continues to use:

https://domain.com

as its main Site URL and Home URL?

The goal is to keep one WordPress installation, one database, and one admin area, but expose the FluentCommunity portal through the support.domain.com subdomain.

Would this setup be fully supported, including:

  • generated internal URLs
  • login and logout
  • cookies and user sessions
  • redirects
  • REST API requests
  • media uploads
  • notifications
  • assets and frontend navigation

Or does FluentCommunity require its portal to use the same hostname as the main WordPress site?

William Beem

This is what I do. My main site is suburbiapress.com. I use hub,suburbiapress.com to host FluentCRM, FluentCart, FluentCommunity, etc. That's because a publishing site has different requirements than a working site with user logins. I'm running OLS with Litespeed cache for my main site, and NGINX with Redis for the hub site.

The only thing I have on my main domain that needs to communicate with the hub domain is Fluent Forms. A simple webhook sends the data to FluentCRM on the hub site.

Let me know if you have questions or a different use case idea.

Christian Frank

Yep. That's what we do, too. Main site is: https://expatexpert.co and community is on https://exchange.expatexpert.co both on Wordpress. Webhook'd from one to the other.

zastavra

Thank you both for sharing your setups.

What we are trying to confirm is slightly different.

We would like FluentCommunity to remain installed and running inside the main WordPress installation at:

https://domain.com

with the same database, users, wp-admin, FluentCRM, and native integrations.

However, publicly, we would like the FluentCommunity portal URLs to appear under:

https://support.domain.com/portal/

In other words, everything would still run from the main WordPress installation, but the FluentCommunity frontend would be served under a subdomain.

Has anyone implemented this specific setup successfully? It would also be very helpful if someone from the Fluent team Shahjahan JewelΒ could confirm whether this configuration is officially supported.

Cointacter

zastavraΒ Dude, your setup sounds complicated. Domain Main Site, and Subdomain and then path to portal on the subdomain. Youre doing double tricks for no reason.

Of course its possible, but youre tricking yourself multiple times.

The best would be to have all as spa only, taking seo fixes into account, and i have it and could share

Cointacter

zastavraΒ your not even looking right at the basics or 1st level of your solution. You cant run same site on multiple domains, this is simply impossible. What u can do is multisite or sync users. U definitely dont want multisite environment with your capabilities, so install remote user sync plugin and use it. But using domain on WP, and subdomain with extra path for portal.. youre overcomplicating it

Cointacter

zastavraΒ and most importantly, fcom has nothing to approve about your setup. Its not fcom thing, its wp thing. Fcom would need to either already have knowledge about multisite/user sync, or to learn it just to reply to you. You should ask AI, it will explain it all for you.

Thomas Oates

CointacterΒ Technically, it is possible to run multiple subdomains on the same WP site. We're doing it right now with two WP sites that we use to provide websites for our chapters and associations. We're not running multisite, just regular WP. We have around 300 subdomains that are served from those 2 WP sites. It took some custom code but it is technically possible. Having said that, not sure I would recommend doing it.

Cointacter

Thomas OatesΒ i know how u do it. I would not do it, too wobble. I would do user sync, but thats multiple databases and Login/logout still wobble. Better try to avoid such things if you want perfection and nothing wobbleish.

David Churchill

zastavraΒ this would technically be two websites domain.com is one site, support.domain.com is the second. So no, you could not run two websites like this off one Wordpress installation.

However, you could convert your existing website into a Wordpress multi-site network. This would allow you to use one Wordpress installation, and setup support.domain.com/portal β€” but you would still need to use hooks to sync users etc with FluentCRM etc as per William BeemΒ and Christian FrankΒ suggestions.

This means one Wordpress codebase, one version of the plugins, but technically two database.

I used to run a large mult-site in the past, it’s a bit of a headache to setup, but once it’s running it’s easier to manage than two separate instances of Wordpress.

So worth looking at Wordpress MU and see if it works for you.

Christian Frank

David ChurchillΒ I tried running FComm on WP Multisite, but it didn't work out. Pageloading times were painfully slow, and even though FComm uses different database tables, plugin crashes were frequent (particularly with Duplicator Pro). We preferred to segregate domains, and then Duplicator ran smoothly.

David Churchill

Christian FrankΒ be interested to know what hosting/setup you used as it sounds like something wasn’t right somewhere. We used to run 100+ sites with WooCommerce, events and custom content.

zastavra

Thank you all for the input. The reason I’m exploring domain.com and portal.domain.com is that the main domain is an e-commerce store, while the portal would contain user-generated discussions.

My concern is SEO separation: low-quality community content should not potentially affect the perceived quality of the store. At the same time, keeping everything in one WordPress installation would preserve the native integration between FluentCRM, FluentCommunity, Fluent Support, and the other Fluent apps.

The /portal/ path itself is not important; portal.domain.com would be fine. If this cannot be done reliably, then a separate WordPress installation for the portal would obviously be the cleaner solution.

Cointacter

zastavraΒ i dont understand why u dont ask AI ? First of all why u dont wanna have it all under single Site? What is your store, Woo or fcart? I can cleanly make either woo or fcart to work in fcom Spa, with perfect seo. Even gutenberg pages i can put on fcom with perfect seo. Nobody on this planet has it like that, yes i know. U can Check shopichain.com its there as test. Is this why u wanna have separated, because fcart doesnt work in fcom Spa? In regards to SEO with my solutions, it can be controlled, u can focus on homepage, products and archives and eliminate or degrade ugc. This way you'd have everything on the same site, working in fcom Spa without the boring page reloads, and without fcom wrapper for WP..

Cleanest solution is user sync for you. Syncing users on few sites allows you to sync anything u can imagine, not just email and password. And for that u dont need help.

Zeffiro Varga

Adding our experience since we went the "two separate WP installs" route about a year ago, for what it's worth.

Main site: WooCommerce + funnel builder for sales/marketing. Second site: FluentCommunity + FluentCRM for the membership/course area. Fully separate installs, separate databases, connected via automation webhooks rather than any shared-hostname trick.

A few things that made it work reliably:

  • User provisioning: purchase/optin on the main site triggers a webhook that creates the user and adds them to the community on the second site.
  • Redirect logic: FluentCommunity's headless portal renders before WordPress's normal template_redirect, so any redirect logic targeting portal pages needs to hook in earlier than usual.
  • Enrollment/access: handled by tag application/removal on purchase, not by anything cross-site.

Fully agree with the folks above who tried Multisite and hit performance/stability issues, two clean separate installs + a solid webhook/tag layer has been much more predictable for us than trying to force one hostname to do both jobs.