I'm facing a weird issue with a Wordpress installation and I'm not sure how to proceed further. I've developed a simple AJAX endpoint only available for logged in users, which returns the details of a custom post type associated with the user. Example:

function get_return_request_detail() {
    $returnRequestId = (isset($_POST['return_request_id'])) ? $_POST['return_request_id'] : '';
    if(empty($returnRequestId)) {
        echo json_encode("missing parameter");

    $results = get_post_meta($returnRequestId);
    $meta = unserialize($results["_meta"][0]);

    if($results["_field_user_id"][0] == get_current_user_id()) {

        ... logic ...

        echo json_encode($data);
    } else {
        echo json_encode("unauthorized");
add_action('wp_ajax_get_return_request_detail', 'get_return_request_detail');

The endpoint works fine and I retrieve the data correctly. An example on how I call it:

            type: "post",
            dataType: "json",
            url: "/wp-admin/admin-ajax.php",
            data: {
                return_request_id: id,
            success: function(response) {

The problem is that as soon as I switch to another page the whole front-end starts returning an error:

Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at [no address given] to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

I've tried enabling both debug and debug_log but I still receive the same message with nothing being written in the log. To enable it I've just added in the wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );

The weird behaviour is that, in order to make the front-end work again, I just need to visit an Admin page and the error disappears. My questions are:

  1. Is there any way to have a more detailed error log for this issue?
  2. Do you have any idea on what could be possibly causing it? Something related to admin-ajax?

What I've tried so far, with no results:

  1. Check Wordpress core file permission;
  2. Replace core files with a fresh installation;
  3. Followed this answer in order to enable error logging for admin-ajax.php (no results);
  4. Disable caching / security plugins;
  5. Disable Server Side caching (Dynamic Cache & Memcached);
  6. Check error logs on Server (the error produces no log);


  • Replace exit; with wp-die(); in your AJAX function. Mar 1, 2023 at 10:49
  • @FrankP.Walentynowicz Thanks for the suggestion, I've tried with wp_die() and also with wp_send_json() but the error keeps occurring
    – LS_
    Mar 1, 2023 at 15:52

1 Answer 1


I've found this question which describes the same issue i'm facing. The accepted solution didn't work for me, but after a bit more research I've found this solution from WPML.

I've noticed that after calling the endpoint the .htaccess was getting rewritten, this part:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteRule ^en/wp-login.php /wp-login.php [QSA,L]
RewriteRule ^fr/wp-login.php /wp-login.php [QSA,L]
RewriteRule ^de/wp-login.php /wp-login.php [QSA,L]
RewriteRule ^it/wp-login.php /wp-login.php [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
Options -Indexes

gets rewritten as:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /it/
RewriteRule ^index\.php$ - [L]
RewriteRule ^en/wp-login.php /it/wp-login.php [QSA,L]
RewriteRule ^fr/wp-login.php /it/wp-login.php [QSA,L]
RewriteRule ^de/wp-login.php /it/wp-login.php [QSA,L]
RewriteRule ^it/wp-login.php /it/wp-login.php [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /it/index.php [L]
Options -Indexes

After applying the suggested solution from WPML:

add_filter('mod_rewrite_rules', 'fix_rewritebase');
function fix_rewritebase($rules){
    $home_root = parse_url(home_url());
    if ( isset( $home_root['path'] ) ) {
        $home_root = trailingslashit($home_root['path']);
    } else {
        $home_root = '/';
    $wpml_root = parse_url(get_option('home'));
    if ( isset( $wpml_root['path'] ) ) {
        $wpml_root = trailingslashit($wpml_root['path']);
    } else {
        $wpml_root = '/';
    $rules = str_replace("RewriteBase $home_root", "RewriteBase $wpml_root", $rules);
    $rules = str_replace("RewriteRule . $home_root", "RewriteRule . $wpml_root", $rules);
    return $rules;

I can see that the values for RewriteBase / and RewriteRule . /index.php [L] don't get updated anymore and the Internal Server Error disappears.

In my case I guess the issue was caused by developing the website in a language and then changing it and transferring the website. I'll contact WPML to let them know about the issue, also I still don't get what's causing the rewrite of the .htaccess after calling the endpoint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.