Admin Pagination URLs Use Wrong Hostname

[grimmdude]

The pagination links on the posts/pages screen uses the wrong host in some cases. Particularly for my case I have a Wordpress blog installed on a separate server from my main website, but it's hosted as a subdirectory /blog on the main site using the mod_proxy Apache module. So the pagination links are coming through using the wrong host like this:

​http://1647760595.us-east-1.elb.amazonaws.com/wp-admin/edit.php?paged=2

It seems like these pagination links are the only ones with this issue, and I believe it's because of how they are being constructed.

I've attached a patch that solves the issue for me.

-Garrett

[johnbillion]

Related: #35561.

I'm not sure why there are a few links constructed like this in core. I can't immediately think of anything that would break if they were corrected so they used admin_url().

Does #35561 affect your site too, @grimmdude?

[grimmdude]

@johnbilliion, yes it does look like #35561 is an issue for me as well. Sounds like that OP and I have a similar setup. Thanks,

-Garrett

[johnbillion]

#38414 was marked as a duplicate.

[grimmdude]

Any update on this ticket? Thanks,

-Garrett

[grimmdude]

May I ask what the hold up is on this? Seems like a straightforward fix,

-Garrett

[SergeyBiryukov]

Previously: #18944, #19216, #20562.

[grimmdude]

Hi @SergeyBiryukov,

Just checking in on this one. Does your comment mean that this is something that's being fixed soon? Thanks,

-Garrett

[swissspidy]

The earlier we can test this, the better.

[DaveFX]

Works for me

[swissspidy]

@DaveFX That's not how the dev-feedback keyword should be used. See ​https://make.wordpress.org/core/handbook/contribute/trac/keywords/

[ketanumretiya030]

i have test pagination in admin with pag, post, and media file all is working fine.

[grimmdude]

Hi @ketanumretiya030,

I still see this as an issue when using a proxy as mentioned in the original post. From what I can tell, as long as this URL is built with a concatenation of $_SERVER vars as opposed to using admin_url() then this problem will persist.

​https://github.com/WordPress/WordPress/blob/aaf99e691391cfceb004d848450dbbf3344b1bee/wp-admin/includes/class-wp-list-table.php#L793

-Garrett

[viliusl]

As stated above, this is rare problem, but still happens if WP is used with proxy.

And fix is easy: take host from DB, not form $_SERVER (WP already doing it, sadly, not everywhere).

​https://github.com/WordPress/WordPress/blob/aaf99e691391cfceb004d848450dbbf3344b1bee/wp-admin/includes/class-wp-list-table.php#L793

<?php
$siteurl = get_option('siteurl');
$current_url = parse_url($siteurl, PHP_URL_SCHEME) . '://' . parse_url($siteurl, PHP_URL_HOST) . $_SERVER['REQUEST_URI'];

p.s. similar situation with sorting:
​https://github.com/WordPress/WordPress/blob/aaf99e691391cfceb004d848450dbbf3344b1bee/wp-admin/includes/class-wp-list-table.php#L1077

[wellmadedigital]

We had this same issue and stumbled on this:

"The site’s wp-config.php file needs to be updated with a $_SERVERHTTP_HOST? definition pointing at the main site URL (example.com in the example we’ve been considering)." Source: ​https://kinsta.com/knowledgebase/reverse-proxy/

Adding $_SERVER['HTTP_HOST'] = 'yoursite.com'; to our ProxyPass settings in wp-config resolved it.

As an example:

Site exists at subdomain.yoursite.com. Proxied to www.yoursite.com/subdomain

Added to wp-config to make this work and resolve many of the Wordpress Admin URL issues (pagination, editing users, etc.):

<?php
# ProxyPass Settings 
# 
# DO NOT REMOVE: overriding the following variables is
# required to ensure that any request /journal/* is handled
$_SERVER['REQUEST_URI'] = '/subdomain' . $_SERVER['REQUEST_URI'];
$_SERVER['SCRIPT_NAME'] = '/subdomain' . $_SERVER['SCRIPT_NAME'];
$_SERVER['PHP_SELF'] = '/subdomain' . $_SERVER['PHP_SELF'];
$_SERVER['HTTP_HOST'] = 'www.yoursite.com';

I still agree with the OP that this feels like a core bug, but I wanted to throw this out there as an alternative solution that doesn't require core revision.

[ocean90]

#46037 was marked as a duplicate.

[ocean90]

#47033 was marked as a duplicate.

[ooglek]

Let's make this happen! Is the best path here using admin_url(), get_option('siteurl'), get_site_url() or some other replacement for the hardcoded $_SERVER['HTTP_HOST'] ?

admin_url() calls get_admin_url() which calls get_site_url() which calls get_option('siteurl')

It seems admin_url() is a higher level method and better place to start. The original diff seems appropriate.

There are only three places left in the wp-admin/ directory where HTTP_HOST is referenced:

in misc.php 5.1.1

<?php
1164
1165     // Ensure we're using an absolute URL.
1166     $current_url  = set_url_scheme( 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] );
1167     $filtered_url = remove_query_arg( $removable_query_args, $current_url );

In class-wp-list-table.php 5.1.1

<?php
 796         $removable_query_args = wp_removable_query_args();
 797
 798         $current_url = set_url_scheme( 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] );
 799
 800         $current_url = remove_query_arg( $removable_query_args, $current_url );

and

<?php
1080         list( $columns, $hidden, $sortable, $primary ) = $this->get_column_info();
1081
1082         $current_url = set_url_scheme( 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] );
1083         $current_url = remove_query_arg( 'paged', $current_url );
1084

Let's fix this.

[SergeyBiryukov]

#47356 was marked as a duplicate.

[kwhat]

What can be done to speed up the adoption of the above fixes? Can I make a pull-request or do we need a diff file or is something else holding this up?

[kwhat]

Updated patch, please apply!

[waddles]

updated for wordpress > 4.6

[waddles]

One would think forcing a url scheme to http:// would be a security concern in 2019.

I think the original solution is best so I updated the patch to support changes made in 4.6.

[grimmdude]

Wow, this is still pending? I created this ticket over three years ago :o

[kwhat]

I have a feeling this ticket has fallen into the backlog abyss. I am not holding my breath that this will be addressed in the next 3 years. You know when you stumble across that 17 year old bug on redit that is finally getting fixed? Yah, its kind of like that.

[tinodjwp]

Latest update caused problems. Can you please fix this?

[liemdo]

It's been a few years already and it seems the problem still persists. Any updates on this one?

[ocean90]

#50157 was marked as a duplicate.

[jschodermedikura]

We have the exact same issue and only really dirty workarounds. It takes longer to argue about this than to actually fix this. To quote John Oliver: How is this still a thing?

[viliusl]

Replying to jschodermedikura:

...It takes longer to argue about this than to actually fix this...

Its funny and sad at the same time.
I predict this discussion will continue for at least 3 years more. Now somebody prove me wrong ...

[ocean90]

#50365 was marked as a duplicate.

[higuita]

So 4 years later, having already a patch for at least 1 year and still not fixed :(

How about a plugin to fix this? is it possible?

Lets try to ping the core commiters already in the ticket!

@ocean90 @SergeyBiryukov @swissspidy @obenland

[viliusl]

How about a plugin to fix this? is it possible?

Not possible to fix with plugin in clean way, unless using methods, that gives even more problems (ob_start).

[joelfbr]

Thank you for the great advice! this finally helped me in a similar issue.

Now, I am wondering which file we have to edit to force WP to always respond with the correct host.
see my question on ​https://stackoverflow.com/questions/65671943/wordpress-redirect-to-main-host

Replying to wellmadedigital:

We had this same issue and stumbled on this:

"The site’s wp-config.php file needs to be updated with a $_SERVERHTTP_HOST? definition pointing at the main site URL (example.com in the example we’ve been considering)." Source: ​https://kinsta.com/knowledgebase/reverse-proxy/

Adding $_SERVER['HTTP_HOST'] = 'yoursite.com'; to our ProxyPass settings in wp-config resolved it.

As an example:

Site exists at subdomain.yoursite.com. Proxied to www.yoursite.com/subdomain

Added to wp-config to make this work and resolve many of the WordPress Admin URL issues (pagination, editing users, etc.):

<?php
# ProxyPass Settings 
# 
# DO NOT REMOVE: overriding the following variables is
# required to ensure that any request /journal/* is handled
$_SERVER['REQUEST_URI'] = '/subdomain' . $_SERVER['REQUEST_URI'];
$_SERVER['SCRIPT_NAME'] = '/subdomain' . $_SERVER['SCRIPT_NAME'];
$_SERVER['PHP_SELF'] = '/subdomain' . $_SERVER['PHP_SELF'];
$_SERVER['HTTP_HOST'] = 'www.yoursite.com';

I still agree with the OP that this feels like a core bug, but I wanted to throw this out there as an alternative solution that doesn't require core revision.

Currently, WP_List_Table uses $_SERVER['HTTP_HOST'] to build pagination and column header links. These links will point to an incorrect host if $_SERVER['HTTP_HOST'] does not match the site URL host, e.g. when Wordpress is used behind a reverse proxy.

This uses admin_url() so that these links will take the configured site URL into account.

Trac ticket: https://core.trac.wordpress.org/ticket/36201

[jefferyto]

As mentioned by the GitHub bot, I have a PR (​https://github.com/WordPress/wordpress-develop/pull/1503) that addresses this issue - would appreciate it if a core committer can take a look.

On setting $_SERVER['HTTP_HOST'] in wp-config.php: For multisite installations using subdomains, this isn't a viable workaround because WordPress uses $_SERVER['HTTP_HOST'] to figure out which site to show/edit/etc. If $_SERVER['HTTP_HOST'] is set to a value that isn't one of the subdomains WordPress knows about, e.g. the public name of a reverse proxy server, WordPress will prompt you to add a new site to the network.