XOOPS SSL & HTTPS on Shared Hosting: Let's Encrypt, Redirects, Proxy Awareness, and Mixed-Content Fixes

XOOPS stores its canonical site address in a single configuration constant, and that design decision is the source of most HTTPS problems you will encounter after installing a certificate. When the stored protocol, the browser request, and the web server's view of the connection fall out of sync, you get infinite redirect loops, half-broken pages where images and stylesheets refuse to load, and admin panels that log you out the moment you touch a secure form. None of these require server-level intervention to repair. Everything can be corrected from your hosting account using the control panel UI, File Manager, phpMyAdmin, and a short list of .htaccess directives.

Issuing and verifying the certificate on the Hostiso stack

Before touching any XOOPS file, confirm that a valid certificate actually covers the hostname your visitors use. On the Hostiso Managed Cloud platform, AutoSSL (cPanel) or Let's Encrypt (DirectAdmin) issues domain-validated certificates automatically, but the automation only succeeds when the domain resolves to the server and the HTTP validation path is reachable.

In cPanel Jupiter, open Security → SSL/TLS Status. You will see every domain, subdomain, and parked alias with a coverage indicator. If a hostname shows as unsecured, select it and click Run AutoSSL. Watch for domains flagged with a warning icon; the common failure is a www or subdomain record pointing elsewhere, or a stale .htaccess rule that redirects the /.well-known/acme-challenge/ path before validation completes. In DirectAdmin Evolution, the equivalent control lives under Account Manager → SSL Certificates, where you choose Free & automatic certificate from Let's Encrypt and tick both the root domain and the www entry so the certificate's Subject Alternative Names match every variant your users type.

If validation keeps failing, inspect the top of your public_html/.htaccess. A blanket HTTPS redirect placed above the ACME exclusion can block the challenge. Add this exception as the first rule so the validator always reaches the token files:

RewriteEngine On
RewriteRule ^\.well-known/acme-challenge/ - [L]

Once the SSL/TLS Status page reports green coverage for both the bare domain and www, load https://yourdomain.com/ directly in a private browser window. A clean padlock with no XOOPS theme styling is expected at this stage, because the application itself still believes it lives at an http:// address. That mismatch is what you fix next.

Aligning XOOPS_URL and the secure cookie environment

XOOPS reads its base address from XOOPS_URL, defined in mainfile.php at the document root. Every generated link, form action, redirect, and asset reference is built from this constant. If it still reads http:// while the browser arrives over https://, XOOPS keeps rewriting secure requests back to plaintext, and modern browsers either block the result or your server bounces it straight back to HTTPS, producing a redirect loop.

Open File Manager in your control panel, navigate to public_html (or the subdirectory holding the XOOPS installation), and edit mainfile.php. Make a copy first by right-clicking and choosing Copy so you have a rollback. Locate the line resembling:

define('XOOPS_URL', 'http://yourdomain.com');

Change the scheme to HTTPS and remove any trailing slash:

define('XOOPS_URL', 'https://yourdomain.com');

Save the file. If your theme or modules also reference a hard-coded XOOPS_PROTOCOL or a secondary URL constant, update those to match. Some older XOOPS setups additionally cache the site URL inside the config table. Open phpMyAdmin, select the XOOPS database, and run a read-only check first:

SELECT conf_name, conf_value FROM xoops_config
WHERE conf_value LIKE 'http://%';

Adjust the table prefix (xoops_) to whatever your installation uses. If rows appear with plaintext URLs, update them individually through the phpMyAdmin edit pencil rather than a mass query, so you can confirm each value belongs to a site-path setting and not unrelated content. After editing database or config values, clear the XOOPS cache by deleting the contents of cache/ and templates_c/ under your XOOPS root through File Manager, leaving the directories themselves and any index.html placeholders in place. XOOPS regenerates these on the next page load, and skipping this step is the most common reason a corrected URL appears to have no effect.

Redirects and proxy awareness on LiteSpeed

With XOOPS now self-aware over HTTPS, enforce the protocol at the web server layer so no visitor ever lands on the plaintext version. Edit public_html/.htaccess and place the canonical redirect immediately below the ACME exception from the first section:

RewriteEngine On
RewriteRule ^\.well-known/acme-challenge/ - [L]

RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

LiteSpeed reads .htaccess natively and honors these mod_rewrite directives without a restart, so the change takes effect on the next request. If your site should resolve on a single canonical hostname, append a second rule to collapse www into the bare domain (or the reverse, depending on your preference):

RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

Proxy awareness becomes relevant when a CDN or reverse proxy terminates TLS in front of the origin. In that topology the connection between proxy and server can arrive as plain HTTP, so %{HTTPS} reads off even though the visitor is secure, and the redirect rule above fires endlessly. Detect this by checking the forwarded header instead. Replace the protocol condition with a rule that respects the proxy signal:

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

For XOOPS to build secure links in this scenario, it must also trust the forwarded header. Add a short block near the top of mainfile.php, above the XOOPS_URL definition, so PHP populates the secure flag before the constant is read:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
    && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

If you prefer not to edit PHP, you can inject the same signal with a .user.ini file is not suitable here because this is a runtime variable, so the mainfile.php snippet remains the cleanest no-root approach. After any redirect change, test with curl -I https://yourdomain.com/ from your local machine, or simply confirm in a browser that the padlock holds and no loop occurs.

Resolving mixed-content warnings and verifying the result

A padlock with a warning triangle means the HTML is served over HTTPS but references at least one asset over HTTP. In XOOPS these stragglers usually hide in three places: theme template files under themes/yourtheme/, module-supplied content blocks, and body text that authors pasted with absolute http:// image links. Open your browser developer console, reload the page, and read the mixed-content entries; each one names the offending file and URL.

For theme files, edit theme.html and any CSS or template partials in File Manager and convert hard-coded http:// asset paths to protocol-relative or HTTPS references. Protocol-relative URLs such as //yourdomain.com/path/logo.png inherit whatever scheme the page used, which keeps the theme portable. For stored content inside the database, run a targeted search in phpMyAdmin against the relevant module table, for example xoops_bb_posts or your CMS content table, using a SELECT with LIKE 'http://yourdomain.com%' to size the problem before carefully updating rows. Keep a database export from phpMyAdmin → Export on hand before any write, since bulk content edits are the one operation with no quick undo.

As a backstop for assets you cannot easily rewrite, add an upgrade-insecure-requests header through .htaccess so compliant browsers automatically promote HTTP subresource requests to HTTPS:

<IfModule mod_headers.c>
  Header always set Content-Security-Policy "upgrade-insecure-requests"
</IfModule>
<IfModule LiteSpeed>
  Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

Introduce the HSTS header only after you are confident HTTPS works site-wide, because it instructs browsers to refuse plaintext for a year and is difficult to reverse quickly. When troubleshooting a page that still misbehaves, check the per-domain error_log that LiteSpeed writes into the XOOPS root or public_html; PHP notices about failed header modification or template parsing frequently point directly at the module or theme file responsible. Finish by clearing cache/ and templates_c/ one final time, then load the homepage, a module page, and the admin login over HTTPS in a fresh private window. A consistent padlock across all three, with no console warnings and no redirect loop, confirms the certificate, the XOOPS_URL constant, the redirect layer, and the proxy signal are finally in agreement.