{"id":24551,"date":"2020-08-24T11:09:34","date_gmt":"2020-08-24T15:09:34","guid":{"rendered":"https:\/\/docs.gravityforms.com\/?p=24551"},"modified":"2025-02-12T10:36:39","modified_gmt":"2025-02-12T15:36:39","slug":"conflict-testing-using-health-check-plugin","status":"publish","type":"post","link":"https:\/\/docs.gravityforms.com\/conflict-testing-using-health-check-plugin\/","title":{"rendered":"Testing for a Theme\/Plugin Conflict using the Health Check & Troubleshooting Plugin"},"content":{"rendered":"\n

Introduction<\/h2>\n\n\n\n

Gravity Forms uses WordPress and software development best practices to make our products as compatible as possible with other plugins and themes. However, some we cannot guarantee the same from third party software, and the sheer variety of plugins and themes out there means that in lots of cases, an issue with a form can be whittled down to a conflict with a third party product. This guide provides instructions for determining if an issue you are experiencing with Gravity Forms may be caused by a theme or plugin conflict, and is often a required first step for a new support ticket.<\/p>\n\n\n\n

For most conflicts you can use the WordPress.org community official Health Check & Troubleshooting<\/a> plugin.<\/p>\n\n\n\n

This plugin allows you to disable other plugins and switch your site to a default WordPress theme, only for the current logged in user<\/strong>, therefore allowing you to perform the testing without affecting your visitors (or other logged in users).<\/p>\n\n\n\n

Quickstart Guide<\/h2>\n\n\n\n
    \n
  1. Backup your site.<\/li>\n\n\n\n
  2. If the form is currently embedded using a third-party builder or modal popup, put it on a test page using the WP default editor.<\/li>\n\n\n\n
  3. If you’re using caching or JavaScript optimizations, turn them off.<\/li>\n\n\n\n
  4. After the above, if the issue persists, install and activate the Health Check & Troubleshooting<\/a>.<\/li>\n\n\n\n
  5. Enable the Troubleshooting mode, starting with only Gravity Forms enabled.<\/li>\n<\/ol>\n\n\n\n

    Before you start<\/h2>\n\n\n\n

    A backup is always advised<\/h3>\n\n\n\n

    Although using the Health Check & Troubleshooting plugin is generally trouble-free, it is advised to create a backup of your WordPress<\/a> as good practise. Because you know what will happen the one time you forget this step…<\/p>\n\n\n\n

    If using a third-party builder or modal to embed the form<\/h3>\n\n\n\n

    For the troubleshooting, you will want to create a test page, to embed your form directly using the WordPress form editor, without<\/strong> third-party builders or modal solutions.<\/p>\n\n\n\n

    Both WordPress Classic Editor<\/a> and Gutenberg<\/a> are supported.<\/p>\n\n\n\n

    If the page is being cached or minified by a plugin or hosting company<\/h3>\n\n\n\n

    Caching and automatic JavaScript optimization techniques have been known to cause issues with plugins and even core WordPress features. It’s great to cache static pages to speed up loading times, but caching dynamic pages where you do changes often is not always a good practice. additionally, trying to automate the optimization of the scripts on the page without knowing each script’s needs is a possible way to break JavaScript related features.<\/strong><\/p>\n\n\n\n

    So if your page is being cached or using any JavaScript related optimization done by a plugin, a CDN (e.g. CloudFlare, Sucuri, KeyCDN, etc) or your host using an internal proxy, Varnish, Redis object cache or any other caching engine, make sure to flush the cache and turn off caching and JavaScript optimizations completely during testing<\/strong>. Failure to do this can create false positives due to cached resources or the optimizations done.<\/strong><\/p>\n\n\n\n

    Below you can find links with directions on how to exclude pages from most popular caching solutions:<\/p>\n\n\n\n

    <\/p>\n\n\n\n