Hummingbird gravity forms conflict

The reCaptcha in Gravity forms aren't loading properly, and are throwing error once Hummingbirds Asset Optimzation is enabled in basic mode. When Asset Optimization is disabled captcha loads fine.

It's working fine once switched to advanced mode in Asset Optimization, and moving the file "gform_recaptcha" to the footer.

However, could notice many sites with different themes enabled having the same issue out of the box once Asset Optimization is enabled, so have to make the same changes in every site manually each time.

Is there any fix that could be applied within the plugin side to make this work out of the box?

  • Dimitris

    Hello there theProduct

    I trust you're doing good today! :slight_smile:

    I tried to replicate in a local site of mine, using solely WPMUDEV Dashboard, HummingBird's Asset Optimization, GravityForms (v.2.3.4.1) and a default theme (TwentySeventeen).

    I didn't have to make any change in Asset Optimization:

    and the reCaptcha continued to work without any problem/error:
    https://monosnap.com/file/LHDZKFfRVZ7oAmJTHXN6lPBrwYJ2Q7

    This should be an issue caused by another plugin or active theme. As Asset Optimization is all about the loading assets of an installation though, we can only further investigate this site-by-site, so we could find what's causing that, or simply use the "footer" workaround via Advanced Mode in Asset Optimization, like my colleague Nithin proposed during your live chat session.

    Warm regards,
    Dimitris

  • theProduct

    Hi Dimitris

    The frustrating thing I've found with this particular bug is that it isn't consistent.

    If it always broke reCAPTCHA all the time, I'd have narrowed things down a while back - but it's way more inconsistent.

    Here are a few of the sites we've run into the problem on recently:

    https://portcityair.com.au
    https://rockhamptoncoolingshop.com.au
    https://www.cleangetaway.com.au
    https://www.workplacecentral.com.au
    (there have been plenty more - I just can't think of any right now, hehe)

    ... and I say "recently", because we were using both Hummingbird and GravityForms on these sites without issue (and without making the footer change) before reCAPTCHA just started dying on us. Previously, not knowing what caused the problem, I would just remove reCAPTCHA for a week or two, then try adding it back again... and it would normally be all well and good (just as it was before it randomly died). Then, at some point down the road, reCAPTCHA would fall over again.

    Why? I have no idea. They're all running on CloudFlare, but having the site in development mode doesn't seem to have an impact on it, so I'm not sure if that is a potential influence.

    Either way, moving the gform_recaptcha page to the footer instantly fixed the problem on the 2 sites I tested it on (port city and rockhampton), and I was planning on testing it on Clean Getaway and Workplace Central next week. Hopefully, it "stays" fixed - and doesn't come back to haunt me randomly in a few weeks time - but we'll deal with one problem at a time, haha.

    Cheers,
    Adam.

  • Dimitris

    Hello there theProduct,

    hope you're doing good today and really appreciate the feedback on this! :slight_smile:

    Please keep in mind that when you're making even one change in Asset Optimization, you should visit your homepage in order to trigger the corresponding internal procedures, which will create the new asset files that your installation will use instead, based on your settings. This will require some time, depending on the number of assets and the server power of course. After 1-5 minutes you should be getting the results of the newly created asset files from HummingBird.

    Any change in the plugins or theme, can result to updated assets, so whole Asset Optimization tuning should be done again. I know that this is more of a trial and error job, but that's what will ensure you that your settings don't break anything in frontend.

    Also enabling Asset Optimization module, but not activating any action (compress, combine, push to footer etc) for any file, won't reduce the server time/load at all though. So in case you don't make any fine tuning there, you can better disable it altogether.

    As I wasn't able to replicate such issue, it should be something that's causing that, either in:
    - Google's end (just make sure that the API keys in use are connected to the corresponding domain name)
    - some specific setting or build or even conflict that's missing from us
    - some change in the assets files which result to broken pages, as explained above around Asset Optimization

    As for Cloudflare, I don't think that it could involve on this, especially after you testing it under the "development mode" which surpasses any caching or whatsoever by their end.
    Either way, I believe that the safest solution would be to force the aforementioned JS file to footer, as it will ensure that reCaptcha will continue to work no matter what.
    As for further looking into it, I think the best thing would be to create a staging/testing site, don't push reCaptcha file to footer and try to replicate the error. Then you can perform a conflict test or compare settings with the live (working) site.

    Hope that was some help!
    Take care,
    Dimitris

    • theProduct

      Also enabling Asset Optimization module, but not activating any action (compress, combine, push to footer etc) for any file, won't reduce the server time/load at all though. So in case you don't make any fine tuning there, you can better disable it altogether.

      Ooohhh.... I thought if I just enabled it and didn't touch anything, it was like W3 Total Cache's "Automatic" minification setting, where it just automatically tried to optimise things (thus the giant scan).

      If its an entirely manual process, that really throws a spanner in the works, as that's something I'm certainly not comfortable having our less technical staff manage as part of a run-up procedure.

      This is really confusing/misleading though, as on the settings page for Asset Optimisation, it says:

      "Super-compress my files: Auto-enabled"
      "Enable WPMU DEV CDN: Host my files on the WPMU DEV CDN"

      This heavily implies something along the lines of 'Asset Optimisation is automatic unless you want to tweak and adjust manually by clicking advanced, then you can tweak what it otherwise does by default'.

      This topic now forks into a bit of a feature request... Automatic compression and minification option (like W3 Total Cache, Rocket, Autoptimize), haha.

      Side Note: This site (https://www.lionlandmarketing.com.au/), which uses a different theme again, was also encountering the same problem with reCAPTCHA. Putting the one file to footer resolved it.

      I'll see if I can a chance to setup a staging site to test things on (not sure when that will happen though), however I guess the priority is making sure Asset Optimisation is something that warrants use before trying to fix my specific issue with it. If it isn't helping sites in its current setup, I may end up just having to disable it for everything - thus avoiding the issue, but also losing out on potential performance optimisation :slight_frown:

      Adam.

  • Dimitris

    Hello Adam

    Ooohhh.... I thought if I just enabled it and didn't touch anything, it was like W3 Total Cache's "Automatic" minification setting, where it just automatically tried to optimise things (thus the giant scan).

    No, the giant scan is to fetch all assets that could be loaded in frontend pages (everything that's properly hooked in wp_enqueue_scripts() action).

    If its an entirely manual process, that really throws a spanner in the works, as that's something I'm certainly not comfortable having our less technical staff manage as part of a run-up procedure.

    You should be able to use at least the "compress" option for all assets. Some files may mention to you that's better to stay un-compressed though.
    Most possible issues are coming from "combine" and change of the loading order (with "footer" or "defer" actions), this part will need a trial & error procedure, but will bring you out the maximum of your setup.

    This is really confusing/misleading though, as on the settings page for Asset Optimisation, it says:
    "Super-compress my files: Auto-enabled"
    "Enable WPMU DEV CDN: Host my files on the WPMU DEV CDN"

    "Super-compress" is a premium feature, as you're a paying WPMUDEV member. When you select to "compress" an asset, this will be done in the best possible way.
    As a premium WPMUDEV member, you can also use our CDN service for the produced asset files. Let me further explain, when you make some changes (like "compress" all assets) and "save changes", HummingBird will start to create some new files (in this case, compressed) and serve these instead of original files. Enabling our WPMUDEV CDN service, all these files will be loaded from there instead, decreasing the server load of your website.
    More about our CDN: https://premium.wpmudev.org/cdn/

    This heavily implies something along the lines of 'Asset Optimisation is automatic unless you want to tweak and adjust manually by clicking advanced, then you can tweak what it otherwise does by default'.

    As mentioned on top, this will still require which assets you want to compress. Additional actions are inside Advanced Mode, as they require some trial & error testing.
    Reference: https://premium.wpmudev.org/docs/wpmu-dev-plugins/hummingbird/#chapter-4

    HummingBird used to have an automatic procedure in previous versions, but again it required some fine-tuning, especially when assets list was too long, due to large number of plugins. I believe that "compress" can be applied safely in most sites though, so you can start with that. Also "combine" should work well, so if you're not in a HTTPS/2 server, you can try this out too. This should be almost the same as W3TC. Then, for better control, you can fine tune by resolving any potential render-blocking issues by using the "move to footer" and "defer" actions.
    Reference: https://premium.wpmudev.org/blog/eliminate-render-blocking-issues-hummingbird/

    Warm regards,
    Dimitris

  • theProduct

    As a premium WPMUDEV member, you can also use our CDN service for the produced asset files.

    Righto. If we're already using CloudFlare (sometimes CloudFlare Pro, sometimes with Argo enabled) on a server configured with Railgun, is enabling the CDN option worth it or counter productive at this point? (speaking strictly from the standpoint of maximising performance and reducing loading times)

    HummingBird used to have an automatic procedure in previous versions, but again it required some fine-tuning, especially when assets list was too long, due to large number of plugins. I believe that "compress" can be applied safely in most sites though, so you can start with that.

    I've got someone going through all of our sites and enabling this as we speak. We'll see how it goes :slight_smile:

    Any word on whether the auto setting will be making a comeback?

    Also "combine" should work well, so if you're not in a HTTPS/2 server, you can try this out too.

    We use CloudFlare across the board, so this option is largely disabled for us.

    Then, for better control, you can fine tune by resolving any potential render-blocking issues by using the "move to footer" and "defer" actions.

    I think I'll reserve that for troubleshooting situations for now (read: angry recaptcha forms and such), haha.

    Thanks! :smiley:

  • Dimitris

    Hello there theProduct,

    hope you're doing good today! :slight_smile:

    If we're already using CloudFlare (sometimes CloudFlare Pro, sometimes with Argo enabled) on a server configured with Railgun, is enabling the CDN option worth it or counter productive at this point? (speaking strictly from the standpoint of maximising performance and reducing loading times)

    If you enabled HummingBird's CDN then assets will be loaded from our CDN instead of Cloudflare's. As shared above, we use StackPath for our CDN services, which is pretty fast. In order to compare these though, you should do some further tests using both alternatives and try to benchmark from different locations (as different locations will be served by different servers of the CDN service, despite which one you select to use).

    Any word on whether the auto setting will be making a comeback?

    Auto-settings isn't going to make a comeback, as this would break even more sites most probably and lots of time would be spent to revert that.

    Warm regards,
    Dimitris

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.