PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

Theme javascript conflict

  1. Hi there, my name is Jared Henderson, I'm the lead developer of the ProPhoto theme, a premium theme -- . I'm posting here with Jeff Youngren's permission, he's one of your customers and one of mine.

    Gravity Forms is causing a javascript error on one of my theme admin pages. I can hack my way around it by adding an ugly patch to manually remove an action you've added, but I thought if I brought it to your attention you might be able to fix it on your end and save a lot of other plugin and theme authors from having the same issue.

    Basically, you add an action to "admin_print_scripts" to call your function print_tooltip_scripts(). There are two problems with how you do this:

    1) You do this in every single admin page. I would strongly suggest you test the global $pagenow variable, or add whatever other conditional logic you need so that you only run this function on pages where gravity forms is actually doing anything. I'm not sure what pages you need to run this on, but it's certainly not every page in the admin area. All of your extra javascript is getting loaded on all of my theme admin pages.

    2) You directly call wp_print_scripts() in the function print_tooltip_scripts() instead of just enqueueing the scripts you need and letting the WordPress "admin_head" or "admin_footer" actions output the scripts. Directly calling wp_print_scripts() there causes ALL enqueued scripts to be printed in the admin head instead of when they were enqueued to be loaded. To understand what I mean, I have enqueued a script to load in the footer. But, because you hook to an action that runs in the admin header and then directly call wp_print_scripts(), my scripts are getting printed in the admin header instead of the footer, and out of the order I intended them, causing a javascript error.

    I would love it if you would take just a few minutes to patch your plugin to a) not load your javascript on every single admin page, and b) not directly call wp_print_scripts() in the admin head area overriding the enqueuing location. This would help me and I'm guessing would automatically take care of a bunch of other potential plugin and theme conflicts.

    If you need to contact Jeff or myself, please do so. You can reach me directly at jared at netrivet dot com. Thanks! You're plugin is really slick, you guys are obviously really talented. I hope you're doing great business!


    Posted 8 years ago on Thursday October 6, 2011 | Permalink
  2. Thanks for your time!

    Posted 8 years ago on Thursday October 6, 2011 | Permalink
  3. Thanks Jared. It looks like we have some room for improvement here. I will take a look at it and see what i can do to get this conflict resolved.

    Posted 8 years ago on Thursday October 6, 2011 | Permalink
  4. I have removed the wp_print_scripts() call. It is unnecessary and I can see where it could cause problems. However, the scripts are not getting printed in every admin page. They are only being en-queued on Gravity Form's pages. The "admin_print_scripts" action is added in the tooltips.php file and that file is only included on Gravity Form specific pages.
    Maybe you (Jeff) is running an old version of Gravity Forms? If not, there might be something specific to your (his) installation that is causing these scripts to be printed on every page (those scripts certainly don't get printed on every page in my test environment). I would be glad to take a closer look and determine the cause of the problem if you send me an FTP and WP admin login to

    Posted 8 years ago on Thursday October 6, 2011 | Permalink
  5. Alex, thanks for your time making that change. I dug a little deeper and found why the scripts were being printed on every page and I don't think it's your fault. He's also running a plugin called "Gravity Forms ShootQ Add-On", which doesn't check the "is_gravity_pag()" method before requiring the "tooltips.php" file, which is causing my headache.

    I assume that's not your plugin?

    Posted 8 years ago on Friday October 7, 2011 | Permalink
  6. Alex, one more thought. Any chance you could make the RGForms::is_gravity_page() method public? Then, a derivative plugin like the one I mentioned above could call it before doing anything. It might make it easier for these plugins to avoid loading gravity stuff on incorrect pages.

    Posted 8 years ago on Friday October 7, 2011 | Permalink
  7. I am glad you figured it out! No, the ShootQ Add-On was not developed by us.

    Posted 8 years ago on Friday October 7, 2011 | Permalink

This topic has been resolved and has been closed to new replies.