Moderator
James Huff
(@macmanx)
Volunteer Moderator
Internal server errors (error 500) are often caused by plugin or theme function conflicts, so if you have access to your admin panel, try deactivating all plugins (all of them). If that resolves the issue, reactivate each one individually until you find the cause.
If that does not resolve the issue, try switching to the Twenty Sixteen theme to rule-out a theme-specific issue.
If that does not resolve the issue, it’s possible that a .htaccess rule could be the source of the problem. To check for this, access your server via SFTP or FTP, or a file manager in your hosting account’s control panel, and rename the .htaccess file. If you can’t find a .htaccess file, make sure that you have set your SFTP or FTP client to view invisible files.
If you weren’t able to resolve the issue by either resetting your plugins and theme or renaming your .htaccess file, we may be able to help, but we’ll need a more detailed error message. Internal server errors are usually described in more detail in the server error log. If you have access to your server error log, generate the error again, note the date and time, then immediately check your server error log for any errors that occurred during that time period. If you don’t have access to your server error log, ask your hosting provider to look for you.
A quick word on your host though. The PHP 5.2 branch was discontinued over 5 years ago: http://php.net/eol.php If they still have not yet upgraded PHP on your server, I strongly recommend finding a new hosting provider.
Thanks for the reply. I had already tried disabling the plugins, and I knew that .htaccess hadn’t been changed since I originally built the site over a year ago, but I did everything as you suggested, and it turns out that the offender is my child theme! Since the problem happens on the admin panel, not the site itself, I wasn’t thinking of themes.
Indeed there is plenty of code in my child theme, most having to do with a custom post type and/or language issues (areas where even WPML fell short of how I wanted it to behave). I laboriously commented and uncommented parts of my functions.php until I honed in on a single line of code that I could comment out and see “Posts -> Add New” run without errors – it relates to WPML, so I’ll have to ask them why it’s no longer compatible.
But the general WordPress concept that baffles me is that apparently save_post() is run even when initially displaying the form for adding a post. The offending code was in a function that I am hooking like this: add_action('save_post', 'duplicate_or_translate_new_entry'); Why does that run when I merely click “Posts -> Add New” (not when I save, but just trying to see the new post form)?
Moderator
James Huff
(@macmanx)
Volunteer Moderator
What version of WordPress were you running prior to this?
Thanks, the plug-in conflict was it for me. Funny thing it was a Malware plug-in that was causing the problem.
@kollman: Yes, it’s always good to disable plugins as one of the first steps in troubleshooting.
In the future, though, it would be better to not hijack other people’s threads to talk about your own issue, since it was not contributing to the original question and may confuse people. Many, many times I found an answer by reading other people’s threads, but I don’t jump in even to say thank you. (In something like Stack Overflow we can up-vote, but here there isn’t that mechanism.)
@james: I don’t think WordPress core was even updated at this time. I have auto-update turned on, and although I know that major version changes aren’t done automatically, I don’t remember having any this time. It was just a pile of plugins, including WPML – the WPML update probably caused my code to become incompatible, since the offending line of code was checking something in a WPML object. In case you’re curious, here is the line (ok, two lines) inside the duplicate_or_translate_new_entry() function that was hooked into save_post():
$lang = wpml_get_language_information($post_id);
if ( $lang["native_name"] == "Japanese" ) return;
Commenting out the second line solves the error 500 problem, so I need to ask WPML what to do about it. But I was just curious why this code runs at all when calling up the Add New form.
Moderator
James Huff
(@macmanx)
Volunteer Moderator
Hm, just that line itself shouldn’t do that, but it’s probably hooked into something else that does by way of WPML.
I don’t know what else it’s hooked into, but I finally figured out that they changed the name (and usage) of wpml_get_language_information: https://wpml.org/wpml-hook/wpml_post_language_details/ I changed to their new syntax and I’m not getting errors anymore. (To test to see if the code is actually catching cases that should not go past that point would be more involved, so I haven’t done that yet.)
My question for you isn’t about the code inside my function (I just shared that because I thought you might be curious), but why save_post() (and things hooked into it) is running at a time when nothing is being saved (merely displaying a form).
Moderator
James Huff
(@macmanx)
Volunteer Moderator
WordPress introduced auto-saving back in 3.6, so I assume it’s that: https://wordpress.org/news/2013/08/oscar/
Perhaps. I wouldn’t have expected that to kick in before the form page has even loaded, but who knows… that one will have to remain a mystery. Thanks for the help!
