Debugging faulty Ajax loading/navigation

[Riccardo]

Hi there guys,
I don’t know why but while developing the website, sometimes the month view navigation will stop working with the usual stuck spinning wheel (IE11, Firefox, Edge, Chrome Android) and the mini calendar widget on all browsers.

Out of disabling functions.php in my theme, disable my custom javascript and reverting to default WP theme (with all the plugins activated), only the last attempt worked.

So, it looks like there’s a theme conflict that under some circumstances will spoil ajax calls.

I would I ask you if you can instruct me to debug what’s going wrong with my theme!

I know how to use Chrome’s debugger and Firefox’s Firebug to debug javascript but I don’t know how to debug ajax calls. although I can clearly see XHR requests in FF and Chrome.

Currently there are no errors in the Console, so I really don’t know where to start and what route to follow.

Glad if you could help, hoping this behaviour is not related to PHP version 7 (As I wrote in older messages I cannot downgrade to PHP 5).

At the moment I have posted another request to disable Ajax functionality to allow customers to use the calendar anyway, to allow proper debugging to fix this!

Thanks 🙂

[Brook]

Howdy again,

I figured I’d snap this topic since it seemed heavily related to your last one.

You are asking all the right questions here. Unfortunately debugging JavaScript can be a bit of a pain when there are no error messages. My go to tactic is to try renaming the JavaScript folder in my theme, then retesting to see if the conflict goes away. If it does rename it back, not try renaming each file inside there and retesting, until you narrow it down to one file that is conflicting. Now you have to run through that file trying to find the conflict. If you can share a copy of the file I’d love to lend an extra set of eyes as well, maybe something will stand out.

Glad if you could help, hoping this behaviour is not related to PHP version 7 (As I wrote in older messages I cannot downgrade to PHP 5).

Well no worries there, we would never want someone to downgrade from the latest version. We fully support PHP7. It’s doubtful though that this is related, it’s probably a JavaScript error.

Did that help, where you able to narrow it down to a file and possibly to something in that file?

Cheers!

– Brook

[Riccardo]

Brook! Once I thought that the problem was theme related, I have made another test, disabling the child theme (I am using a Child theme), and it works on all browsers.

So it is something in my child theme’s code that is spoiling Ajax navigation.
The strange part is that although I have activated again my child theme and renamed functions.php (this disables loading my custom js, shouldn’t it?) and style.css, the problem is there again.

There must be something elsewhere (I am using other customized php templates in the child theme) but I would bet there are no big modifications in there. Basically the large amount of customizations is made in functions.php, css and javascript files….

[Riccardo]

Hoooorrrraaaayyyy!!!!!

I have narrowed down the problem! This is the offending code in my child’s theme function.php

if (is_user_logged_in()){
    if (in_array( 'parent', (array) $acorn_user->roles )){
              show_admin_bar(false);
              add_action('admin_init', 'no_mo_dashboard'); 
        }else{
            show_admin_bar(true);
        }
}

// ********* parent cannot access dashboard 
function no_mo_dashboard() {
     wp_redirect(home_url()); // STOPS AJAX LOADING EVERYWHERE!!!!
 }

Now I have found a snippet that doeas a similar function:

add_action( 'init', 'blockusers_init' );
function blockusers_init() {
if ( is_admin() && ! current_user_can( 'administrator' ) &&
! ( defined( 'DOING_AJAX' ) && DOING_AJAX ) ) {
wp_redirect( home_url() );
exit;
}
}

Where there’s a test on Ajax…… Did I miss something? Why was my code blocking Ajax?

• This reply was modified 7 years, 7 months ago by Riccardo.

[Brook]

Excellent detective skills!

For some strange reason WP chose to store it’s Ajax API inside the WP Admin area. So any ajax calls load WP Admin. Any type of security layer that prevents access to WP Admin (without considering what the user is accessing) will break WP Ajax. Your new code checks to see if Ajax is happening, and if so allows the user access. This is most wise.

That make sense now? I am happy you got to the bottom of this.

Cheers!

– Brook

[Support Droid]

Hey there! This thread has been pretty quiet for the last three weeks, so we’re going to go ahead and close it to avoid confusion with other topics. If you’re still looking for help with this, please do open a new thread, reference this one and we’d be more than happy to continue the conversation over there.

Thanks so much!
The Events Calendar Support Team

[Author]

Posts