My personal site on siteground is on https with the force setting on

Additional Info:

1. My edits above were to hide some security info.
2. In case someone visits the site, https://BackgroundSearch.com currently has the hosting service force https.

   ---

   _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/14861.}

@pintobuck you should remember that if someone (like me and others) were subscribed to this tracker then they will have received your original post by email so you should make sure you change your details

I've had this happen as well. I wasn't able to nail down exactly why it's happening, because as @brianteeman implies, it doesn't always happen. For example, clearing your cookies will fix it temporarily. Using CloudFlare with their free SSL seemed to be related, but I couldn't absolutely say that's the problem. In the end, I'm not using Joomla!'s forceful https setting, and instead have htaccess handling it:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^mysite.com [NC]
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://mysite.com/$1 [R,L]

If you are using cloud flare then that's definitely a problem area with things you have to change at cloud flare if you are using all. Or at least there was last time i looked

Perhaps a bit off topic @JamesShaver, but yes, there can be a problem with too many redirects if Cloudflare is setup incorrectly.
But in my experience it is possible to use a (free) Cloudflare account for getting https on your joomla site. I've set this up for dozens of domains.

1. You should let Cloudflare redirect http and https traffic to your server. You can do this in your domain's Crypto tab on Cloudflare. At the SSL settings choose "Full". The "Full" settings only work if you have a certificate installed for your hosting account. (This can be a self signed certificate or the default certificate for your hosting account.)

2. In the DNS settings of Cloudflare you can point the an A record for the domain name as well as the www A record to your server's ip address. Make sure and set the status (the cloud symbol with the arrow through it located in the right column) to make use of Cloudflare.

3. Now that all www, non-www, http and https traffic is going through Cloudflare to your hosting account, make sure that you configure your hosting provider so that http and https are pointed to the same folder.

4. On your server redirect all non-www traffic to the www. domain. If you're using Apache you can use .htaccess for redirection of all non-www to www:

Redirect non-www to www -- BEGIN

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

Redirect non-www to www -- END

5. After that you can redirect all http traffic to https in Joomla's configuration: Global Configuration > Server > Force https > Entire site. This could give errors if you haven't set Cloudflare's SSL settings to "Full".

In my experiments with Joomla Force HTTPS, I had some indications that the primary cause of the to-many-redirects problem stemmed from the base tag that appeared on every page using http:

Additional info: My original installation of Joomla was performed via my web site hosting service's auto install tool.

Newbie mistake. My code disappeared. I'll try again using the Markdown Help.

In my experiments with Joomla Force HTTPS, I had some indications that the primary cause of the to-many-redirects problem stemmed from the base tag that appeared on every page using http:
<base href="http://YourDomainName.com/" />

I could make the too-many-redirects problem go away by using an htaccess modification to force the base tag to use https:
<base href="https://YourDomainName.com/" />

But, my htaccess modification caused other problems (as described in the Joomla.org forum thread that I cited above), so I gave up on Joomla Force HTTPS and used my web site hosting service to force HTTPS.

I notice that Joomla.org uses the base tag with https:
<base href="https://joomla.org/" />

Additional info: My original installation of Joomla was performed via my web site hosting service's auto install tool.

Force setting works just fine.

But if your server doesn't support full SSL and you are using cloudflare flexi SSL i.e. upstream SSL then it won't work well at all. Since you are trying to force your server todo something it cannot.

But if you have also set the livesite variable in the Joomla! global config this needs removing / updating.

You also need to update any http:// links on your site to HTTPS otherwise yes you will get redirect errors.

You can use this plugin:
https://extensions.joomla.org/extension/cloudflare-for-joomla/

to allow the user of Cloudflare FlexiSSL since it tests against the remote cloudflare header IIRC.

Many thanks
Tony

No disagreement, just more info, without addressing the Cloudshare issue.

1. BackgroundSearch.com uses a dedicated SSL certificate, setup by the web hosting service. It works well when they force HTTPS.

2. When I was experimenting with Joomla Force HTTPS, I found for me:
   2a) I changed all my URLs to relative URLS, but that did not help.
   2b) I changed configuration.php

$live_site = 'http://backgroundsearch.com';
To
$live_site = 'https://backgroundsearch.com';

which helped connect to my Gantry 5 custom CSS and swMenuPro CSS, because that was not happening without the https change.
2c) A key factor seemed to be the base tag <base href="http://YourDomainName.com/" /> using http, which appeared on every page (View Page Source). When I forced that base tag to use https, then the too-many-redirects problem went away.

3. Several people appear to have similar problems judging from the number of hits on the forum thread Installing SSL https on Joomla 3.6.5, Problems, and Solutions. Some other forum threads ask about the too-many-redirects problem.

I hope this info helps.

The problem is cloudflare isn't true ssl. It's just protection between your computer and cloudflare. Then there's no protection between cloudflare and your server this is where it all falls down in simple terms.

On 24 Mar 2017, 18:44 +0000, pintobuck notifications@github.com, wrote:

No disagreement, just more info, without addressing the Cloudshare issue.

BackgroundSearch.com uses a dedicated SSL certificate, setup by the web hosting service. It works well when they force HTTPS.

When I was experimenting with Joomla Force HTTPS, I found for me:
2a) I changed all my URLs to relative URLS, but that did not help.
2b) I changed configuration.php

$live_site = 'http://backgroundsearch.com'; To $live_site = 'https://backgroundsearch.com';

which helped connect to my Gantry 5 custom CSS and swMenuPro CSS, because that was not happening without the https change.
2c) A key factor seemed to be the base tag using http, which appeared on every page (View Page Source). When I forced that base tag to use https, then the too-many-redirects problem went away.

Several people appear to have similar problems judging from the number of hits on the forum thread Installing SSL https on Joomla 3.6.5, Problems, and Solutions (https://forum.joomla.org/viewtopic.php?f=706&t=947508). Some other forum threads ask about the too-many-redirects problem.

I hope this info helps.

This comment was created with the J!Tracker Application (https://github.com/joomla/jissues) at issues.joomla.org/tracker/joomla-cms/14861 (https://issues.joomla.org/tracker/joomla-cms/14861).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (#14861 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/ABVglt8cEcdOqL6VI3vWlw9PYKsiqzm2ks5rpA72gaJpZM4MlfUz).

1. For clarity: BackgroundSearch.com uses a dedicated SSL certificate.

2. Re TonyPartridge stated "You also need to update any http:// links on your site to HTTPS otherwise yes you will get redirect errors."
   For info, Steve_Moate reported similar success with that method:
   "I have used phpMyAdmin to track down the instances of %http://mydomainname% and successfully changed them to https:// either through phpMyAdmin or the normal site editor depending how complex the HTML looks."

   ---

   _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/14861.}

I had a problem with joomla 3.7.0 and php 7.0 which I seem to have fixed by editing my version of SwMenuPro.
There were lots of Deprecated-Warnings concerning the SwMenuPro Files. At some stage the menu wouldn't show.

So here is what I did:
How to make SwMenuPro PHP 7.0 compatible

Do everything at your own risk!
So first copy all the files you want to change.
I did it this way:

• Start filezilla, download the file to edit in notepad++.
• In filezilla, rename the file on the server (add 'old')
• Change something in notepad++ and save.
• Upload the changed file with filezilla, so it will have the old name.
  Now you can work on that file while everybody in the world will see what you're doing :-)

To test your changes don't forget to

• clear joomla cache
• clear firefox cache

Now let's go:
Errors/Warnings reported are:

1. PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP;
   ... has a deprecated constructor in /path/to/file.php on line ...
   There is a very good article with a true fix of that problem on https://cweiske.de/tagebuch/php4-constructors-php7.htm
   This problem concerns only the classes chain and swBrowser in /modules/mod_swmenupro/functions.php (line 1791 and 3550 or so)
   and as well the class chain2 in administrator\components\com_swmenupro\swmenupro.php (line 1869)
   Follow the instructions in the article above (read carefully, scroll down!)

2. Strict Standards: Only variables should be assigned by reference in /home/.../swmenupro.php on line ...
   Here joomla variables are directly accessed. I removed the &. So now a copy of the joomla variable is made. On my site it seems to work.

3. Non-static functions may not be called as static.
   This concernes obviously only the class HTML_swmenupro in \administrator\components\com_swmenupro\admin.swmenupro.html.php
   Since even inside the class the functions are never called by "$this->" we can define all functions as "public static".
   So replace "function" by "public static function" in this file ( but NOT the javascript functions of course!! ).
   Indentation in this file is not very consequent, so you might be not sure. You may search in the complete installation for "HTML_swmenupro::"
   and you will get all function names.

4. There remains a last
   Warning: Creating default object from empty value in /home/www/musikgymnasium-berlin.de/administrator/components/com_swmenupro/swmenupro.php on line 512
   which I couldn't fix, but everything works well on my site.

All in all I get the impression that SwMenuPro is not very well done. I tried to login on the SwMenuPro Forum but I couldn't register
because I couldn't see the captcha! The window can't be enlarged, so it was impossible.

As I said in the beginning, everybody can try this at own risk. Hope I could help somebody with the same problems.

GK

Joomla Force HTTPS caused too many redirects

From my experience, in 99% cases it is incorrect server configuration .
Properly configured server does not require "Joomla Force HTTPS" to be enabled, at all.

Could some Joomla extensions be the cause of problems when Joomla Force HTTPS is enabled?
For example,

1. Garadok cited his problems with swMenuPro and Joomla Force HTTPS, above on 4/27/2017.

2. Several people in Joomla.org forum have reported the need to manually change all http URLs to https before they could get Joomla Force HTTPS to work. For example Steve_Moate, CircuitoX, and others.

3. Pursuant to example No. 2, above, I noticed that swMenuPro inserts canonical http URLs into my Gantry 5 template. (Full disclosure: swMenuPro cannot be my only problem. As a test, I unpublished swMenuPro, but Joomla Force HTTPS would still cause too many redirects and browsers would not display my site.)

Suggestion: Joomla could ask extension creators to certify that their extensions are compatible with Joomla Force HTTPS. Joomla Extensions Directory could have an SSL ready symbol for each extension like JED does for Joomla 3 compatibility.

More Info: Mike McMullen wrote about his Joomla SSL problems in a Gantry group.

I looked around some more, and decided that the Base Href was DEFINITELY the issue. So I found head.php in the Joomla Libraries, and commented it out.
Instantly, the pages all work.
I have no idea why that was not working right (generating an HTTPS base href), but... this seems to work. Taking care of a stray module issue, then SSL looks like it will be up and running.
So I guess it Wasn't Gantry after all! Just Joomla.

That seems to support 3 issues:

1. Joomla's http base tag <base href="http://YourDomainName.com/" /> can be a problem.
2. Need to change all http URLs to https URLs.
3. Sometimes Joomla extensions could cause the problem.

Joomla's http base tag can be a problem.

On my own site with force https set to on the base tag generated is https://

The issue as far as I can see and have replicated before, is when different headers are used in the request like: X-Forwarded-Proto: https

If Joomla! is forced HTTPS when these types of headers are used it isn't happy since the server side doesn't have SSL installed in most cases or the cert fails validity.

This plugin tends to solve the problem:
https://extensions.joomla.org/extension/cloudflare-for-joomla/

Some related info from Joomla Forum. https://forum.joomla.org/viewtopic.php?f=706&t=949468

Per Leolan:
"You do not change the base-tag since that tag is automatically changed if you force SSL on the entire Joomla site."

Per CircuitoX:
"1) Causing too many redirects after my site went SSL and enabled Joomla Force HTTPS.
If you enabled https via cms (the redirection can be via php or mysql).
If you have control panel web hosting like cpanel and that have plugin for https, or if you have plugins for ssl in your joomla or something like sh404SEF this can be relation to url redirection via .htaccess.
This cause conflict with between cms redirection (force ssl) and server side .htaccess."

Update: Successful SSL, Joomla 3.8.1, Gantry 5.4.18, and Gantry Hydrogen template, on Shared Hosting by a large, international-sized hosting company.

The dedicated SSL certificate was purchased from the shared hosting service, installed by them, and assigned to a dedicated IP number.

Problem #1 - Joomla Force HTTPS caused browsers (Chrome, Firefox, I.E.11) to give error messages about too many redirects, and browsers would not display my web pages.
Solution to Problem #1 - Joomla 3.8.1 still causes too many redirects and browsers will not display my web pages. However, with the latest updates, now I can turn off Joomla Force HTTPS, let my web site hosting service C-Panel force HTTP > HTTPS, and browsers will display my web pages properly.

Problem #2 - My Gantry 5 Hydrogen Template problem back then was that SSL broke Hydrogen Template's connection to the custom.scss page, and so the template fell apart on the front end.
Solution to Problem #2 - Now with the latest updates, Joomla 3.8.1, Gantry 5.4.18, Hydrogen Template, and SSL are working together well after I added a line to .htaccess:
### Upgrade internal requests to https, insert if your site layout breaks when visiting the site via https
Header set Content-Security-Policy "upgrade-insecure-requests"

Additional Info:
(1) Currently, I'm using Joomla 3.8.1, PHP 7.0.98, Hosting Service's Apache server, Database 5.5.35-Maria, Database Collation utf8mb4_general_ci, Gantry 5.4.18, Hydrogen Template 5.4.18.
(2) For my current installation, Joomla 3.6.2 was installed using the hosting service auto install tool. Joomla was upgraded using Joomla's auto upgrade since then
(3) A year ago, I tried the SSL solution discussed above, but it did not work. However, it is working now. Perhaps the interim upgrades to all components helped.

"Upgrade internal requests to https, insert if your site layout breaks when visiting the site via https"
is supposed to be an .htaccess comment line with the pound sign in front of it, instead of the H1 header in the comment above.

In my case this same issue or one similar was caused by a conflict with an SSL redirect plugin by Yireo. It's a great plug-in; I had recycled a website to be used for another client and forgot that the plugin was active. I deactivated the plug-in and now my redirect in .htaccess is working.

This appears to be a server configuration issue than core issue.

Set to "closed" on behalf of @alikon by The JTracker Application at issues.joomla.org/joomla-cms/14861

let's close this for now, it can be reopened if required