Nothing has changed within Gravity Forms in the latest release that would cause behavior like this.
Typically when you encounter an insecure content error message it's caused by a script, styles or images being loaded via http:// instead of https://. If you view source on that page and search for "gravityforms/" (without the quotes) you will see that all of the Gravity Forms related resources are being loaded via https:// and therefore are not going to trigger an insecure content error as you have described.
The fact that it is sporadic leads me to believe something else is going on with your site anyway because the forms aren't going to execute sporadically. The forms are going to execute the same way each and every time.
I took a look at the page you provided the URL to and did a quick search for everything being called via http:// and not https:// which would cause an issue with the SSL and you have other content on the page that is being called insecurely. See this screenshot:
https://skitch.com/carlhancock/854gg/view-source-https-www.aandaupdate.com-register
You have WordPress.com related analytics tracking script that is being called via an http:// call which means it's loading insecure content on a secure page and could trigger the browser to display the message related to insecure content being loaded.
I also noticed that you are using page caching with WP Super Cache. That could contribute to the sporadic nature of the issue you are encountering and contribute to sporadic issues that are difficult to track down because caching can cause confusion.
I would suggest NOT using page caching on a page containing a Gravity Form. Because the page is being cached that means if you make changes to the form, they won't be apparent right away. Page caching can also cause issues with the forms ability to interact with your database.
You must be very careful when implementing page caching. It should only be used in situations where the page interaction is 100% static. Forms by their very nature are not static. They dynamically communicate with your WordPress database and caching plugins can prevent this from happening reliably.
Posted 12 years ago on Tuesday May 22, 2012 |
Permalink