Resolved Missing HTTP_HOST causes incorrect URL generation in WP Toolkit

[Maarten]

Username:

TITLE

Missing HTTP_HOST Causes Incorrect URL Generation in WP Toolkit

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian 18.0.64 Update #1
AlmaLinux 8.10
WP Toolkit version 6.5.4-8879

PROBLEM DESCRIPTION

When using WP Toolkit in Plesk and switching the PHP handler to FPM application served by nginx, the $_SERVER['HTTP_HOST'] variable is undefined. This causes WordPress to generate incomplete URLs in the admin panel. For example, the pagination links on the "Pages" overview page lose the domain name, resulting in incorrect URLs like:

https://wp-admin/edit.php?post_type=page&paged=2

Instead of:

https://domain.com/wp-admin/edit.php?post_type=page&paged=2

STEPS TO REPRODUCE

• In Plesk, switch a WordPress instance's PHP handler to FPM application served by nginx using WP Toolkit.
• Access the WordPress admin panel (/wp-admin).
• Navigate to Pages (Pages > All Pages) and click the pagination links at the top of the page.
  

ACTUAL RESULT

The pagination links are missing the domain name (SITEURL) and appear as:

https://wp-admin/edit.php?post_type=page&paged=2

This results in a broken link and an inability to navigate between pages. Additionally, when WordPress debugging is turned on, a PHP warning appears in the wp-content/debug.log:

PHP Warning: Undefined array key "HTTP_HOST" in /var/www/vhosts/domain.com/httpdocs/wp/wp-admin/includes/misc.php

EXPECTED RESULT

Pagination links should include the correct domain name (SITEURL), as follows:

https://domain.com/wp-admin/edit.php?post_type=page&paged=2

ANY ADDITIONAL INFORMATION

Temporary Workaround
Adding the following code to wp-config.php resolves the issue temporarily:

if (!isset($_SERVER['HTTP_HOST'])) {
   $_SERVER['HTTP_HOST'] = 'domain.com'; // Replace with the actual domain
}

However, this is not a long-term solution and requires a proper fix at the server or WP Toolkit level.

Additional Notes

• The issue appears specific to the FPM application served by nginx configuration. Switching back to another PHP handler (e.g., Apache with nginx) resolves the issue.
• Likely related to nginx not passing the HTTP_HOST variable correctly to PHP-FPM in the default configuration.
• HTTP/3 is turned on the server.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[Kaspar]

FWIW: It's a limitation when using HTTP/3 caused by Ngnix. See this thread with another possible workaround: Resolved - Nginx HTTP3 cause invalid redirect on WordPress

 

[Maarten]

Thanks!
I checked the nginx trac and noticed they’ve marked this as “won’t fix.” Given this, will Plesk consider providing an update to include:
fastcgi_param HTTP_HOST $host; in a /etc/nginx/conf.d/fix-http-host.conf file to address the issue?

Or… should we start replacing nginx with Caddy Server?

 

[Kaspar]

Yeah, I don't get why the Nginx devs are so reluctant to support the $http_host variable, while other web servers like OLS and Caddy already support this for HTTP/3 without any additional configuration. It makes HTTP/3 on Nginx a lot less usable and as a result less useful on Plesk.

 

[Maarten]

True, but will Plesk consider providing an update to address this issue? Without a fix, HTTP/3 becomes pretty much useless when using nginx in this setup.

 

[Maarten]

I've contacted Plesk Support about this issue. They have acknowledged the Nginx limitation and are currently reviewing it with their team to determine the best approach for a solution. I'll share any updates I receive.

 

[Maarten]

Update:
I've asked the Plesk Support team to create an article explaining the issue and providing a temporary workaround. While it's not a definitive solution, it ensures that users can find information about the symptoms and a way to address them on the Plesk Support page:

https://support.plesk.com/hc/en-us/articles/28416628603415-On-WordPress-website-hosted-on-Plesk-for-Linux-server-pagination-buttons-in-WordPress-Admin-dashboard-do-not-work-as-expected

 

[Maarten]

Update:
I’ve noticed that this issue with $http_host in WordPress has been known for 9 years (Ticket #34353). Given that Nginx is widely used in Plesk environments and HTTP/3 adoption is growing, this limitation could affect a significant number of users.

It’s important to note that this issue doesn’t lie with Nginx, as they adhere to the HTTP/3 specifications. The problem arises because WordPress relies on $http_host, which isn’t always available in HTTP/3. The recommended approach, according to Nginx, is to use $host instead.

I’ve brought this issue to the attention of the Plesk Support Team and suggested they advocate for a solution with the WordPress Core Development Team. Since this problem affects HTTP/3 compatibility, I believe Plesk’s involvement could help bring more attention to this matter.

 

[Kaspar]

Thank you Maarten for discussing this with the support team!

 

[Maarten]

This is what I get from Plesk Support, no real solution, only telling "this is not a Plesk problem" and "you don't have to use WP + Nginx":

---
After reviewing the situation, I would like to clarify why Plesk will not be addressing this issue directly. Here are a few key points to consider:

• the issue is not with any specific component but rather the compatibility between them. It only occurs when using HTTP/3, PHP is served by Nginx and WordPress. This is a specific setup and not a general problem affecting all users of HTTP/3, Nginx or WordPress.
• there is a straightforward fix that can be applied by adding the variable fastcgi_param HTTP_HOST $host; to the Nginx configuration. This allows users to address the issue based on their specific requirements
• users have the flexibility to apply any necessary fixes to their Nginx configuration. If PHP served by Nginx is not suitable for their setup, they can choose alternative configurations
• the software works as expected, and there is no inherent bug in Plesk. Plesk provides the software and tools to manage it, but it is not responsible for customizing it to fit specific applications
• there have been recent discussions on this issue, including comments from WordPress representatives in the thread that has been provided and it seems WordPress team is aware of this issue - it is up to them if they are willing to change how their application functions and how to address this.

Nevertheless, I will make sure to include this request in my report for consideration.

---
@Sebahat.hadzhi @AYamshanov
Could you please chime in on this issue? The request number is #95413018

Given that this problem affects WordPress installations running on HTTP/3 with PHP served by Nginx, and the suggested workaround (fastcgi_param HTTP_HOST $host;) gets overwritten during Plesk updates, it would be great to have some official guidance or acknowledgment.

This is not just a one-off issue, but something that could impact a growing number of users as HTTP/3 adoption increases. A more permanent solution at the template level or advocacy towards the WordPress Core Team might be helpful.

Thank you

 

[Not_allowed_to_use_email]

It also affects Joomla (at least v4 and v5) with HTTP/3 and nginx-fpm:
The backend shows an URI parse error for https:///administration/... (missing hostname)

BR

 

[Sebahat.hadzhi]

@Maarten, I brought the issue to our WP Toolkit's team attention and further discussed the case with one of our software development leads. Unfortunately, at this point, we are not planning to perform any changes due to the following reasons:

• According to NGINX developers $http_host should not be used, and they don't want to encourage its usage for http/3 connections (#2281)[#2281 (QUIC: failed to get $http_host variable for http3 request) – nginx]
• PHP developers also don’t plan to improve anything (#13201)[`$_SERVER['HTTP_HOST']` doesn't exist when requesting via HTTP/3 on nginx · Issue #13021 · php/php-src]
• Switching HTTP_HOST to the $host may break existing sites, for example, it doesn’t include port number

Regarding the workaround suggested, I performed a test on an AlmaLinux 8.10 server and I can confirm that /etc/nginx/fastcgi.conf remains intact after a Plesk upgrade.

 

[Maarten]

Thank you for the detailed response and clarification regarding the positions of NGINX and PHP developers.

However, my main point was not addressed: the WordPress ticket (#34353) has been open for 9 years, and the issue lies in how WordPress handles $http_host. Given that WordPress is one of the most popular CMS platforms and Plesk provides robust tools for managing WordPress sites, wouldn't it make sense for Plesk to advocate for this with the WordPress Core Team?

When this ticket was created 9 years ago, HTTP/3 didn’t even exist. Now that HTTP/3 adoption is growing rapidly, this issue has become much more urgent. The combination of HTTP/3, WordPress, and NGINX is becoming increasingly common, and resolving this would benefit a large number of users.

This wouldn’t require significant effort from Plesk—simply putting some pressure on the WordPress Core Team to prioritize this ticket could go a long way. Would the WP Toolkit team be willing to take this step?