Plugin pages redirect to port 80 on https connection #628

New Issue

2026-10-05T00:08:03+02:00

adam commented

2026-10-05 00:08:03 +02:00

I just setup a brand new Piwigo v2.9.0 on my web hosting. The site is configured with a Let's Encrypt SSL certificate, and everything works fine.

Then I installed the Protected Albums, and got an error from the browser when opening a protected album, as shown in the 2 screenshots below

For some reason, Piwigo (I don't think it's the plugin itself, because the same behavior can be observed with other plugins as well) added port 80 to the https URL. Note that if I manually edit the URL to remove the port, then I can continue without further issues:

I just setup a brand new Piwigo v2.9.0 on my web hosting. The site is configured with a _Let's Encrypt_ SSL certificate, and everything works fine. Then I installed the _Protected Albums_, and got an error from the browser when opening a protected album, as shown in the 2 screenshots below ![selection_001](https://cloud.githubusercontent.com/assets/449891/26027097/bb4f591e-3807-11e7-9f0f-f0d824ef1849.png) ![selection_002](https://cloud.githubusercontent.com/assets/449891/26027098/bd6945e8-3807-11e7-9c55-4d11e6ee6775.png) For some reason, Piwigo (I don't think it's the plugin itself, because the same behavior can be observed with other plugins as well) added port 80 to the https URL. Note that if I manually edit the URL to remove the port, then I can continue without further issues: ![selection_003](https://cloud.githubusercontent.com/assets/449891/26027156/0a7fc464-3809-11e7-8e82-5e45697d36fc.png)

adam closed this issue

2026-10-05 00:08:03 +02:00

adam commented

2026-10-05 00:08:04 +02:00

Looks like the problem is in get_absolute_root_url() function

Looks like the problem is in *get_absolute_root_url()* function

adam commented

2026-10-05 00:08:05 +02:00

Weird.

$_SERVER['SERVER_PORT'] is set to 80, even if my URL is https://example.com:443/photos/index.php?/password/1. In fact, it is 80, whatever the port number is.

So maybe it's not an issue with Piwigo itself, but with PHP or the web server ?

EDIT: after further research, this is most likely an Apache issue - http://stackoverflow.com/questions/4433229/incorrect-port-number-returned-by-serverserver-port. I'll talk to my hosting provider; until then I'll patch the source code as a workaround.

Weird. `$_SERVER['SERVER_PORT']` is set to **80**, even if my URL is https://example.com:443/photos/index.php?/password/1. In fact, it is 80, whatever the port number is. So maybe it's not an issue with Piwigo itself, but with PHP or the web server ? EDIT: after further research, this is most likely an Apache issue - http://stackoverflow.com/questions/4433229/incorrect-port-number-returned-by-serverserver-port. I'll talk to my hosting provider; until then I'll patch the source code as a workaround.

adam commented

2026-10-05 00:08:06 +02:00

For the record, here is how I fixed the problem.

Temporary workaround

Do not append the port number to the URL.
Note: this is only applicable when using default port numbers for http/https.

diff --git a/include/functions_url.inc.php b/include/functions_url.inc.php
index ea329b4..c144ee1 100644
--- a/include/functions_url.inc.php
+++ b/include/functions_url.inc.php
@@ -69,15 +69,6 @@ function get_absolute_root_url($with_scheme=true)
     else
     {
       $url .= $_SERVER['HTTP_HOST'];
-      if ( (!$is_https && $_SERVER['SERVER_PORT'] != 80)
-            ||($is_https && $_SERVER['SERVER_PORT'] != 443))
-      {
-        $url_port = ':'.$_SERVER['SERVER_PORT'];
-        if (strrchr($url, ':') != $url_port)
-        {
-          $url .= $url_port;
-        }
-      }
     }
   }
   $url .= cookie_path();

Hosting provider (permanent) solution

The provider's shared hosting architecture relies on HAProxy. They can't change UseCanonicalName = On and UseCanonicalPhysicalPort = On (per the StackOverflow article referenced earlier).

They finally came up with the following solution: use an auto_prepend file with the following contents:

<?php
# Fix PHP SERVER_PORT detection on https
# Based on recommendation from Infomaniak support ref #INK-ESL-34959-993

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

For the record, here is how I fixed the problem. ## Temporary workaround Do not append the port number to the URL. *Note: this is only applicable when using default port numbers for http/https.* ``` patch diff --git a/include/functions_url.inc.php b/include/functions_url.inc.php index ea329b4..c144ee1 100644 --- a/include/functions_url.inc.php +++ b/include/functions_url.inc.php @@ -69,15 +69,6 @@ function get_absolute_root_url($with_scheme=true) else { $url .= $_SERVER['HTTP_HOST']; - if ( (!$is_https && $_SERVER['SERVER_PORT'] != 80) - ||($is_https && $_SERVER['SERVER_PORT'] != 443)) - { - $url_port = ':'.$_SERVER['SERVER_PORT']; - if (strrchr($url, ':') != $url_port) - { - $url .= $url_port; - } - } } } $url .= cookie_path(); ``` ## Hosting provider (permanent) solution The provider's shared hosting architecture relies on [HAProxy](http://www.haproxy.org/). They can't change `UseCanonicalName = On` and `UseCanonicalPhysicalPort = On` (per the StackOverflow article [referenced earlier](https://github.com/Piwigo/Piwigo/issues/681#issuecomment-301261353)). They finally came up with the following solution: use an [auto_prepend file](http://php.net/manual/en/ini.core.php#ini.auto-prepend-file) with the following contents: ``` php <?php # Fix PHP SERVER_PORT detection on https # Based on recommendation from Infomaniak support ref #INK-ESL-34959-993 if(isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO']=='https') { $_SERVER['SERVER_PORT'] = 443; } ```

adam commented

2026-10-05 00:08:06 +02:00

Thank you for this clean fix.

@modus75 do you think we should implement it in Piwigo core?

Thank you for this clean fix. @modus75 do you think we should implement it in Piwigo core?

adam commented

2026-10-05 00:08:07 +02:00

I don't think we should because I'm not sure it's standard in anyway (no
official doc anywhere) and most importantly can it be forged (eg send an
X-Forwarded-Proto header) ?
It's probably ok to put it if you know you're behind a proxy /load balancer
etc... I'm not sure for the general case.

On May 23, 2017 13:05, "Pierrick Le Gall" notifications@github.com wrote:

Thank you for this clean fix.

@modus75 https://github.com/modus75 do you think we should implement it
in Piwigo core?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Piwigo/Piwigo/issues/681#issuecomment-303365039, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJRc9qa9dZLoop-EK_lCmtfR9WncNpXMks5r8r1kgaJpZM4NaHjD
.

I don't think we should because I'm not sure it's standard in anyway (no official doc anywhere) and most importantly can it be forged (eg send an X-Forwarded-Proto header) ? It's probably ok to put it if you know you're behind a proxy /load balancer etc... I'm not sure for the general case. On May 23, 2017 13:05, "Pierrick Le Gall" <notifications@github.com> wrote: > Thank you for this clean fix. > > @modus75 <https://github.com/modus75> do you think we should implement it > in Piwigo core? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/Piwigo/Piwigo/issues/681#issuecomment-303365039>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AJRc9qa9dZLoop-EK_lCmtfR9WncNpXMks5r8r1kgaJpZM4NaHjD> > . >

adam commented

2026-10-05 00:08:08 +02:00

ok fine, let's keep it as a tip in Github :-)

ok fine, let's keep it as a tip in Github :-)

adam commented

2026-10-05 00:08:08 +02:00

Let's look what WordPress does...

On May 23, 2017 13:05, "Pierrick Le Gall" notifications@github.com wrote:

Thank you for this clean fix.

@modus75 https://github.com/modus75 do you think we should implement it
in Piwigo core?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Piwigo/Piwigo/issues/681#issuecomment-303365039, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJRc9qa9dZLoop-EK_lCmtfR9WncNpXMks5r8r1kgaJpZM4NaHjD
.

Let's look what WordPress does... On May 23, 2017 13:05, "Pierrick Le Gall" <notifications@github.com> wrote: > Thank you for this clean fix. > > @modus75 <https://github.com/modus75> do you think we should implement it > in Piwigo core? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/Piwigo/Piwigo/issues/681#issuecomment-303365039>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AJRc9qa9dZLoop-EK_lCmtfR9WncNpXMks5r8r1kgaJpZM4NaHjD> > . >

adam commented

2026-10-05 00:08:09 +02:00

No HTTP_X_FORWARDED_PROTO in Wordpress source code.

No HTTP_X_FORWARDED_PROTO in Wordpress source code.

adam commented

2026-10-05 00:08:10 +02:00

FWIW, the solution they provided is specific to their infrastructure, and assumes that https == port 443, so I'm not certain it can be made fully generic. I'm also not sure how standard the HTTP_X_FORWARDED_xxx headers are.

FWIW, the solution they provided is specific to their infrastructure, and assumes that https == port 443, so I'm not certain it can be made fully generic. I'm also not sure how standard the *HTTP_X_FORWARDED_xxx* headers are.

adam commented

2026-10-05 00:08:11 +02:00

Hello Dregad,
I have Piwigo (latest version, 2.93 (?) installed, and face the problem that the URL after encryption with Lets Encrypt also refers to the port 80. In your "how-to" above, you have published a code that this Fix fixes Can you tell me in which file the temporary workaround have to insert and where? Many thanks, Armin

Hello Dregad, I have Piwigo (latest version, 2.93 (?) installed, and face the problem that the URL after encryption with Lets Encrypt also refers to the port 80. In your "how-to" above, you have published a code that this Fix fixes Can you tell me in which file the temporary workaround have to insert and where? Many thanks, Armin

adam commented

2026-10-05 00:08:11 +02:00

@Armin63 it's all in my above comment, just look at the provided patch in unified diff format. Basically you need to remove the lines marked with a leading - from functions_url.inc.php.

@Armin63 it's all in my above comment, just look at the provided patch in [unified diff format](https://en.wikipedia.org/wiki/Diff#Unified_format). Basically you need to remove the lines marked with a leading `-` from _functions_url.inc.php_.

adam commented

2026-10-05 00:08:12 +02:00

Hello Dregad,
yes - they should actually still exist, the unsuspecting, who do not know where the code must be installed, so that the SSL works in the admin area.
Please be so kind, and tell me how to implement exactly.

I built the php code from the post "Hosting provider (permanent) solution" BEFORE the index.php and then after that before the admin.php in the admin order. PIWIGO continued to run flawlessly, but after logging on, you must continue deleting the suffix ": 80".

Thanks to the team that supports me, because php is not known to me in detail. But I learn every day ...
So thanks in advance !!!!!!!!!!!!!!!!

Hello Dregad, yes - they should actually still exist, the unsuspecting, who do not know where the code must be installed, so that the SSL works in the admin area. Please be so kind, and tell me how to implement exactly. I built the php code from the post "Hosting provider (permanent) solution" BEFORE the index.php and then after that before the admin.php in the admin order. PIWIGO continued to run flawlessly, but after logging on, you must continue deleting the suffix ": 80". Thanks to the team that supports me, because php is not known to me in detail. But I learn every day ... So thanks in advance !!!!!!!!!!!!!!!!

adam commented

2026-10-05 00:08:13 +02:00

Can anyone help me here? I tried everything, but can not get to your destination

Can anyone help me here? I tried everything, but can not get to your destination

adam commented

2026-10-05 00:08:14 +02:00

Workaround using PHP's .user.ini and auto_prepend_file

Here is a workaround found in the Piwigo forum if your server accepts https on port 443, but is misconfigured (e.g. due to an odd reverse proxy port) such that it says it would handle it over port 80 instead:

Add a file /path/to/yourdomain/public_html/.user.ini (varies of course wherever your system's PHP user_dir is) with content

; Fix SERVER_PORT making redirects work in Piwigo.
auto_prepend_file = /path/to/yourdomain/public_html/https_port_fix.php

Add a file /path/to/yourdomain/public_html/https_port_fix.php with content

<?php
    // Fix SERVER_PORT  making redirects work in Piwigo.
    $_SERVER['SERVER_PORT'] = 443;
    $_SERVER['HTTPS'] = 'on';
?>

### Workaround using PHP's .user.ini and auto_prepend_file Here is a workaround found in the [Piwigo forum](https://piwigo.org/forum/viewtopic.php?pid=172125#p172125) **if** your server accepts https on port 443, but is misconfigured (e.g. due to an odd reverse proxy port) such that it says it would handle it over port 80 instead: Add a file **/path/to/yourdomain/public_html/.user.ini** (varies of course wherever your system's PHP _user_dir_ is) with content ``` ; Fix SERVER_PORT making redirects work in Piwigo. auto_prepend_file = /path/to/yourdomain/public_html/https_port_fix.php ``` Add a file **/path/to/yourdomain/public_html/https_port_fix.php** with content ``` <?php // Fix SERVER_PORT making redirects work in Piwigo. $_SERVER['SERVER_PORT'] = 443; $_SERVER['HTTPS'] = 'on'; ?> ```

adam commented

2026-10-05 00:08:14 +02:00

Have a look at #982. That fixed it for me.

Have a look at #982. That fixed it for me.

adam commented

2026-10-05 00:08:15 +02:00

in case of header X-Forwarded-Host is set, function get_absolute_root_url will not take care of ports.
see https://github.com/Piwigo/Piwigo/blob/86c561156203870b2c07ad9e4a954098c1d69cc2/include/functions_url.inc.php#L50

e.g. for nginx just add to your proxy location:
proxy_set_header X-Forwarded-Host $http_host;