Why ATutor Behaves Oddly Under HTTPS

ATutor was designed in an era when plain HTTP was the default, and its assumptions still shape how it handles URLs today. During installation, the application writes an absolute base address into two places: the include/config.inc.php file (the AT_include_path and related constants derived from your domain) and several rows inside the _config and content tables in the database. When you later add an SSL certificate and start visiting the site over https://, ATutor keeps generating links, form actions, and asset references using the address it recorded at install time. If that address was http://yourdomain.com, every page you load over HTTPS will pull stylesheets, JavaScript, and course content over insecure HTTP, and the browser flags the page as "not fully secure."

The second complication is proxy awareness. On the Hostiso stack, LiteSpeed Web Server terminates the TLS connection and then hands the request to PHP. In many shared configurations PHP sees the request through variables like HTTP_X_FORWARDED_PROTO rather than a directly populated HTTPS server variable. ATutor's older bootstrap code checks $_SERVER['HTTPS'] in a few spots to decide whether to emit secure cookies and canonical links. When that variable is empty because TLS was terminated upstream, ATutor can enter a redirect loop, log users out immediately after login, or refuse to set the session cookie with the Secure flag. None of this indicates a broken certificate; it reflects the gap between how the certificate is served and how the application detects it.

The practical consequence is that installing a certificate is only the first of several steps. You also need to force browsers onto HTTPS, teach ATutor that requests are secure even when PHP cannot see the raw TLS handshake, and correct the stored base URL so internal links stop pointing at the old scheme. Each of these lives entirely inside your hosting account, so you never need root, SSH administration, or changes to server-wide configuration files.

Issuing the Certificate and Confirming Coverage

Most Hostiso accounts already have AutoSSL (cPanel) or Let's Encrypt automation (DirectAdmin) issuing certificates the moment a domain resolves to the server. Before touching any ATutor files, confirm the certificate actually covers the exact hostname learners use. A certificate issued for yourdomain.com does not automatically secure www.yourdomain.com, and a mismatch there produces the same warning symptoms people often blame on ATutor.

In cPanel Jupiter, open Security → SSL/TLS Status. You will see every domain and subdomain with a coverage indicator. If ATutor lives on a subdomain such as lms.yourdomain.com, verify that specific entry shows a valid, unexpired certificate. If it is missing, select the domain and click Run AutoSSL. Give it a few minutes and refresh; DNS propagation or a stray redirect can delay issuance, and the status page reports the reason if validation fails.

In DirectAdmin Evolution, go to Account Manager → SSL Certificates, choose the domain from the selector at the top, and pick Free & automatic certificate from Let's Encrypt. Tick both the root domain and the www entry so the SAN certificate covers both, then save. DirectAdmin will also offer to enable the option that forces the certificate to be used for the domain; leave that enabled.

Once issued, load your ATutor URL directly with https:// typed in the address bar. The connection padlock confirms the certificate is valid even if the page content still shows mixed-content warnings. Separating "is the certificate valid" from "does the page load securely" saves a great deal of guesswork, because the fixes for each are different and applied in different places.

Forcing HTTPS and Handling Proxy Termination

With a valid certificate in place, the next task is guaranteeing every request lands on HTTPS. ATutor ships an .htaccess file in its document root (for example /home/username/public_html/ or the subdomain's root such as /home/username/lms.yourdomain.com/). Open it in the cPanel or DirectAdmin File Manager, enabling "Show Hidden Files" first, and add the redirect block near the top, above ATutor's existing rewrite rules:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteCond %{HTTP_HOST} ^(www\.)?yourdomain\.com$ [NC]
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

The dual condition matters on LiteSpeed. When TLS is terminated upstream, %{HTTPS} may not read as on even though the visitor is on a secure connection, so relying on it alone can create an infinite loop. Adding the X-Forwarded-Proto check makes the rule redirect only genuine plain-HTTP requests and leave already-secure requests alone.

ATutor itself still needs to believe the request is secure so it emits HTTPS links and secure cookies. Because you cannot edit server-wide PHP settings, use a .user.ini file or a small guard at the top of include/config.inc.php. The cleanest approach that survives ATutor's own logic is to normalize the server variable before the application reads it. Add this to the very top of include/config.inc.php, immediately after the opening PHP tag:

if (
    (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') ||
    (!empty($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on')
) {
    $_SERVER['HTTPS'] = 'on';
    $_SERVER['SERVER_PORT'] = 443;
}

This tells ATutor the connection is encrypted whenever LiteSpeed forwarded a secure request, which stops the login-then-logout loop caused by the secure session cookie being dropped. Save the file and clear your browser cookies for the domain before testing, since a stale insecure session cookie can mask whether the fix worked.

Correcting the Stored Base URL and Clearing Mixed Content

Even with redirects working, ATutor will keep serving http:// asset links if its stored base address still uses the old scheme. Open phpMyAdmin from cPanel or DirectAdmin, select the ATutor database (its name is listed in include/config.inc.php as DB_NAME), and inspect the configuration table, typically named AT_config with the prefix your install used. Look for the row where name is site_url or the equivalent base-path value. Run a targeted update rather than editing rows by hand so you do not miss occurrences:

UPDATE AT_config
SET value = REPLACE(value, 'http://yourdomain.com', 'https://yourdomain.com')
WHERE value LIKE 'http://yourdomain.com%';

Course content authored in the HTML editor is the other common source of insecure references. Instructors frequently embed images or iframes with absolute http:// URLs, and those live in the content tables such as AT_content and AT_glossary. Update them the same way, adjusting the table and column names to match your prefix:

UPDATE AT_content
SET text = REPLACE(text, 'http://yourdomain.com', 'https://yourdomain.com')
WHERE text LIKE '%http://yourdomain.com%';

Always export the database first using phpMyAdmin's Export tab so you have a rollback point. To find any remaining offenders after the updates, load a course page in your browser, open the developer console, and read the mixed-content warnings; each one names the exact insecure resource so you can trace it to the table where it was stored. For third-party embeds hosted elsewhere that only offer HTTP, the correct action is to replace them with an HTTPS source rather than downgrade your own site.

Finally, confirm ATutor's admin-side setting matches. Log in to the ATutor administrator panel, open System Preferences, and verify the site URL field reflects the HTTPS address. If your account uses LiteSpeed Cache, purge it from the cPanel or DirectAdmin cache tool after these edits so visitors receive freshly generated pages rather than a cached copy still referencing the old scheme. Once the base URL, the proxy guard, and the redirect rules agree with one another, the padlock stays closed across the dashboard, course pages, and login flow.