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.

Conflict with Buddypress 1.5.4

  1. Running Wordress 3.3.1 and Buddypress 1.5.4 (Both Unmodified)

    Whenever I click 'Add New' the page doesn't finish loading (WP Admin Bar Fails to appear)

    If I Disable Buddypress, 'Add New' page loads correctly and functions normally.

    Any Help Appreciated :)

    Posted 12 years ago on Wednesday February 22, 2012 | Permalink
  2. Hi guys any chance we can get you to have a look at this for us please, as we cannot use the the forms until we manage to get it resolved.

    I can provide login details etc.

    Cheers fellas :o)

    Posted 12 years ago on Sunday February 26, 2012 | Permalink
  3. UPDATE: With Buddypress activated it will render the Add New Page up to the point where it displays 'Standard Fields' it will not render from this point on.

    However with buddypress deactivated it will render the entire Add New page correctly.

    What would likely cause a conflict at that point?

    Cheers!

    Posted 12 years ago on Sunday February 26, 2012 | Permalink
  4. Richard Vav
    Administrator

    Have you updated gravity forms to 1.6.3 if you check the settings page they have added a new 'no conflict' option that will prevent your theme and other plugins from including CSS and js files on the gravity forms admin pages. You should enable that and see if it makes any difference.

    That said it could be a server resource issue, in which case that no conflict mode option won't make a difference.

    Posted 12 years ago on Sunday February 26, 2012 | Permalink
  5. Just tried that with no success.

    Thanks for the tip though!

    Posted 12 years ago on Sunday February 26, 2012 | Permalink
  6. Richard Vav
    Administrator

    It's sounding less like a plugin conflict and more like a server resource issue. If you have access to your hosting control panel I would check the performance logs for the times when you tried to access the gravity forms admin areas and see what your servers CPU and memory resource usage was at those times.

    Posted 12 years ago on Sunday February 26, 2012 | Permalink
  7. Host doesn't think its a resource issue.

    ------------------------------------------
    The default resource limits imposed on the Linux hosting platform are
    currently set to a maximum of 256MB of RAM and 1 minute of CPU time per
    user process. CPU time is measured in clock ticks, based on the CPU
    model, and will usually equate to more than 1 minute of real time.

    When processes hit these limits they are terminated by the kernel on the
    hosting servers. This will result in 500 errors being raised.
    -----------------------------------------

    Posted 12 years ago on Monday February 27, 2012 | Permalink
  8. I can confirm with 99% certainty after working with the dev team in the hosts that its not a resource issue, none of their monitors show any limitations being reached.

    They tell me its most likely a conflict at code level which is causing the script to stop rendering.

    9 Days in on this one, if anyone can help that would be great :o)

    Cheers!

    Posted 12 years ago on Friday March 2, 2012 | Permalink
  9. Hello Warren,

    I am replying here and I have also sent you an email after your forum posts were brought to my attention. Please note I don't always monitor the support forums personally so if you are working with me on a specific issue, please contact me directly.

    I wanted to follow up with you on this because I had in fact replied to your last Contact Us request and had requested additional information so we could take a look.

    The error related to rg_currency IS an issue and we have to take a look at your site and see why the error is happening. We don't have any other users reporting this issue so it's an issue related to your site install itself. It's usually something minor and if we can take a look we can determine what is going on pretty quickly and resolve it.

    I had replied to your last email via the Contact Us ticket you had submitted and requested an FTP login. You had supplied a WordPress admin login, but not an FTP login so we can do some debugging at the code level.

    I had not heard a response on my last reply so it appears you did not see it or receive it.

    We are more than willing to help you resolve this issue. It's not a matter of not wanting to refund your money, we'll spend more money in manpower working with you on this particular issue than what your Gravity Forms purchase cost. We just want to get it corrected so that it is working properly for you, that is what is important to us. If we can't get it corrected, we'll be glad to refund your money.

    If you can send over the FTP login we can take a look and quickly determine what exactly is going on.

    There are no known issues with BuddyPress compatibility and Gravity Forms so the issue is going to be something specific to your site which means we have to debug it on your site.

    Posted 12 years ago on Tuesday March 6, 2012 | Permalink
  10. The debug noticed you encountered weren't the cause of the issue, those were strictly warnings in debug mode and not errors. However, they have been resolved because I installed the latest version of Gravity Forms on your site. You were running an older version. Debug warnings (which aren't errors) can cause pages not to load, but only when debug mode is turned on... which it should not be turned on if it is a live site. It should only be used for testing and debug purposes.

    The issue isn't a conflict with BuddyPress, but it is related to server performance as well as client side browser performance.

    It's related to the fact BuddyPress makes heavy use of the WordPress users table to create users. The average WordPress site does not have hundreds, let alone thousands of WordPress users in the database. There are areas in the form editor where a drop down is returned that lists all of the users. The Post Author drop down in the Post Fields displays a drop down containing all of the users so you can select the Post Author when setting a default. Your server is choking on returning all of the users due to performance reasons.

    The easy fix is to use an available hook, the gform_author_dropdown_args hook, which is documented here:

    http://www.gravityhelp.com/documentation/page/Gform_author_dropdown_args

    This hook allows you to control what authors are returned in the Post Author field and in your case you want to use this to limit what is returned because you have so many users in your WordPress user table. You an use this hook so that it only returns users of a certain role, or you can use it to return specific user id's.

    Rather then edit your theme and add this custom code, because you are using a BuddyPress theme, I created a quick plugin that implements this hook. I called it Gravity Forms Limits Authors and it's installed and activated. It is currently limiting the users that appears in the Post Author drop down in the Post Fields to just the Administrator user. You can edit the plugin file and add other user id's if you need to change which users appear in that drop down.

    This isn't an issue that impacts just Gravity Forms. It's a common issue with WordPress sites that have thousands of users like you do and returns this list of users in elements such as drop downs, etc.

    It is resolved with the hook I implemented via a custom plugin.

    Be aware that if you switch to Formidable Pro you could get locked in to using their solution. We will be introducing an Add-On to allow users to display entry data as well as edit entry data and posts created using Gravity Forms later this year and it's going to be much more advanced than what Formidable Pro offers. We don't rush features like their developer does. We make sure they are well planned out from a feature, functionality and user interface standpoint and do a lot of testing. They treat things like it is a feature race and implement features as fast as they can... which includes constantly replicating features we introduce almost immediately after we introduce it.

    Posted 12 years ago on Tuesday March 6, 2012 | Permalink