Script above site html – prevents login

  • Resolved loushou

    (@loushou)


    9 years, 3 months ago

    Hey guys,

    Current, we are running version 2.0.0. We are using a theme by WooThemes called Canvas (pretty popular premium theme, that is very flexible); however, the problem I am about to describe happens even when using a core WordPress theme, or any other theme I have tried for that matter.

    The problem is that the following code is being rendered ABOVE the site html:

    <script type='text/javascript' data-cfasync='false'>var _mmunch = {'front': false, 'page': false, 'post': false, 'category': false, 'author': false, 'search': false, 'attachment': false, 'tag': false};</script><script data-cfasync="false" src="//s3.amazonaws.com/mailmunch/static/site.js" id="mailmunch-script" data-mailmunch-site-id="" async></script>

    So what I mean is that this happens:

    <script type='text/javascript' data-cfasync='false'>var _mmunch = {'front': false, 'page': false, 'post': false, 'category': false, 'author': false, 'search': false, 'attachment': false, 'tag': false};</script><script data-cfasync="false" src="//s3.amazonaws.com/mailmunch/static/site.js" id="mailmunch-script" data-mailmunch-site-id="" async></script><!DOCTYPE html>
<html>
  <head>
    <title>My-site</title>
  </head>
...

    To the naked eye, this does not seem like it could be a problem; however, it is a huge problem. The issue is really a two fold one. First, it is preventing the login cookie from being able to be set, which prevents login. Secondly, it is also preventing almost all redirects from working, because both the cookie and the redirect use basically the same mechanism.

    The login cookie normally gets set before any of the page is rendered. This is because the login cookie is set using a response header. All response headers must be sent to the browser before any html is rendered. Otherwise, you generate a PHP warning (usually logged in the error log in production environments), and the cookie is not set. Because the cookie is not set, the login redirect page is resulting in a whitepage that does not redirect to the admin.

    Secondly, when doing redirects the same exact process happens. WordPress uses a response header to tell the browser that it needs to redirect the request to a different url. Because your script tag is getting printed before WordPress expects it to print, you are interrupting the redirect header, just like the login cookie header.

    Thankfully, this is easily resolved. It seems that there is a small misunderstanding on your side, how the wp_enqueue_scripts action works or should be used. This action is meant only to setup the scripts that will be loaded on a given page, and then rendered later at the appropriate time. What you are doing is printing out the scripts you need in this step, instead of queuing them up for a later render, which is wrong. In this file: 

    constant-contact-forms-by-mailmunch/public/class-constantcontact-mailmunch-public.php

    you have the method enqueue_scripts(). That method hooks into the wp_enqueue_scripts action. This method needs to change in one of two ways.

    Option #1 – the WordPress preferred method

    Change your code to actually enqueue the script and it’s special settings, instead of printing it out directly in this method. You would need to leverage the wp_enqueue_script and wp_localize_script functions to do this properly. You can find a pretty straigh-forward, accurate example of how to do this on this github gist page.

    Essentially, your function should turn out something like this:

    public function enqueue_scripts() {
  $args = array(
    'front' => false,
    'page' => false,
    'post' => false,
    'author' => false,
    'search' => false,
    'attachment' => false,
    'tag' => false,
  );

  if ( is_front_page() || is_home() ) $args['front'] = true;
  if ( is_page() ) {
    $args['page'] = true;
    $args['pageData'] = $post_data;
  }
  if ( is_single() ) {
    $args['post'] = true;
    $args['postData'] = $post_data,
    $args['postCategories'] = get_the_category();
    $args['postTags'] = get_the_tags();
    $args['postAuthor'] = array( 'name' => get_the_author_meta( 'display_name' ), 'ID' => get_the_author_meta( 'ID' ) );
  }
  if ( is_category() ) {
    $args['category'] = true;
    $args['categoryData'] = get_category( get_query_var( 'cat' ) );
  }
  if ( is_search() ) $args['search'] = true;
  if ( is_author() ) $args['author'] = true;
  if ( is_tag() ) $args['tag'] = true;
  if ( is_attachment() ) $args['attachment'] = true;

  wp_enqueue_script( 'mailmunch-script', '//s3.amazonaws.com/mailmunch/static/site.js', array() );
  wp_localize_script( 'mailmunch-script', '_mmunch', $args );
}

    Now if the $siteID variable actually has a functional purpose, other than being a marker, then you will need to do a little research on how to get that added to the script tag. Despite that, this is how WordPress says you should be using the wp_enqueue_scripts hook.

    Option #2 – less preferable, but still workable

    The other option is to change the action that your printing your script stuff out on. If you must actually print out your script tags manually, due to some extraneous complication of requiring the $siteId var without a good way to add it to the wp_enqueue_script method above, then the proper action you should be using is wp_print_scripts. When wp_print_scripts runs, the header portion of the page is already in the process of being rendered. Thus, waiting until then will prevent your script tags from interfering with response headers, but will still allow your script to be loaded earlier enough to be useful.

    Hopefully you find this explanation comprehensive and informative as to what the problem is and how to fix it. I am sure you already had your own ideas on how to resolve it, but I figured I would include at least some hint in case you needed some guidance. And even more hopefully, this will lead to solutions that will help others as well.

    Let me know if I can provide any extra information that will help you resolve this,
    Loushou

    https://wordpress.org/plugins/constant-contact-forms-by-mailmunch/

Viewing 1 replies (of 1 total)
  • Plugin Author mailmunch

    (@mailmunch)

    9 years, 2 months ago

    Hi Loushou,

    Thank you so much for doing the research and explaining the problem in detail. We tried to use option #1 but passing custom attributes to a script tag using enqueue_scripts seems quite hacky so we have chosen a new option, instead of enqueue_scripts we’ll now use wp_head to echo our tags.

    What do you think about that?

Viewing 1 replies (of 1 total)
  • The topic ‘Script above site html – prevents login’ is closed to new replies.