Why Zikula Needs Explicit HTTPS Handling

Zikula is a Symfony-based content management framework, and like most Symfony applications it builds absolute URLs from a combination of the incoming request scheme, the host header, and values cached in its own configuration. When a site is served behind LiteSpeed on a managed shared server, the request that reaches PHP has already passed through the web server's TLS termination layer. That means the environment variables Zikula reads to decide whether a visitor arrived over http or https are populated by the server, not by the browser directly. If those signals are misread, Zikula will happily serve a page over a secure connection while emitting asset links, form actions, and canonical tags that still point at http://. The padlock disappears, browsers block the insecure sub-resources, and the layout collapses because CSS and JavaScript were silently dropped.

The second common failure mode is a redirect loop. Administrators frequently add a rule in .htaccess to force HTTPS, then discover the site cycles endlessly between the secure and insecure versions. This happens when the redirect logic and Zikula's own routing disagree about the current scheme, or when a rule checks a variable that the proxy layer rewrites on every hop. Because you are working as an unprivileged hosting user, none of this is fixed by touching server configuration or restarting services. Everything is solved inside the account: the SSL/TLS installer in the control panel, the document root .htaccess, Zikula's stored site parameters, and a careful reading of the local error_log. The rest of this guide treats each layer in the order a request actually travels through it.

Installing and Verifying the Certificate

Before any redirect or configuration change, confirm that a valid certificate covers every hostname your Zikula install answers on. On cPanel Jupiter, open Security → SSL/TLS Status. Hostiso provisions AutoSSL, so the domain and its www alias should already show a green lock with a Let's Encrypt or Sectigo certificate. If a hostname shows as unsecured, use the Run AutoSSL button and wait for the queue to complete. On DirectAdmin Evolution the equivalent path is Account Manager → SSL Certificates, where you select Free & automatic certificate from Let's Encrypt and tick both the root domain and the www entry so the SAN list matches every name Zikula might generate.

A frequent oversight is issuing a certificate for example.com and www.example.com but running Zikula from a subdomain such as cms.example.com or an addon domain. The certificate must list the exact host that appears in the browser address bar. If it does not, the connection is technically encrypted but the browser rejects the name mismatch, and no amount of application configuration will suppress that warning. After issuance, verify the chain from the outside rather than trusting the panel alone. A quick check of the live endpoint over HTTPS in a private browser window confirms the leaf certificate, the intermediate chain, and the expiry date are all correct before you commit to forcing traffic onto it.

Only once the certificate is confirmed valid for the canonical hostname should you introduce redirects. Forcing HTTPS while the certificate is incomplete produces the worst outcome: visitors are pushed to a scheme the browser refuses to trust, and the site becomes unreachable rather than merely insecure.

Forcing HTTPS and Avoiding Redirect Loops

Zikula ships with a .htaccess in the document root (typically /home/USER/public_html/.htaccess, or the addon domain's root such as /home/USER/cms.example.com/). The rewrite block that boots the front controller lives here, and your HTTPS enforcement must sit above the existing Zikula rules so it runs first. On the LiteSpeed stack the reliable scheme test is %{HTTPS}, which LiteSpeed populates correctly after TLS termination. Use this near the top of the file, inside the existing <IfModule mod_rewrite.c> block, immediately after RewriteEngine On:

RewriteEngine On

# Force HTTPS on the canonical host
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

If you also want to canonicalize on the non-www or www hostname, combine it into a single hop so you never chain two 301s (which slows the first request and can confuse caches):

RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

Redirect loops usually appear when a rule tests %{SERVER_PORT} or a copied X-Forwarded-Proto condition that does not match the LiteSpeed environment. Avoid rules like RewriteCond %{SERVER_PORT} 80 on this stack; the port seen by PHP is not a dependable proxy signal here. Stick to %{HTTPS}. If a loop persists after you switch to it, clear the browser cache and test in a fresh private window, because a previously cached 301 from an old rule will keep firing even after the file is corrected.

Keep any Zikula-generated block, usually delimited by comments referencing the front controller, untouched below your redirect. Editing .htaccess through File Manager in cPanel or DirectAdmin is safest: enable Show Hidden Files (dotfiles) in the File Manager settings, make a copy first, then edit inline. If a saved rule breaks the site with a 500 error, the fix is to restore your copy; check the per-account error_log in the same directory to confirm whether the failure came from a rewrite syntax error or from PHP.

Proxy Awareness and Clearing Mixed Content

With the certificate valid and traffic forced onto HTTPS, the final layer is making Zikula itself agree that the site is secure so it stops printing http:// URLs. Zikula stores its canonical address in the Settings module and in the framework parameters written during installation. Log into the AdminCP and open Administration → Settings → Main settings. Update the site URL fields so they use the https:// scheme and the exact canonical host. Save, then flush the cache from Administration → Cache clearing (or the Clear cache control on the settings screen), because Symfony compiles URL generation and container parameters into var/cache and will keep serving stale insecure links until that directory is regenerated.

If asset links still render as http:// after the settings change, the parameters file needs alignment. In the Zikula installation, the trusted proxy and scheme handling are governed by the framework configuration under config/ (for example the parameters written at install time). Because LiteSpeed terminates TLS in front of PHP, ensure the request scheme is trusted by editing the parameters through File Manager so the application treats the forwarded HTTPS request as secure. When Zikula reads a proper on value from %{HTTPS} and the stored site URL is HTTPS, the router emits secure absolute URLs and the mixed-content warnings tied to CSS, JavaScript, and internal images resolve on their own.

Content authored inside the CMS is the last hiding place for insecure references. Editors that pasted full http:// image or embed URLs into articles and blocks will keep triggering the browser's mixed-content shield even after every configuration layer is correct. Use phpMyAdmin (from cPanel Databases or DirectAdmin MySQL Management) to locate the hardcoded strings, and take a full export first from the Export tab. A targeted update against the content column, scoped tightly with a WHERE clause, replaces http://example.com with https://example.com; run it only after backing up, and clear the Zikula cache again afterward. Set the .user.ini in the document root if you need a longer max_execution_time while running a large content sweep, since that per-directory PHP override is honored on the CloudLinux and LiteSpeed stack without any server-level change. When browser DevTools shows zero blocked requests in the Console and Network tabs, HTTPS is fully consistent end to end.