Cloudways integration

[Ultrarooc]

When integrating Ultimate Multisite with Cloudways and following the integration instructions precisely, I noticed that SSL certificates weren't being generated for the custom domains. It turns out that Cloudways adds subdomains, custom domains, and the wildcard subdomain "*.reddomain.com" (according to the configuration in "wp-config" (WU_CLOUDWAYS_EXTRA_DOMAINS)). My conclusion was that the wildcard SSL certificate was preventing the generation of SSL certificates for the custom domains. So, I deleted the "WU_CLOUDWAYS_EXTRA_DOMAINS" configuration in "wp-config," removed the Cloudways wildcard SSL certificate, and generated a new standard SSL certificate for the main network domain. Now everything works as expected. I think the guide needs updating so others don't make this mistake and abandon this integration.

[superdav42]

Thanks — confirmed the previous wording was actively suggesting the
configuration that breaks SSL for tenant custom domains, and I've put up two
PRs to fix it:

• Plugin (in-product setup wizard): docs(cloudways): warn against using network wildcard in WU_CLOUDWAYS_EXTRA_DOMAINS #1159 — updates
  views/wizards/host-integrations/cloudways-instructions.php
• Public docs site: Ultimate-Multisite/docs#45 — updates docs/user-guide/host-integrations/cloudways.md

Both PRs:

• Drop the misleading *.yourdomain.com / *.wildcard.com from the
  WU_CLOUDWAYS_EXTRA_DOMAINS example.
• Reframe WU_CLOUDWAYS_EXTRA_DOMAINS as for external domains only
  (separate marketing site, parked domain, etc.) — never the network's
  own subdomain wildcard.
• Add an Important — Wildcard SSL Pitfall section with the recommended
  Cloudways SSL setup (standard Let's Encrypt for the network domain
  only, DNS-only wildcard for tenant subdomains).
• Add a troubleshooting bullet for the exact symptom you hit: per-tenant
  custom domains stuck without SSL when a wildcard cert is active on the
  Cloudways application.

The plugin code itself is consistent with the new docs:
Cloudways_Domain_Mapping::get_valid_ssl_domains() strips the leading
*. before requesting SSL, and Cloudways_Integration::send_cloudways_request()
hard-codes 'wild_card' => false, so the integration never installs a
wildcard cert — only standard Let's Encrypt per-domain. That's documented
explicitly now under "SSL Certificate Management" / the new pitfall section.

Closing once #1159 merges.

---

aidevops.sh v3.14.92 plugin for OpenCode v1.14.40 with gemma4:e4b spent 15h 38m and 263,673 tokens on this with the user in an interactive session.

[superdav42]

Filed a separate code-side follow-up: #1160 — "exclude wildcards from Let's Encrypt SSL request, keep them in aliases".

Once that lands, the integration will tolerate wildcards in WU_CLOUDWAYS_EXTRA_DOMAINS safely (kept on the aliases list for routing, excluded from the per-domain Let's Encrypt request). The doc PRs (#1159, docs#45) still stand — best practice will remain "standard Let's Encrypt cert on the network domain" — but the code itself will stop turning a wildcard config into a stripped-apex SSL request.

---

aidevops.sh v3.14.93 plugin for OpenCode v1.14.41 with gemma4:e4b spent 16h and 263,673 tokens on this with the user in an interactive session.