WP_List_Table uses HTTP-Parameter, not home_url

https://www.php.net/manual/en/reserved.variables.server.php – For those who don’t know, _SERVER is a php call that grabs server and execution environment information.

So yeah, “Contents of the Host: header from the current request, if there is one.” can do that if the host header’s using the IP.

Sorry, I think, I wasn’t clear enough about my question (but thanks anyway): The problem at hand is, that the login – like most of wordpress – uses the home_url or site_url to build urls, making sure, that some funny reverse proxy doesn’t kill the cookie concept.

So the user logs in on server https://www.abc.com (not really), but the reverse proxy calls 1.2.3.4 (again, not really), so the line above will give us a pagination link of https://1.2.3.4/wp-admin/…

The browser says, that there is no cookie from 1.2.3.4 (depending on the settings) and the user has to login again. The login is at https://www.abc.com, the user logs in, can do a lot of things in admin, but when it comes to paging (or search), there’s again the 1.2.3.4 host …

So my question was – or better: should have been – if there is a reason for not using the wordpress parameters and using the HTTP_HOST instead.

The first thing that comes to mind is security. I could write a plugin to screw up the WP parameter, but I can’t forge the HTTP_HOST as easily.

If that’s the case, it’s strange that security is only applied for paging and search in the backend …
??

The front end is where you’d want to plug things into though, y’know? I mean, I’d want flexibility on the front, and cover-my-backside on the back ??

I’m completely with you. All I meant is that it’s strange that editing a post or changing admin setting is based on the defined name (site_url) while searching and paging is “secured” by HTTP_HOST usage …

Not that it’s not a good idea, but I doubt it was intended that way.

Oh … Woah. I thought it went the other way!