Forum Replies Created

Viewing 10 replies - 1 through 10 (of 10 total)
  • Thread Starter Gurth

    (@gurth)

    OK, thanks. Away they go.

    Thread Starter Gurth

    (@gurth)

    Whether the files should be there or not isn’t the question; removing them isn’t going to fix the problem.

    Not by itself, but it’s probably part of the solution.

    You need to start working your way through these resources:

    That’s what I was doing and that’s why I found those files. But because I’m not sure they shouldn’t be there, I decided to ask before removing them.

    Thread Starter Gurth

    (@gurth)

    Thanks, but unfortunately, that still causes the same loop — in other words, nothing appears to have changed.

    Thread Starter Gurth

    (@gurth)

    Thanks, I’ll pass it on and hope this does help.

    Thread Starter Gurth

    (@gurth)

    Contacting the host pointed us in a new direction, but it’s not really resolved the issue yet. The web server’s logs contain the following errors:

    [Sun Mar 15 12:27:34 2015] [error] [client [redacted]] SoftException in Application.cpp:351: Mismatch between target UID (500) and UID (504) of file “/home/[redacted]/domains/[redacted]/public_html/wp-admin/user-new.php”, referer: https://[redacted]/wp-admin/profile.php
    [Sun Mar 15 12:27:34 2015] [error] [client [redacted]] Premature end of script headers: user-new.php, referer: https://[redacted]/wp-admin/profile.php

    UID 500 is a generic user, 504 is the user for my site. So what seems to be going on, is that the files have a different user than they’re expected to have, which is why they “can’t be found”.

    Googling these error turns up that it’s not an unknown problem, and isn’t restricted to WordPress — it appears to be related to suPHP, which (so the host informs me) is needed here because WordPress requires a setting that’s considered unsafe, but suPHP allows this to be set per user so it won’t compromise everybody’s security.

    The commonly-recommended solution appears to be to do a chown recursively (so in my case, chown -R 504:504 in the user’s home directory), which I got the host to do for me, but it didn’t resolve the problem ??

    My ideas are beginning to run out, though …

    Thread Starter Gurth

    (@gurth)

    That seems to be the only recourse. Time to send an e-mail …

    Thread Starter Gurth

    (@gurth)

    I just got round to checking, and there are no .htaccess files in any directory in the path from wp-admin/ on up, so that’s not it either. (In case you’re going to ask: yes, I did make sure to have my FTP client show hidden files ?? This is getting seriously strange, if you ask me.

    Thread Starter Gurth

    (@gurth)

    Yep. I clicked the “check all” button at the top and then chose to deactivate them. What I find odd is that changing the permalinks causes the error code to change to 500, which suggests to me that the 404 might be a misleading error caused by the permalinks getting confused because of the actual problem that’s occurring. But what that problem would be, I haven’t got a clue ??

    FWIW, I also just changed my site’s theme to Twenty Fifteen, as I remembered I hadn’t tried disabling my custom theme yet, and the users page still 404s.

    Thread Starter Gurth

    (@gurth)

    I set them to “standard” to try that, and instead of a 404, the pages now give a 500 Internal Server Error. Anything else than “Standard” causes a 404.

    Thread Starter Gurth

    (@gurth)

    No problem there — I’ve been coding HTML etc. for close on 20 years, so it didn’t take me long to figure out where and to put in the PHP ?? I can see how it might puzzle other people, though. (As for why my theme didn’t include a call to wp_footer(), that’s because I made it myself and don’t think I read anywhere about that call being required, so I had left it out.)

Viewing 10 replies - 1 through 10 (of 10 total)