Skip to:
Content
Pages
Categories
Search
Top
Bottom

[Resolved] BuddyPress kills my 3.5 upgrade

  • @lwaltzer

    Participant

    I’m running a large wp multisite, with shardb, and when BuddyPress is activated I get a fatal memory error and white screen across the install. I originally thought this was an issue with a parameter 2 error shardb was throwing, but we fixed that and the issue persists.

    I was able to get the front page to load by massively increasing wp memory limit via define(‘WP_MEMORY_LIMIT’, ‘8192M’); in wp-config, but can’t get any other BP pages to load or admin pages to fully load (just get left sidebar in dash).

    I have confirmed this is the case when no additional plugins or themes (beyond the default) are on the system. (Attempting to run) latest version of BP. As soon as I remove, the install is fine.

    Only error being thrown by debug is “Notice: define() was called with an argument that is deprecated since version 3.0! The constant VHOST is deprecated. Use the boolean constant SUBDOMAIN_INSTALL in wp-config.php to enable a subdomain configuration. Use is_subdomain_install() to check whether a subdomain configuration is enabled. in /var/www/html/wp-includes/functions.php on line 2908”

    Anyone have suggestions for additional troubleshooting? All suggestions/queries welcome.

Viewing 4 replies - 1 through 4 (of 4 total)
  • @hnla

    Participant

    PHP Script Memory limit is there for a very particular reason, it’s set as a limit  to ensure that no script running on the server can end up consuming all the main system memory and thus crashing your whole server, setting what you have suggests all of your machines main memory and you may well run into issues, 128M or 256M should be more than enough to run WP/BP.

     

    I would also not trust to setting this php config from WP check what is actually set using phpinfo()

    @lwaltzer

    Participant

    Yeah, I realize all that. It was a temporary step. In php.ini it’s 128m and it’s been fine. This just helped me figure out where the problem lay if not how to solve it.

    @lwaltzer

    Participant

    @boone figured this out for me, and hacked together a fix which I’ve pasted below.

    `

    $dbv ) {
    if ( ‘get_blogs_of_user’ == $dbv[‘function’] ) {
    $is_get_blogs_of_user = true;
    break;
    }
    }

    if ( $is_get_blogs_of_user ) {
    // Get the real metadata, but don’t recurse
    remove_filter( ‘get_user_metadata’, ‘bbg_admin_bar_hack’, 10, 4 );
    $meta = get_user_meta( $object_id );
    add_filter( ‘get_user_metadata’, ‘bbg_admin_bar_hack’, 10, 4 );

    // How many blogs does this user have?
    static $blog_count_of_user;
    if ( ! isset( $blog_count_of_user ) && is_user_logged_in() ) {
    $blog_count_of_user = 0;
    foreach ( $meta as $mk => $mv ) {
    if ( ‘capabilities’ === substr( $mk, -12 ) ) {
    $blog_count_of_user++;
    }
    }
    }

    // We only care about those with counts > 75
    if ( $blog_count_of_user > 75 ) {
    static $clean_keys;
    if ( isset( $clean_keys ) ) {
    return $clean_keys;
    } else {
    foreach ( $meta as $mk => $mv ) {
    if ( ‘capabilities’ === substr( $mk, -12 ) ) {
    unset( $meta[ $mk ] );
    }
    }

    $clean_keys = $meta;
    return $meta;
    }
    }
    }

    }

    return $check;
    }
    add_filter( ‘get_user_metadata’, ‘bbg_admin_bar_hack’, 10, 4 );

    `

    @lwaltzer

    Participant

    Oops. Trying again:

    /**
    * In WP 3.5+, get_blogs_of_user() is much slower than in previous versions. As
    * a result, if you have a certain number of blogs, running get_blogs_of_user()
    * will create a memory timeout. This is a particular problem because
    * get_blogs_of_user() is called on every page, because of the toolbar.
    *
    * Ideally, there would be a way to short-circuit get_blogs_of_user(), or even
    * to prevent WordPress from calling get_blogs_of_user() while loading the
    * toolbar. But there is not. As a workaround, this function intercepts a key
    * step in get_blogs_of_user() – the get_user_meta() call that gets all of a
    * user’s metadata. If we determine that this request is coming from
    * get_blogs_of_user() (which we do by examining the debug_backtrace(), a truly
    * awful technique), AND that it’s one of the generic meta queries used by
    * get_blogs_of_user(), AND that the current user has more than 75 blogs, THEN
    * we strip all of the blog capability keys from the array of metadata,
    * tricking get_blogs_of_user() into thinking that the current user has no
    * blogs at all.
    */
    function bbg_admin_bar_hack( $check, $object_id, $meta_key, $single ) {
    // Only fire when looking at get_user_meta() with no params
    if ( ! $meta_key ) {

    // check to see whether this came from get_blogs_of_user()
    $db = debug_backtrace();
    $is_get_blogs_of_user = false;
    foreach ( $db as $dbk => $dbv ) {
    if ( ‘get_blogs_of_user’ == $dbv[‘function’] ) {
    $is_get_blogs_of_user = true;
    break;
    }
    }

    if ( $is_get_blogs_of_user ) {
    // Get the real metadata, but don’t recurse
    remove_filter( ‘get_user_metadata’, ‘bbg_admin_bar_hack’, 10, 4 );
    $meta = get_user_meta( $object_id );
    add_filter( ‘get_user_metadata’, ‘bbg_admin_bar_hack’, 10, 4 );

    // How many blogs does this user have?
    static $blog_count_of_user;
    if ( ! isset( $blog_count_of_user ) && is_user_logged_in() ) {
    $blog_count_of_user = 0;
    foreach ( $meta as $mk => $mv ) {
    if ( ‘capabilities’ === substr( $mk, -12 ) ) {
    $blog_count_of_user++;
    }
    }
    }

    // We only care about those with counts > 75
    if ( $blog_count_of_user > 75 ) {
    static $clean_keys;
    if ( isset( $clean_keys ) ) {
    return $clean_keys;
    } else {
    foreach ( $meta as $mk => $mv ) {
    if ( ‘capabilities’ === substr( $mk, -12 ) ) {
    unset( $meta[ $mk ] );
    }
    }

    $clean_keys = $meta;
    return $meta;
    }
    }
    }

    }

    return $check;
    }
    add_filter( ‘get_user_metadata’, ‘bbg_admin_bar_hack’, 10, 4 );

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘[Resolved] BuddyPress kills my 3.5 upgrade’ is closed to new replies.
Skip to toolbar