Viewing 4 replies - 1 through 4 (of 4 total)
  • Hi!

    Ok, this one is interesting.. InstantClick will only load on the front-end, so you should normally be fine in the admin. However, if you find your way to wp-admin via the front-end (through the admin-bar for example), InstantClick will continue to do its work there – and eventually crash the comments admin. The only way to stop this, really, is by disabling InstantClick for admin pages.

    The real issue will be finding a solution that doesn’t involve extra code loaded for non-logged in users.. this one is something to think about for the future.

    Thanks!
    Mike

    Mike, I was about to report the same problem when going into admin following an edit_post_link.

    Determining if user is logged in couldn’t be easier, see is_user_logged_in.
    The thing is what do we do next…

    Thanks @kalligator.

    Disabling InstantClick altogether for logged in users would be the simplest solution, I see 2 problems though:
    1. It creates a different experience for the admin and the end user – making incompatibilities with InstantClick invisible for logged in users (opening the door to “But it works for me” bugs)
    2. It will also disable InstantClick for membership sites, like ecommerce websites where logged in users never even see wp-admin.

    What do you think?

    Valid points, caching plugins mostly follow this strategy as well by default i.e. do not serve cached content to logged-in users.
    I can see this as an option in the plugin prefs.

    How about stopping the pre-rendering on links that contain the wp-admin string?

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Admin crash’ is closed to new replies.