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.

Gravity Forms Plugin Preventing Website from Loading

  1. Hello,

    I purchased Gravity Forms today to setup on our company website, but am unfortunately running into many problems with it...

    Firstly, I have installed the plugin to our test site, in order to resolve all the issues before pushing it to the live site. I have temporarily created a login/pass for you to access the test site and see what I'm seeing.

    Login: gravity
    Password: gravity

    This is the address to a page on the test site where I'm testing the plugin:

    When looking at all the problems, you can visit the live site at to see how things should be working. Anything with /test_site in the URL will bring up the test site. If you remove the /test_site, you'll go to the live site.

    You can see the same page as above on the live site at this address:

    The main problem is that when the plugin is implemented on a page, it appears to prevent much of the page from loading. In fact, it prevents functionality from loading across the entire website!

    Many functions are affected ranging from Cufon font replacement, to widgets loading, the top-side css menus become erratic, portfolio images don't load, our animated bullets are frozen, etc, etc. Most likely the page simply is not completely loading because something is crashing or conflicting. Like I said though, these problems occur site-wide when the form is implemented on a page.

    The particular page I'm using for testing this is not yet used on the site, so that's why its mostly empty. But you can easily see the many elements that are not loading properly.

    Some additional problems I'm encountering...

    Initially the form was inheriting CSS used by our list items. It was actually becoming a bulleted list. I was able to prevent that by implementing the CSS you posted in another thread for that problem.

    I noticed also that when adding certain items to a form, I would get an AJAX error preventing me from adding that item. This initially happened when adding the "Address" field. I then noticed it on other fields as well.

    At this point, this is preventing me from completing a major project. It's a big problem and I really need your help. I'd like to use Gravity Forms if possible, especially because I paid all the money for it. But at this moment I have serious concerns about it making our site unstable. If you can help me to pin-point the problems and resolve them asap, then perhaps we can use this. Otherwise, I'll be forced to abandon this plugin.

    I hope you can help!

    ~ Michael Samson

    P.S. If there is a way we can communicate more directly, such as via email, I would prefer that instead of a public forum...

    Posted 9 years ago on Thursday September 6, 2012 | Permalink
  2. On your test site, please enable WP_DEBUG in your wp-config.php file. We need to see the error or conflict which is causing the page to stop loading. Based on your symptoms, it's likely a jQuery or JavaScript conflict.

    We do not provide support via email. If you have a developer license, you have access to priority support. If not, then we will handle your support in these forums.

    You also have some additional markup being introduced to the Gravity Forms shortcode output. This is commonly added to themes where the [raw] shortcode is in effect. The work around is to wrap the gravityforms shortcode in the [raw] shortcode. That does not fix the problem, but will work around it. That is not the cause of all your problems though. If you have access to error logs, and/or can enable WP_DEBUG, we will be able to better help you.

    Posted 9 years ago on Thursday September 6, 2012 | Permalink
  3. Hello,

    Thank you so much for replying this quickly. I didn't expect an answer after hours like this. It's appreciated, as I'd really like to work out these difficulties during the day tomorrow.

    I have no problem working with you through the forum if that's how you prefer. Frankly, I just appreciate the support and am glad you're able to help.

    As you asked, I have enabled the debug mode from within the wp-config.php. This very quickly brought up some information, most notably what appears to be a memory issue. I'd like to hear what you think of that for sure. This is a VPS platform, but if there is a memory problem, I can probably resolve it. I just need more insight from you on this.

    I agree, there are multiple issues occuring here. Hopefully we can work through them all.

    Regarding what you said about the shortcode output. At the moment I am simply calling the form via a manual shortcode.

    [gravityform id=1 title=false description=false]

    I can of course change this upon your recommendation if that's the problem. The form itself is also just for testing. I quickly threw in a few options. It's not a real form we're using.

    I need to be 100% confident that the website is completely unaffected by this plugin before pushing it to the live site. Earlier today the plugin shut down our live site briefly... scary. Can't let that happen again.

    I'll be here all day tomorrow to work with you on this.

    Thank you again for helping me!

    ~ Michael

    Posted 9 years ago on Thursday September 6, 2012 | Permalink
  4. Hello Again,

    This is my second post tonight, so please take a look above first...

    Well, some great news here. After seeing the memory limit error I decided to investigate if that was the cause of the problems. I checked the memory limit setting in my php.ini file that governs scripts, and low and behold it was set to 32MB. The error that was showing indicated a need for more than 32MB.

    So I went and increased the limit to 128MB, and that immediately solved the problems I was seeing. The page now loads properly, and as far as I can tell all of those problems were caused by the lack of memory. I should have figured it was something fundamental to affect so many things.

    I had read online that the WordPress core prefers a 32MB memory limit, but that doesn't take into account lots of plugins. I think adding Gravity Forms kind of pushed our site over the edge. It simply needed more memory.

    At this point I'd like to now ask you to take a look at the test site again, and see if the plugin is running properly. I have left the debug mode turned on for you. There still may be some additional problems to take care of... things that only you would notice.

    Looks like this may workout afterall...

    ~ Michael

    Posted 9 years ago on Thursday September 6, 2012 | Permalink
  5. We find that 128MB of RAM works well with multiple large plugins and many themes. I'm glad that seems to have taken care of most (of not all) of your issues.

    The extra markup is a symptom of a larger problem on the site which WILL create problems in the future, with a date picker, conditional logic, or multi-page form. See this screenshot:

    The red highlighted </ p> and </ span> and </ div> (and the ending
    on lines 391-397) are not output by Gravity Forms, but by something on your site. A plugin conflict or functions.php functionality. Something on your site is processing the gravityforms shortcode output and adding that markup. You should attempt to resolve that to prevent problems with deployment on your live site.

    Most commonly, this is added by themes which have a [raw] shortcode. It can be called something else in individual themes, but the bottom line is that it changes the processing of all shortcodes, including Gravity Forms. The quick fix is to wrap your gravityform shortcode in the [raw] shortcode, like this:

    [raw][gravityform id=1 title=false description=false][/raw]

    If the [raw] text itself appears on your page, then your theme does not utilize the [raw] shortcode. Maybe it's called something else in your theme?

    If that works to prevent the additional markup, it's only masking the problem. The permanent fix is to remove that shortcode and the related function from your theme

    You can see how we solved situations similar to yours in the past by reading these related posts:

    Other than that, I think everything looks good. I was able to submit the form with no data, so you don't have any required fields, but it seemed to go through fine and I saw the confirmation message.

    Posted 9 years ago on Thursday September 6, 2012 | Permalink
  6. Hello Chris,

    Sorry it took me so long to get back to you today... had a late start. I can't thank you enough for looking everything over for me. Your insights have been on target each time.

    I was actually surprised to see the memory limit set so low. We don't have that many advanced plugins on the site, but are starting to gain more now that we have added Gravity Forms. Like I said earlier, it must have been that final straw.

    I looked at the piece of code you took the screenshot of, and saw the extraneous markup. That is frustrating to know that something else on the site is modifying shortcodes completely unlreated to it.

    I hadn't noticed it until I tried your suggestion with the [raw] shortcodes, but there was indeed extra space both above and below the form. That space was caused by the extra markup. You probably saw that.

    As you suggested, I wrapped the form shortcode with the [raw] shortcode. After doing this those extra spaces above/below the form did dissapear. I then viewed the source code, and saw much of that extra markup was gone.

    All of the
    tags at the ends of each line are gone, as are the 3 </p> tags you pointed out. However, this one line still has the </span> and </div> in it...

    <label for='input_1_1_6' id='input_1_1_6_label'>Country</label></span></div>

    I actually didn't know about the [raw] shortcode until now. Is this a shortcode built into all themes by default? Just curious if its default wordpress feature or not. It's going to be handy in the future...

    Like you said, this is just a work-around solution. If you don't mind, please take a look at the page again and see if the [raw] code is helping enough... and what its missing.

    I'd like to find out what plugin or code is modifying the shortcode markup in the first place, but cannot do this on my own. Do you know of a good way to pin-point the source of the problem? I'm open to any suggestions or help you can offer.

    At this point I am going to push this to the live site, but want to continue correcting conflicts. I'll also start building the form, which may reveal any additional issues.

    ~ Michael

    Posted 9 years ago on Thursday September 6, 2012 | Permalink
  7. I actually didn't know about the [raw] shortcode until now. Is this a shortcode built into all themes by default? Just curious if its default wordpress feature or not. It's going to be handy in the future...

    The raw shortcode is not standard on all themes. It is included in many Themeforest themes. I'm not sure what theme you started with or what code base you started with to create your theme. I would find the code that registers the [raw] shortcode and remove it. It's not good code. It's not core WordPress functionality either.

    To find the code, I would grep through all the theme and plugin files (the wp-content directory) for the word "raw" and see what comes up. You need to find and remove the function that registers the raw shortcode. After you remove the function, you won't need to wrap the [gravityforms] shortcode in the raw shortcode. If you do, the [raw] shortcode will just show in the page, not be processed.

    The source of your page looks fine now: no more extra HTML being added by any other plugin, that I can see.

    I would add a date picker, a textarea character limit, and some conditional logic to your form, and make it multi-page, just to see if there are any JavaScript conflicts before you go live. Test the most complicated form you will every need, with all the bells and whistles, just to make sure.

    Posted 9 years ago on Friday September 7, 2012 | Permalink
  8. Hi Chris,

    I must admit, you offer some of the best forum based customer service I've ever seen. Your responses are fast and detailed. My compliments to you!

    Earlier today I read many of the other forum topics relating to this problem. You had sent me a link to them. I saw all the posts about ThemeForest and their use of the raw shortcode. What a headache those themes have caused your team.

    Regarding the theme for DigitalRage... Well, we did actually start with a very basic theme when the site was first established. We have have been customizing and changing that theme ever since. At this point it barely resembles what we started with.

    Obviously the original theme had the raw shortcode installed. The question is why? If I am understanding this correctly, it's the raw shortcode itself that is causing the problem. It sounds like you're saying that the raw shortcode actually adds the additional markup. Is this correct? When I read about the purpose of the raw shortcode, it said it removes automatic formatting made be WordPress. But now I am confussed. Are you saying the additional markup is in fact from the raw shortcode itself?

    I can certainly look for the source of the shortcode and remove it. I'm quite good at locating code in the theme. I am a developer, just not so much back-end. I am more in between with my knowledge. But I can easily track down and remove that code.

    But if the raw shortcode is there, how do I know its not being used in parts of the site? I really need to understand better what its purpose is before removing it. Please do clarify this for me.

    You've been awesome, and I thank you for all the help and information. I'll keep you posted on our form implementation, and if anything else pops up. But for now I just want to get rid of this shortcode if it makes sense to.

    ~ Michael

    Posted 9 years ago on Friday September 7, 2012 | Permalink
  9. If you have never intentionally used the [raw] shortcode in a post, then I think you are safe. Sounds like you did not know it was there, so you were probably not using it at all. Removing the function is safe so long as you're not using it.

    You could search the wp_post table for instances of the word "[raw]" and ensure that it's not been used anywhere.

    Background: the function provided by the [raw] shortcode changes how all shortcodes are processed, every time a shortcode is processed, if you're using the [raw] shortcode or not. That's the reason is messes with all other shortcode output (all shortcode output is run through the wpautop filter, whether that was the intention of the shortcode provider or not). If you remove this function, you will remove the reprocessing of all shortcodes and won't have to jump through hoops to make sure the gravityforms shortcode output is unmolested.

    For way of background, I ran into the problem with this [raw] shortcode way back when I first started using Gravity Forms, and posted about it in March 2010, before I began helping in the forums. I've been dealing with it ever since. Here is the topic which started it all:

    If you have any more questions, please let us know.

    Bottom line: remove the shortcode function from the theme, and remove the line which registers the function.

    Posted 9 years ago on Friday September 7, 2012 | Permalink
  10. Hello Chris,

    Thanks for all the information...

    That is interesting that the Raw shortcode applies a filter to the output of all other shortcodes. No wonder it can have such a negative impact. But what is the purpose of those filters? Obviously they serve some sort of function / advantage, otherwise they wouldn't be installed in the first place. I'm very curious to know this.

    I decided to take your advice and hunt down the Raw shortcode. That took about 60 seconds, as it was in my "shortcodes.php" file, under the "functions" folder. In fact, it was practically the first code in that file.

    I knew I could easily comment out the code, and see if it had an impact on the site. So this is exactly what I did. I commented out the entire function, and then checked the website thoroughly. As far as I can see, nothing was affected. All the pages are loading identically, the formatting all looks the same, and no functions seem affected. Perhaps this was not in use at all. I even checked in the dashboard for changes... not knowing if this could only affect the front-end of the site. I saw no problems at all.

    After this I went and removed the raw shortcode from the Gravity Forms shortcode. Like you said, it was showing [raw] on the site since it was no longer being processed. After removing the raw code, the form looked perfect, and there was no additional markup as expected.

    At this point I think all my problems originally reported are solved. I only have three remaining questions...

    I noticed in the Raw shortcode I commented out that the "wpautop" filter was removed. Instead it was using a custom filter, "my_formatter". This was a little odd to me. I thought that perhaps this was actually being used. But like I said, after commenting this all out, there were no changes I could see on the site. So I thought I'd show you the code and see what you thought about it, and why it was there to begin with.

    Here it is...

    function my_formatter($content) {
        $new_content = '';
        $pattern_full = '{(\[raw\].*?\[/raw\])}is';
        $pattern_contents = '{\[raw\](.*?)\[/raw\]}is';
        $pieces = preg_split($pattern_full, $content, -1, PREG_SPLIT_DELIM_CAPTURE);
        foreach ($pieces as $piece) {
            if (preg_match($pattern_contents, $piece, $matches)) {
                $new_content .= $matches[1];
                } else {
                $new_content .= wptexturize(wpautop($piece));
    return $new_content;
    remove_filter('the_content', 'wpautop');
    remove_filter('the_content', 'wptexturize');
    add_filter('the_content', 'my_formatter', 99);

    This question is simple... Aside from this code you see above, is there any other code that also should be removed having to do with raw? I wasn't sure if there was another component somewhere, or if this was everything.

    Lastly, I did activate Gravity Forms on the live site yesterday, and am working on it now. It's for our new Careers section which is not yet live. But I can show you it if you're curious. I am still working on the form, but so far there are no problems. The form submitted beautifully and I'm having no problems in the dashboard either.

    Here is the link to the real implementation:

    You can see the form towards the bottom of this page.
    I am trying right now to figure out how to move certain fields to the right column. The name and address fields very nicely split things up into two columns automatically. I need to do the same thing with some of the other columns at the bottom of the form. This probably requires some custom CSS. If you know the best way to accomplish this, please let me know.

    Anyways, I know this was a lot to read, but I thank you for all your time and help. You really came through for me on this!

    Thank you again for everything!

    ~ Michael

    Posted 9 years ago on Friday September 7, 2012 | Permalink
  11. Hi Chris,

    I just wanted to add a few things to my above post... (please read that first)

    I've been working here on the form, and have now made it a multi-page form. Amazing feature by the way. It really helps to save on page space and makes the form less intimidating.

    I have been running into a few issues though...

    The first is that I have a conflict when applying conditional logic. If I apply any logic at all, the form simply will not load. There's obviously a conflicting script somewhere. At the moment I decided not to use the logic (trying to keep it simpler), but it would be nice to fix this issue.

    The other issue is concerning formatting...

    Ironically splitting the form up into multiple pages helped with the fact that not all fields could easily be set side by side (two column layout). I had asked you about this above. But I am encountering a more annoying issue. It seems that certain fields are ignoring the size setting. I have several fields (like on page 2 of my form) that are set to large, but will only display in medium. There is some kind of css issue here.

    Additionally, there seems to be no size setting for upload type fields. Those fields are displaying very small on my form. They only get larger if a larger size element is positioned above them (they expand). Otherwise, they are stuck small. There is no option for size on under the "advanced" tab.

    I really want my form to fill the entire space (left to right), so these sizing issues are frustrating me. This is an otherwise amazing form that has exceeded all my expectations.

    My compliments on your software. It is so easy to use and intuitive. I was able to use it immediately without reading any documentation. Amazing plugin.

    Anyways, I've posted so many things for you. But we are getting close! ;)

    ~ Michael

    Posted 9 years ago on Saturday September 8, 2012 | Permalink
  12. 1) That's typically how that [raw] shortcode works. (You can see where this code came from, #9 right here.) It removes the built in wpauotp function, and replaces it with its own my_formatter function. That is why the [raw] shortcode causes all these problems. Just remove the code, as you have done, and you'll be fine.

    2) I would search the shortcodes.php file for any instances of my_formatter, to be sure nothing else is calling that function. If you remove the function, and something tries to call it, you'll get a fatal error.

    For question 3 and beyond, please open a new topic as we have veered far from the original intention of this topic. I'll close this one, but feel free to copy and paste your replies into a new topic with a new title. Thank you.

    Posted 9 years ago on Saturday September 8, 2012 | Permalink

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