WillemGrooters

All extensions (except a few that are propitiatory) are build-in, and for the rest the blog works, except (it seems) for these two. I would expect that WordPress – even 4.9.8 – is able to cope with the habits of later PHP versions than 5.2, especially given the fact that these higher versions are recommended
There is one weird thing in PHP_ERRORS, but just ONE line, and this problem occurs many, may times.
I won’t rule out platform specific components here, but that would mean that these scripts (or their callers) don’t clean up. This is something I will try to find out.

As suggested switched to 2019 theme. But since the issues I have seem to be in wp-admin-ajax and rss-feeds – but these have nothing to do with the themes, I think, so I wonder if this helps.

Is doesn’t.

There is nothing special in my blogs: using 2015 and 2017 themes and just Aksimet (All plugins are disabled, due to issues with WP 5.2). Though I updated both themes, the problem persists: on editing, wp-admin-ajax shows up in accesslog as
POST /sysblog/wp-admin/admin-ajax.php HTTP/1.1″ 400 0
and again, I cannot publish or update. After some time, I _might_ be able tp do that but there is no guarantee.

Makes no difference.

Thanks, that’s just what I was looking for ??

I have reasons for this: this configuration is used to compare different server configurations, or even completely different web servers (a facility I have on my OS of choice), and therefore the only difference should be the server by which the application (in this case WordPress) is accessed. And each of these will access the application over it’s own port. B ecause that port is kept in the URL stored in the database, it is limiting access over that port only. I have observed that when port 81 is defined, access over port 82 will start the access, but the server on port 81 will take over at some point, and some functionality does not work…Different blogs (no problem for me – because the OS) using one database is no option either – for the same reason: the URL stored in the database will limit access over that single port….
So port forwarding nor mutisite installtion will do the trick…

I don’t have any. The one I found was in /wordpree/WP-CONTENT/THEMES/wordpreciousss/theme-base/ (don’t bother on case, it’s no issue on my system). Removing it makes no difference.

As stated before, reversing to 2.6.3 solves the problem. The problem mmust be within WP, sine that contuinues to return status 301, where 2.6.3 ends with status 200.

No change.
The PHP code keeps returning:

‘Status: 301’
‘X-Powered-By: PHP/5.2.6’
‘X-Pingback: https://server.my.domain/blog/xmlrpc.php’
‘Content-Type: text/html; charset=UTF-8’
‘Location: https://server.my.domain/blog/’
‘Script-control: X-stream-mode’

and a new request is made – until the browser (or server) gives up.

This blog is VERY basic, I didn’t add any…
But I’ll give it a try (if I can get into the admin panel)

Plugin disabled before update, and after: no difference.
Changed theme (default –> anonther, than back to default): No difference

Current state is default theme, no plugins enabled. Still redirection loop…

cache ????

Well, found one thing, and that solved that problem: BLOG_CHARSET = UTF-8. Changed that and that problem seemed to be solved. But now adding medai doesn’t return to the page…

I’m not sure if this is the right place to note a potential problem:

I do have the same problem on _one_ of my blogs; The admin page (wp-admin/index.php) is accessed via a link on another (secired) page and redirects:

https://domain.com/tracks/wp-login.php?redirect_to=http%3A%2F%2Fdomain.com%2FTracks%2Fwp-admin%2Findex.php

Just remove everything from and including “?” and it’s fine. Well, sort of. Even specifying “remember me” doesn’t work. I always have to remove the redirection.

The other blog’s admin page can be accessed from it’s own pages, and works without redirection.

The only difference I find: the first mentioned blog has been upgraeded from 2.2.3 to 2.6.3 in one shot; the other gre towards this version (2.2.3 -> 2.3 -> 2.6 -> 2.6.3).

Sounds a bell ?? and it might even be worse.

Similar problem with only ONE of my blogs after upgrading from 2.2.3 to 2.6.3. The only way to get in was requesting a new password and use that.
problems arose with changing this generated passwordt to what I use normally: That fails because the response is said to be non-CGI-compliant:

...
profile.php (cgi_exe:phpwasd.exe) TRACKS:[WP-ADMIN]profile.php
-NOTICED-I-CGI, 5374617475733A203330320D0A582D506F77657265642D42 (2048 bytes) Status: 302..X-Powered-B
...

Status: 302..X-Powered-B – the dots stand for <CR><LF>. Since this is the only place where the problem occurs (other locations for Status 302 have no problem whatsoever) I guess there is something wrong in the PHP code, that “X-powered-B….” is added.
The server is set to NOT allow that.

I bypassed it by entering – as a string – the encrypted password I use in another WP blog, and I could login as ususal.

I guess this is caused by an error somewhere in the PHP code. Mine is a “non-standard” environment (no Linux or Windows), so it’s easiest to point to the environment that causes the problem. But since this is the only location in the whole package that I run into this problem, it’s not very likely to be the server to be in error.

Save yourself a LOT OF TROUBLE and make your WP files and directories READONLY (except for the upload directories if you need them) for any one except yourself and the webserver. That server should never be running in a privileged account. If that is a requirement, think of changing eitehr you r access scheme or your server.
Secure your access data from access by a browser. Jutst the PHP module/engine needs to know. Not the server.