Colin

Ok, sorry, I now realize that the FETCH_COOKIES_ENABLED constant is a custom created setting from the PDF Templates plugin. Below is how it is used in the plugin functions:

/**
 * Applies print templates
 */
add_action('template_redirect', '_use_pdf_template');
function _use_pdf_template() {
  global $wp_query, $pdf_post_types;

  if(in_array(get_post_type(), $pdf_post_types)) {

    if (isset($wp_query->query_vars['pdf-template'])) {

      // Substitute the PDF printing template

      // disable scripts and stylesheets
      // NOTE: We do this because in most cases the stylesheets used on the site
      // won't automatically work with the DOMPDF Library. This way you have to
      // define your own PDF styles using <style> tags in the template.
      add_action('wp_print_styles', '_remove_dep_arrays', ~PHP_INT_MAX);
      add_action('wp_print_scripts', '_remove_dep_arrays', ~PHP_INT_MAX);
      add_action('wp_print_footer_scripts', '_remove_dep_arrays', ~PHP_INT_MAX);

      // disable the wp admin bar
      add_filter('show_admin_bar', '__return_false');
      remove_action('wp_head', '_admin_bar_bump_cb');

      // use the print template
      add_filter('template_include', '_locate_pdf_template');

    }

    // our post permalink
    $link = get_the_permalink();

    if(isset($wp_query->query_vars['pdf']) || isset($wp_query->query_vars['pdf-preview'])) {

      if( defined('FETCH_COOKIES_ENABLED') && FETCH_COOKIES_ENABLED ) {

        // we want a html template
        $header = 'Accept:text/html' . "\n";

        // pass cookies from current request
        if( isset( $_SERVER['HTTP_COOKIE'] ) ) {
          $header .= 'Cookie: ' . $_SERVER['HTTP_COOKIE'] . "\n";
        }

        // create a request context for file_get_contents
        $context = stream_context_create(array(
          'http' => array(
            'method' => 'GET',
            'header' => $header,
          )
        ));

        // load the generated html from the template endpoint
        $html = file_get_contents($link . (strpos($link, '?') === false ? '?' : '&') . 'pdf-template', false, $context);
      }

      else {
        // request without cookies
        $html = file_get_contents($link . (strpos($link, '?') === false ? '?' : '&') . 'pdf-template');
      }

      // process the html output
      $html = apply_filters('pdf_template_html', $html);

      // pass for printing
      _print_pdf($html);

    }

  }
}

It is used to pass cookies into the header of the PDF template when it loads, so it can access the user info, etc.

So the question is still: why does this break when Awesome Support is installed/active?

That’s the part I’m not getting…

Any help you can provide is much appreciated. I would REALLY like to resolve this asap.

Thanks!

FYI:

After a grueling and frustrating wild goose chase, myself and the WP Engine hosting company have finally realized that the above

define('FETCH_COOKIES_ENABLED', true);

line in wp-config.php will break the PDF generation functionality if the Awesome Support wordpress plugin is active.

We have not discovered why yet, but have narrowed it down to that specific line in wp-config.php.

@antti Kuosmanen Any ideas why that line might cause this?

Hi again Julien,

Where would you recommend I start looking in order to troubleshoot the apparent conflict with the PDF Templates plugin?

I know you said that you tested the PDF Templates plugin with Awesome Support and that it worked for you, but for me, if I deactivate Awesome Support, the PDF plugin starts working again immediately. Then when I reactivate Awesome Support the PDF plugin stops working again (server request times out when I try to generate a PDF via the /pdf endpoint).

I’m not a very advanced developer, but it seems like there’s a very clear causal relationship between the Awesome Support plugin and the PDF plugin, and since the Awesome Support plugin works fine whether the PDF plugin is active or not says to me that it’s the Awesome Support plugin which is preventing the PDF plugin from working, and no the other way around.

How can I tackle this issue. I’ve already spent quite a few days integrating Awesome Support into my website and I would really like to avoid having to find and configure another support plugin.

If I were to purchase a premium addon for your plugin would it make it more worth your while to take a look at my site and see if you can figure out what is causing the conflict?

I could really use some help, even if you could just point me in the right direction for troubleshooting.

Thanks in advance!

– Colin

wpas_get_tickets_list_page_url() and wpas_get_submission_page_url()

Oh, ok, sorry for the misunderstanding. I assumed it only worked in one direction based on the email template tags for that one.

Good to know.

awesome! looking forward to it.

WordPress: Version 4.3.1
Awesome Support: Version 3.2.1
Wordpress PDF Templates: Version 1.3.9

FYI: I have made some very small customizations to the list.php and details.php templates and copied them into an awesome-support directory in my theme folder. But none of the customizations would effect the PDF plugin… I can’t see how they would.

My site is currently under construction. I could provide you with some creds if there is some way to privately send them to you…

I have a custom post type session-plan with a couple custom templates, single-session-plan.php and one-month-session-plans.php. For each of the custom templates I have created a custom PDF template, single-session-plan-pdf.php and one-month-session-plans-pdf.php respectively.

Before installing the Awesome Support plugin I was able to generate PDFs by navigating to the /pdf url endpoint for a single session-plan post, or for any page which had the one-month-session-plans.php template applied. No problems.

Once I installed the Awesome Support plugin, when I tried to navigate to the above mentioned /pdf endpoints, the request would time out after about a minute.

When I deactivated Awesome Support, the /pdf endpoints function properly and successfully generate the intended PDF.

I would LOVE if you were willing to check it out on my site. How can I get you login creds privately?

Hi again,

thanks for the response. I read through the youTube tracking docs and I think the issue is that my videos are dynamically loaded in a modal window, which is created when a user clicks a link/button. So basically the youTube video iframe is being added to the DOM after the clicky youtube.js file has already been queued, and the modal window html containing the youTube iframe is loaded at the very bottom of the page, right before the closing </body> tag.

Do you know if there is any additional documentation regarding the youTube clicky analytics? Like maybe a javascript snippet which could re-initialize the tracking script when new content is added to the DOM?

Thank you for any help!

– Colin

Thanks for the quick response!

I’ll keep an eye out for that update.

Will the new helper function for retrieving the Tickets pages be a publicly available function that I can use in my templates?

Thanks!

Wow! Thanks for the super fast response.

It’s quite strange, but the issue seems to have been isolated to the very first test ticket I submitted. Since then, none of the other test tickets have had the same formatting/sanitization issue.

So sorry sending you down what may have been a wild goose chase! I only realized later that the issue had gone away.

VERY STRANGE!

Thanks again for your awesome support!

@tareqhasan
Can you confirm whether the tracking pixel will fire once or twice when applied to a specific product? Re: Above.

Thanks.

Hi, I know this is an old thread, but I am having a similar issue. I’m using a plugin called MemberPress which can restrict access to pages and posts based on user “membership levels” (custom roles).

The above solution define('FETCH_COOKIES_ENABLED', true); certainly works, in that it gives the WP PDF Templates plugin access to the post content in order to successfully generate a PDF, but the problem is that anyone can access that PDF by navigating to the /pdf/ URL endpoint, even they do not have access to the post/page restricted content.

It would be quite easy to realize that all the restricted content is available if you just append the /pdf/ endpoint to any restricted page’s url.

Is there a way to prevent this kind of circumvention?

Let me know what you think. And thanks for the great plugin!

hmm… that sounds like the tracking code will fire twice. Am I understanding that correctly? I just want to be sure, because if it fires on the product page, as well as on the checkout page, then that would create 2 “conversions” instead of one.

@tareqhasan
+1

Could you please confirm the updated functionality in v0.3 ?

In the plugin’s change log you said this:
[fix] Product specific code only loads on product page itself, not checkout

But could you specify how you fixed that issue, and how we should now utilize the product-specific tracking pixel field?

My assumption is that, now, with the new update, any code/scripts that are input into the “Conversion Tracking Code” textarea field on a WC product edit page (in wp-admin), will be served or triggered/fired on the WC checkout endpoint ONLY if that particular product was purchased. Is this correct?

Also, does this mean that if a customer purchases several products in one checkout, 3 of which have product-specific tracking scripts, that all 3 of those tracking scripts will fire on the WC checkout endpoint?

Thank you for the clarification.

UPDATE:

I put a couple spaces and re-saved the hlt-bootstrapcss.php file in the plugin’s root directory. This apparently reset the plugin’s LESS settings, and allowed me to reload my site with your plugin activated.

I went back to the LESS settings and put my desired font into the @font-family-sans-serif variable field, this time with DOUBLE quotes, but when I hit Save Settings, I got the same result. Site crashed. Only saw white screen of death, and this is what my error log says:


[08-Dec-2014 02:07:00] PHP Fatal error: Uncaught exception 'Less_Exception_Chunk' with message 'ParseError: Unexpected input in variables.less on line 39, column 1
37| //
38| //## Font, line-height, and color for body text, headings, and more.
39| @font-family-sans-serif: \"Dosis\", sans-serif;
40| @font-family-serif: Georgia, \"Times New Roman\", Times, serif;
41| //** Default monospace fonts for <code>, <kbd>, and <pre>.
42| @font-family-monospace: Monaco, Menlo, Consolas, \”Courier New\”, monospace;’ in /home3/sustajd0/public_html/farandaway.adaptifydesigns.com/wp-content/plugins/wordpress-bootstrap-css/inc/Less.php/Parser.php:510
Stack trace:
#0 /home3/sustajd0/public_html/farandaway.adaptifydesigns.com/wp-content/plugins/wordpress-bootstrap-css/inc/Less.php/Parser.php(328): Less_Parser->GetRules(‘/home3/sustajd0…’)
#1 /home3/sustajd0/public_html/farandaway.adaptifydesigns.com/wp-content/plugins/wordpress-bootstrap-css/inc/Less.php/Tree/Import.php(265): Less_Parser->parseFile(‘/home3/sustajd0…’, ”, true)
#2 /home3/sustajd0/p in /home3/sustajd0/public_html/farandaway.adaptifydesigns.com/wp-content/plugins/wordpress-bootstrap-css/inc/Less.php/Parser.php on line 510

I don’t understand what’s wrong with line 39! It looks the same as line 40, doesn’t it?

Can you shed some light on what I’m doing wrong?