Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By Rounder on
I have a site working fine, but it is defaulting to HTTP. When I add the .htaccess file with the necessary:
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://websitename.com/$1 [R,L]only the home page works. Every other link says:
The requested URL /xxxxxxx was not found on this server.When I remove the .htaccess file and try to refresh, nothing works at all - not even the Admin login that was open in another tab/window.
After restoring the code and database from backup and verifying that everything works OK, I tried installing the Protocol Relative URLs module and clearing the cache. Exact same results when doing all of the above. There is absolutely no documentation for this module, but I get the impression that it only works if installed before creating any content - it doesn't correct an existing website.
So how does a person make an existing Drupal 8 website work with HTTPS?
Comments
It should just work. Can you
It should just work. Can you paste in your apache config for the secure site.
BlueFusion.co.nz
~
Your .htaccess looks a little different than the official recommended solution for Enabling HTTP Secure (HTTPS) ... If that doesn't work, you could also try my attempt at Forcing HTTPS and www/no-www in settings.php.
I see that to force https on
I see that to force https on my Drupal site I need to add this to .htaccess:
I notice the default .htaccess already has this below. Do I need to comment this out after adding the above code?
Those lines can be removed. Obviously, you can't ...
use protossl in later RewriteRule statements. These lines are meant for situations where https are optional. It uses protossl to store a blank or 's' depending on which protocol was used. It was meant to prevent switching. Since you are forcing to https those lines are redundant. This assumes forcing is one of the first things you do.
My bad
Turns out it was my own fault. I was talking to my hosting company last night and we were playing around in the public_html folders where the .htaccess file that is the default installation is basically a few commented lines. So I got in the habit of replacing that with the modified version they gave me.
Not paying attention, I just assumed that all .htaccess files on my account were the same way. So I over wrote the one in the Drupal site I was working on - wiping out the important 190 lines of code that Drupal had placed there!
After I reloaded the backup I paid more attention to what was in there. No wonder things did not work when I wiped them out! The rep suggested I put the RewriteCond and RewriteRule statements at what is line 78 in my file - after these statements:
Everything works like a charm now.
The links ressa gave are good to know, and I bookmarked that page for future reference should the need arise. Thanks!
To paraphrase the movie: "What you initially asked is one of the most insanely idiotic things I have ever read. Everyone in this forum is now dumber for having read it. I award you no points." (g)
Great that you got it working
And thanks for sharing your solution. Just remember that next time you update Drupal, the .htaccess file will be replaced with a fresh version, without your modifications.
What do mean by "update"?
What do mean by "update"? You mean, any updates to Core or any modules via Composer?
If that is true, is there any way around it? It seems very dangerous for Drupal to just make that blanket assumption that nothing customer-specific was there and just write over it.
Seems like there should be a feature/option added within Drupal Core that could be enabled to select that HTTPS should always be used.
~
I mean Drupal core updates, module updates shouldn't touch the Drupal core .htaccess file. A Drupal core update will replace many files, like robots.txt .htaccess, etc., see Update procedure in Drupal 8 for more.
(sigh) I guess I come from a different environment
In the enterprise world where I come from, there is no way we would be allowed to write over any such file that might have been customer-modified. If it was absolutely necessary to replace existing file(s), our programs would automatically rename (usually something timestamp-related so it would definitely be unique) and save the old version so the customer could refer to it to make matching updates to the new version.
I'll get on my soapbox now ... earlier this year when I was trying to decide on learning WordPress vs Joomla vs Drupal, I chose Drupal because it was promoted as being an Enterprise-level CMS. But I'm not seeing a lot of Enterprise-level disciple when it comes to programming practices and documentation.
(climbing back down now)
Assuming You Use Composer
In my hosting environment, I lock down Composer in an effort to prevent things like this. Using Git or manually updating core is usually the way I go -- hence avoiding these issues.
Reliance upon Composer is fairly new and I think the implementation and requirement for it solves problems for developers but does nothing for end users. I suspect this implementation will improve but not in the near future and most likely not until Drupal 9 is released.
Until then, I will manually update core because I can tell the software what to do and not the other way around.
---
Shane Birley
Left Right Minds
https://www.leftrightminds.com