bobsblog

Yes. I assume, the problem is the hashing of username and password, that are sent to the smtp server. With the password containing ,< we get an authentication error, withe new password (not containing ,<), it works just fine.

It‘s not a WordPress-User, but the Mail-User (Mailbox), post smtp is connecting to. We got the error message on sending the test-mail from the post smtp backend.

I don’t get that. The form action should be empty, so that the browser usually calls the existing url (and before you search you see the domain name in the address, right?).

Anyway, you could workaround that by replacing the following line in wp-admin/edit.php:

<form id="posts-filter" action="" method="get">

with

<form id="posts-filter" action="<?php echo ( is_ssl() ? 'https://' : 'https://' ) . parse_url(get_home_url(), PHP_URL_HOST) . $_SERVER['REQUEST_URI'];?>" method="get">

But I really don’t get why it happens in the first place. The paging was pretty clear, but that …

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.

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

Have you changed both occurrences in the file?

Ok, if you feel like adventure, you can try the following:

Look for the file at wp-admin/includes/class-wp-list-table.php (and make a backup of the file) and replace the following line:

$current_url = ( is_ssl() ? 'https://' : 'https://' ) . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];

with

$current_url = ( is_ssl() ? 'https://' : 'https://' ) . parse_url(get_home_url(), PHP_URL_HOST) . $_SERVER['REQUEST_URI'];

There should be two occurrences. I don’t have a blog in a sub directory (and I don’t have the time to set up one), so I didn’t test it with sub-directory Blogs but with my domain, it works just fine.

But beware of two things:

First: This fix is quick an dirty (kind of) and I’m trying to find out if there will be a real fix.
Second: As long as there is no real fix, the next update may break this workaround.

It’ll be great, if you can give it a test drive and tell me/us, if it worked.

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.

Doesn’t php 5.3.2 give you the HTTP_HOST?

btw: I’m at home, fed and ready to look into that.

Are you able to create a .php (maybe test.php) file with the following content, call it from your browser and tell me, what you see under HTTP_HOST? It would be interesting to see, if there’s your IP or your “real” hostname.

<?php phpinfo(); ?>

And please delete that file immediately after doing the test!

You’re welcome.

So the problem exists only in list view in the admin panel?
And there, it is only paging? When you edit a post, it works just fine?

And how’s paging with comments?

It might be a problem with WP_List_Table. The class is new with 3.1 … and it’s actually doing the search box and the pagination for most lists in the backend. When I’m at home tonight (I’m currently on the road), I’ll have a look into the code.

P.S.: That will take me another one or two hours (to get home), but I’m quite sure, we’ll find a workaround. It might be a weakness in WP_List_Tables, but maybe there’s a reason for that (not a bug but a feature).

As far as I got it, you relocated your blog recently (march?). Does that relocation correlate to the beginning of the problems?

What’s in siteurl and home (the two URLs in settings/general)?
Are there any plugins running? Maybe one of them is not yet compatible to 3.1.
Do you have a fancy .htaccess, sorry web.config stuff?

The problem is surely, that you login at https://www.in.gov/&#8230; and the browser saves the cookie, then the link is to the ip address. The browser says: “No way, you won’t get this cookie, the other guy named ‘www.in.gov/…’ created.” and you have to log in again, because there’s no cookie from your IP.

The login url is with the server name or the ip? And you can use all the other links in admin just fine?

Hi, do you have the following line in your wp-config.php (maybe from relocating some time in the past …

define('RELOCATE',true);

Sorry, my bad.

Hi Kostas,

by default, wordpress doesn’t have any admin color schemes (or I’m pretty blind). So I assume, you’re using a plugin to change the admin theme.

It might be helpful, to ask the plugin developer (or the forum there) or at least tell us, what you’re using.

Cheers
Bob

P.S.: Or are you using wordpress.COM?