Skip to:
Content
Pages
Categories
Search
Top
Bottom

Forum Replies Created

Viewing 25 replies - 26 through 50 (of 3,925 total)
  • @r-a-y

    Keymaster

    Do you both have the Activity component disabled?

    If so, this is a bug. We’ve tentatively fixed this for the next release.

    However, you can temporarily apply the changes by by adjusting these files:
    https://buddypress.trac.wordpress.org/changeset/12185

    (Red means code removal, green means code addition)

    @r-a-y

    Keymaster

    What happens when you enqueue it? Does it work then? The next step is to figure out why the buddypress-nouveau JS is not being enqueued on the Site-wide Activity page.

    @r-a-y

    Keymaster

    The bug needs to be reproduceable on a fresh install of WordPress and BuddyPress.

    If you are able to replicate this bug there, then please list the steps it takes to duplicate the problem.

    It’s possible that you are using a plugin or custom code to change certain things. If that is the case, you need to disable all BuddyPress-related plugins and code snippets and then trying to reactivate each one to pinpoint what is causing the problem.

    @r-a-y

    Keymaster

    I just saw another thread about this.

    It looks like the bp-nouveau JS files are not being outputted in the footer.

    You can check to see if the buddypress-nouveau JS file is being properly registered and enqueued:
    https://buddypress.trac.wordpress.org/browser/tags/3.1.0/src/bp-templates/bp-nouveau/buddypress-functions.php#L296
    https://buddypress.trac.wordpress.org/browser/tags/3.1.0/src/bp-templates/bp-nouveau/buddypress-functions.php#L364

    Are you, by chance, filtering 'bp_nouveau_register_scripts' anywhere?

    @r-a-y

    Keymaster

    Sounds like the same problem as this report:

    Can’t Post in Activity Stream

    Unfortunately, we have been unable to determine the cause. Maybe you can help?

    If you are able to reproduce this problem on a fresh install of WordPress and BuddyPress, then please let us know so we can look into the problem.

    @r-a-y

    Keymaster

    It looks like you are using a plugin like BP Activity Plus due the fact that our activity post forms look different.

    Try disabling that.

    @r-a-y

    Keymaster

    Maybe just “don’t use oembed except for Youtube” type of hacking?

    BuddyPress just uses whatever oEmbed providers that WordPress uses.

    You can disable oEmbed providers in WordPress with code:
    https://codex.wordpress.org/Function_Reference/wp_oembed_remove_provider

    Hope that helps somewhat. The rest is up to you.

    @r-a-y

    Keymaster

    Check areas where your developer has either written a plugin or modified your BuddyPress templates in your theme (should be under /wp-content/YOUR-THEME/buddypress/ maybe.

    @r-a-y

    Keymaster

    Sounds like you should use a forum like bbPress (bbpress.org) instead of a profile-centric option like BuddyPress.

    @r-a-y

    Keymaster

    What does it say in the browser console’s Javascript tab?
    What does it say in the browser console’s Network tab for the AJAX request?

    Are any PHP errors logged if you enable WP_DEBUG in wp-config.php?

    @r-a-y

    Keymaster

    I’m not sure. Perhaps there is something being lost in translation in your description.

    Can you take screenshots or a GIF to demonstrate your problem? Perhaps it’s browser-related? Could also potentially be a plugin conflict.

    Here’s a quick GIF I took:

    GIF of mention

    Pressing on “Public Message” takes me to the Site-wide Activity page with the user’s mention name. I click inside the textarea and write something. Hover over the “Post Update” button and it’s the hand cursor. I click on “Post Update” and wait for it to post. It successfully posts (you can’t see the post because I didn’t increase the height of the GIF.

    This is in Chrome.

    @r-a-y

    Keymaster

    For me, it displays the hand icon and I’m able to submit the form after pressing on it. I’m testing with a WordPress default theme.

    Try switching your theme temporarily to see if you can duplicate your problem.

    @r-a-y

    Keymaster

    Sounds like you’re using a plugin because when you hit the “Public Message” button, it should take you to the Site-wide Activity page with the @-username pre-populated. The submit button is also named “Post Update” and not “Send”.

    Could also be something that your theme implemented. If so, try changing your theme to a WordPress default theme to see if the behavior is how I described.

    @r-a-y

    Keymaster

    BuddyPress doesn’t handle user deletion. We use the WordPress user API to remove the account.

    WordPress is in charge of removing data and they currently do not remove data from the wp_signups table when a user is deleted. Here’s a somewhat, related ticket:
    https://core.trac.wordpress.org/ticket/43232

    @r-a-y

    Keymaster

    BuddyPress cannot handle a different members slug for single profile pages.

    It might be possible via custom code, but is probably hard to implement. The easiest thing to do is remove the user slug entirely for user profiles, while keeping the Members Directory at users.

    You can remove the user portion of the member profile URL with the following code snippet in your theme’s functions.php or via a custom plugin:

    add_filter( 'bp_core_enable_root_profiles', '__return_true' );

    @r-a-y

    Keymaster

    BuddyPress does not do anything to the login page.

    You are using a 3rd-party plugin to manipulate the login page. Please use the support forum for that plugin for help.

    @r-a-y

    Keymaster

    Thanks for the thorough report, @jakdaniel5.

    I’ve filed a ticket here – https://buddypress.trac.wordpress.org/ticket/7938

    We’ll try to verify the issue internally. Once we can duplicate the problem, we’ll look to fix this up.

    @r-a-y

    Keymaster

    The BP ones are not dangerous.

    Your authenticity plugin just looks for anything using base64_encode(), which can be used for legitimate purposes. You’d have to audit the other plugins to determine if they are doing anything of mal intent.

    @r-a-y

    Keymaster

    The BuddyPress ones are false positives.

    @r-a-y

    Keymaster

    Please read the 3rd point in the sticky thread:

    BuddyPress 3.1.0 is now available!

    If you have replies to make, make them at the linked thread mentioned in the sticky.

    Closing to avoid forking the discussion.

    @r-a-y

    Keymaster

    I’ve added an answer to the thread you linked to.

    I’m closing this to avoid forking the discussion.

    @r-a-y

    Keymaster

    Got the answer for you.

    In v3.0.0, we conditionally load code depending on the page you are on.

    Since you are manipulating the default nav item, the screen code needs to be available before the call to bp_core_new_nav_default() is made.

    You can use the following code snippet in conjunction with the code snippet you are currently using until v3.2.0 is released to address this issue:

    add_action( 'bp_late_include', function() {
    	// Include Email screen code on Settings component and for default nav action (which is empty).
    	if ( is_user_logged_in() && bp_is_settings_component() && ! bp_current_action() ) {
    		require_once buddypress()->settings->path . 'bp-settings/screens/notifications.php';
    	}
    }, 11 );

    I’ve created a ticket here – https://buddypress.trac.wordpress.org/ticket/7935

    @r-a-y

    Keymaster

    If you have access to your server, you can rename the wp-content/plugins/buddypress folder to something else like wp-content/plugins/buddypress-bak, then reload the Plugins page or a frontend page and BuddyPress should deactivate.

    @r-a-y

    Keymaster

    I’ve created a ticket here – https://buddypress.trac.wordpress.org/ticket/7934

    Hopefully, some other contributors can duplicate the problem.

    @r-a-y

    Keymaster

    Sorry, I cannot duplicate this on a fresh install of WordPress 4.9.7 and BuddyPress 3.1.0, using Twenty Seventeen and launching the Customizer.

    Any steps to duplicate from a fresh install? What page are you attempting to launch the customizer from?

    If you want to help debug the uncompressed javascript, add the following to wp-config.php:

    define( 'SCRIPT_DEBUG', true );

    And note down the JS console message.

Viewing 25 replies - 26 through 50 (of 3,925 total)
Skip to toolbar