Opened 5 years ago
Last modified 2 weeks ago
#36201 reopened defect (bug)
Admin Pagination URLs Use Wrong Hostname
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Administration | Keywords: | has-patch needs-testing dev-feedback |
Focuses: | administration | Cc: |
Description
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
Attachments (3)
Change History (40)
#1
@
5 years ago
- Focuses administration removed
- Keywords has-patch added
- Milestone changed from Awaiting Review to Future Release
#3
@
5 years ago
@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
#8
@
4 years ago
Hi @SergeyBiryukov,
Just checking in on this one. Does your comment mean that this is something that's being fixed soon? Thanks,
-Garrett
#9
@
4 years ago
- Milestone changed from Future Release to 4.8
The earlier we can test this, the better.
#11
@
4 years ago
@DaveFX That's not how the dev-feedback keyword should be used. See https://make.wordpress.org/core/handbook/contribute/trac/keywords/
This ticket was mentioned in Slack in #core by obenland. View the logs.
4 years ago
#14
@
3 years ago
- Keywords close added
- Resolution set to maybelater
- Status changed from new to closed
i have test pagination in admin with pag, post, and media file all is working fine.
#15
@
3 years ago
- Resolution maybelater deleted
- Status changed from closed to reopened
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.
-Garrett
#16
@
3 years ago
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).
<?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
#17
follow-up:
↓ 37
@
22 months ago
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.
This ticket was mentioned in Slack in #slackhelp by ooglek. View the logs.
21 months ago
#21
@
21 months ago
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.
#23
@
20 months ago
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?
#24
@
18 months ago
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.
#25
@
18 months ago
- Focuses administration added
Wow, this is still pending? I created this ticket over three years ago :o
#26
@
18 months ago
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.
#29
@
10 months ago
It's been a few years already and it seems the problem still persists. Any updates on this one?
#31
follow-up:
↓ 32
@
9 months ago
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?
#32
in reply to:
↑ 31
@
9 months ago
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 ...
#34
@
5 months ago
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
#35
@
5 months ago
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).
This ticket was mentioned in Slack in #core-media by johnbillion. View the logs.
4 months ago
#37
in reply to:
↑ 17
@
2 weeks ago
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.
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?