backend 500 & 404 errors

I am able to back out of the error page using my browser back button

That indicates to me an issue with site caching either local or server.

I’m not sure what that means, or what to do with it.

I updated to WordPress 3.8.1 to see if that would fix the problem. I had to do it manually, as the updates page of my Dashboard is one of the pages I can’t access. Wow, what a hassle compared to the one-click update! After updating, I no longer got the 500/404 error when logging in with an incorrect username or password. The logon page returned to its cute head-shaking behavior when incorrect info is entered in either field.

However, the update to 3.8.1 did not fix the errors when attempting to access the Dashboard/Updates and Appearance/Themes pages. Furthermore, after the update, my Plugins/Installed Plugins page also returned the 50/404 error, which was a headache, since I had deactivated the plugins to do the manual update, and couldn’t get to them to turn them back on. However, I was able to fix this by deleting hello.php from the plugins directory (which is the only file I had added to that directory during the WordPress update). Then I was able to access Plugins/Installed plugins again and reactivate my plugins.

Additional information:

“500” does not actually appear in the title of the error page. I added it to “Internal Server Error” because the browser tab shows “500 Internal Server Error” as the page title.

The URLs for the pages that return the 500/404 errors are:

our_domain/subfolder/WordPress/wp-admin/update-core.php (Dashboard/Updates page)

our_domain/subfolder/WordPress/wp-admin/themes.php
(Appearance/Themes)

What do those two pages have in common that is not true of any other page in the dashboard? Could really use some help from people who know more about this than I do….

BTW, my login userID no longer seems to be case sensitive. Is that new, or has that always been true and I’m just now noticing it?

I am having this exact same problem.

I even went as far as doing brand new fresh install using the default theme and no plugins I still get the same issue.

This is so very weird.

I am curious what theme you are using? My older, not updated theme is one of the suspects in my case.

BTW, I am back to receiving the error on the login page if I enter the password incorrectly (for awhile there it reverted to normal headshaking behavior, but no longer, and I’m pretty sure I haven’t changed anything, this time).

What’s more, I’m getting the error on the login page even when I enter the <i>correct</i> password. If I refresh the page (without re-entering the password), it does log me in the second time. I don’t think it should be saving my entered password info so that it’s still there for a page reload, should it? (Though of course I’m glad I can log in to my dashboard).

The only other person who has bothered to respond to this thread said something about caching issues (which the above also sounds like, no?). Unfortunately, that person did not elaborate, so I don’t really know what to do with that information.

Please bear in mind, folks, that if we were programmers, we would probably not need to post to this forum in the first place.

If you require assistance then, as per the Forum Welcome, please post your own topic.

What’s the content of the .htaccess file?

(Use the code tags in the bar above the text box so it’ll be readable)

There are two, not sure which one you mean. The one at the same level as the WordPress folder is the password protection one, I believe.

AuthUserFile [PATH] .htpasswd
AuthGroupFile /dev/null
AuthName [HIDING IT]
AuthType Basic
<limit GET>
require valid-user
</limit>

The one in the level above the WordPress folder:

Action php-cgi /cgi-bin/php5
AddHandler php-cgi .php
SetEnv DEFAULT_PHP_VERSION 5

I think the php version is something our host had me put in.

Is this site behind a firewall or proxy of any kind? Not just an htaccess based password, but is it actually restricted from outgoing internet access?

No.

But our web host is primarily an ISP, so I think their directory structure is a little different. I’ve already spoken to them. They said it was a WordPress issue, but they don’t really know anything about WordPress. If I can identify a problem on their end, they are usually pretty responsive, but I’m on my own for figuring out what it is before I go to them. We’re a non-profit and get our hosting free, so we can’t really complain!

Original poster here, still trying to fix this. I’ve been reading various troubleshooting guides on this error, and they all refer to an htaccess file in the same directory as the wp-content, wp-admin and wp-includes folders. I don’t have an htaccess file there (a bunch of other places, but not there). Should I?

I tried going to my permalinks setting in my dashboard and saving settings, which (according to these same troubleshooting guides) supposedly generates a new and correct htaccess file if you don’t already have one there, but nothing happened. Still no htaccess file.

The problem is wordpress and it’s happening anytime you update a theme to a newer revision. I’m on wordpress 3.8.1 and I updated my WooCommerce Theme from 2.1.3 to 2.1.4 and 2.1.5 a day later. If you right click your mouse on your webpages in wordpress and select “Inspect element – Console” you will see this error message: event.returnValue is deprecated. Please use the standard event.preventDefault() instead.
Failed to load resource: the server responded with a status of 500 (Internal Server Error) https://www.oneshopatatime.com/wp-admin/admin-ajax.php. <- This is a wordpress file that is blocking any attempt to change sql database values using theme settings. This is only a problem after updating a Theme to a newer revision.

It’s not likely we will see a fix for the above problem anytime soon. If you read back through the posts on the Wootique website, the same problem was being reported over 6 years ago. The issue appears to be that when a Theme is being installed, there are configuration parameter values that need to be provided by the Theme Plugin to the WordPress installation manager. These values need to be changed in the appropriate database and any cached registers dumped before the install. All the values needed to make the interface between the new Theme and WordPress work are either not being reported or they are being ignored or they are being overwritten by cached values stored in some register that was not dumped prior to the theme change. [advertising copy removed by moderator]

I finally found the problem. It was indeed in an htaccess file, which I had placed in the directory above my WordPress installation back in 2011 under direction from my webhost to force it to run php 5 instead of php 4 (which was my host’s default php version at the time). Although my host now runs php 5.5, that file was keeping it at php 5, which is now too low to run WordPress. I updated the file (which I did by changing 5 to 55, NOT 5.5, in case anyone else needs to do this), and the problem was finally fixed.

Thanks to everyone who tried to help me with this!