BuddyPress.org

I don’t believe that BuddyPress itself could be configured to do anything like this.

Are you using any other plugins that might perform redirects, or restrict access to content?

What’s your setting at Dashboard > Settings > Reading “Your Homepage displays”? I wonder if there’s something funny happening there.

> Could it be a problem in the generate button link function ?

It’s possible, but it’s definitely not a problem with BP in the most general sense. I’m looking right now at an installation that is running Twenty Seventeen, and the buttons in question are clickable. It *could* be that you have another plugin that is somehow modifying the markup so as to make the buttons unclickable. Here’s what the markup for these buttons should look like (this specific example is the ‘Public Message’ button, but they are all similar):

<a href="http://example.com/activity/?r=username&_wpnonce=97df4e3389" class="activity-button mention">Public Message</a>

Does yours look similar to this? If not, then there must be a plugin or some JS interfering.

If possible, you could send me login credentials (my buddypress.org username @ gmail.com) so that I could see from a logged-in user’s point of view.

@852cmd Hm, that string – ‘Error! Please upload Profile Picture’ – doesn’t come from BuddyPress. This should be your clue: whatever code is generating that string is probably also doing the blocking itself. Try searching your codebase – including your theme – for this error message.

You can post a job here.

Have you read:

Customizing Labels, Messages, and URLs

Hi @ikipac – Do you mean you want to turn them off here on BuddyPress.org? Or on your specific BuddyPress installation? And by ‘notifications’ do you mean the email notifications, or the messages shown under the blue number near the top-right of the screen?

Email preferences are on the Settings panel of a BP profile. Here on buddypress.org, that’s at https://buddypress.org/members/ikipac/settings/notifications/

The screen notifications (behind the blue number) can be turned off on your own BP installation by disabling the Notifications component (Dashboard > Settings > BuddyPress). It’s not possible to disable this feature on your buddypress.org account.

Hi @chhayaparikh1963 – Thanks for the post!

I agree that the ability to post from the front end would be a good improvement for BuddyPress. It’s a bit complex to think about how it might be developed for BP itself, since it’s likely that many BP sites will want the feature implemented in different ways: limiting permissions to specific kinds of users, linking groups to sites within a multisite network, specific taxonomies for posts created from particular front-end contexts, etc. That being said, it’s something that’s long been on the radar of the BP development team. A recent ticket that outlines the issue is https://buddypress.trac.wordpress.org/ticket/6736

In the meantime, I know you said you have checked out all the third-party plugins, but I will say informally that I’ve had pretty good luck with BuddyForms. https://themekraft.com/buddyforms/

I wholly agree with the sentiments of the guy who posted this.

I think bbPress and BuddyPress are, frankly, appalling offerings to ordinary WordPress users.

They may well be excellent tools for developers, but they are the most user-unfriendly bits of software I have encountered in WordPress. Indeed, they make me wonder whether WordPress is for users anymore, rather than professional developers.

It simply should not be this complex, and dismally supported, to have a forum on WordPress.

I agree wholly with the view that there should be a premium paid-for service with a solution aimed at WordPress users – that is people who create editorial and run a site. Not the professional developers, who can look after themselves.

It does not surprise me that outfits like Wix are growing given this direction of WordPress. If it is for developers only – who hone their marketable skills doing this stuff – then fine.

For an ordinary user, who is not totally useless on WordPress, I have found this BBPress / BuddyPress combination utterly toxic and a waste of time.

The simplest answer is probably to style that span as display: block then you have a number of options for forcing it below other elements. It’s going to depend a lot on your theme.

If you choose to modify the template, the template to modify would go in child-theme/buddypress/members/member-header.php.

There are a few non-BuddyPress reasons I can think of for this:

• The page is cached by WP Super Cache or a similar plugin
• Your shared server has some sort of caching built-in (like object caching or expires headers)
• Your browser is using the cached version from your last visit to that page (try a different browser to test)

The setup you describe works ok for me on my local test (no caching enabled) installation. You might contact your hosting company to see what is enabled on your shared server.

hi,
bp_is_member() is not available in BuddyPress.

For your task, You should use
bp_is_user()

Hope that helps.

Regards
Brajesh

Hi @VentureCore-

It seems like you can make avatars work remotely. Check bp_core_fetch_avatar() for some filter opportunities. https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-core/bp-core-avatars.php#L98

I’ve not done what you’re trying to do, but it seems that the filter points bp_core_avatar_folder_url, bp_core_avatar_folder_dir could be useful, but there’s a filter on the final result at bp_core_fetch_avatar for the “html” output version and bp_core_fetch_avatar_url for just the url.

Cover images should actually be easier to manage. Take a look in https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-core/bp-core-attachments.php#L28

Alternatively, you could filter the other plugin to ignore avatar and cover image requests. Lots of ways to solve this, I’d bet.

I’d use BuddyPress Docs for this purpose, but I’m a fan of and contributor to that plugin. It’s great for creating organized shared libraries with tags and search ability.

If you’d rather it be more forum-like, use bbPress.

-David

What about using a custom member front page? Then you’d have total flexibility:
Custom Front Pages for your users profiles

Otherwise, I think you could conditionally filter bp_displayed_user_get_front_template to specify members/single/activity.php for self and friends and members/single/profile.php for non-friends. See this function:
https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-members/bp-members-template.php#L1397

Sure, I’m happy to point you in the right direction.

The BuddyPress Custom XProfile Field Type plugin is probably a good one to start with. It uses the BP_XProfile_Field_Type class to register its fields. It even has an existing Datepicker field that you can use as a starting place: https://github.com/donmik/buddypress-xprofile-custom-fields-type/blob/master/classes/Bxcft_Field_Type_Datepicker.php

There are a few changes you’ll need to make in order for this to show two datepickers instead of one.

– The set_format validation regex expects a single date. This will need to be modified for your new format. https://github.com/donmik/buddypress-xprofile-custom-fields-type/blob/1126cf093bd2b6e9f917b5c15f52e203f17cbb9e/classes/Bxcft_Field_Type_Datepicker.php#L14
– You’ll need to modify the edit_field_html method so that it loads two separate input fields, and then write some JavaScript that assigns a jquery-datepicker to each one of them. Then you’ll need to write a little bit of extra JS that combines the two datepicker inputs into a single (probably hidden) field, which is the one that BP will actually save to the database. https://github.com/donmik/buddypress-xprofile-custom-fields-type/blob/1126cf093bd2b6e9f917b5c15f52e203f17cbb9e/classes/Bxcft_Field_Type_Datepicker.php#L29
– If you decide to store the start and end date in a single row in the profile field, you’ll also need some logic that splits it into start and end when you load the edit_field_html. Another option is to store the concatenated display text – say, April 2017 - May 2017 – in BP’s native xprofile field, and to store the start and end date separately, as xprofilemeta. You’d need a custom save routine for this, but it may be a bit cleaner.

Good luck! Sounds like a fun project.

Regarding your first question, it appears that your theme is adding marks to your navigation menu. You’ll need to inspect the element to see what rule is causing it, then override it. (Or choose a different theme.)

Regarding your second question, if your theme has a full-width page template, select it for your BuddyPress pages. If it doesn’t you’ll have to create one, or choose a different theme.

As @shanebp notes, adding the tabs themselves is pretty straightforward. In addition to bp_core_new_nav_item() etc, you might also look into the more all-encompassing BP_Component class. See https://codex.buddypress.org/developer/bp_component/, https://codex.buddypress.org/developer/function-examples/core/bp_core_new_nav_item/.

It’s the content of these tabs that is likely to be more complex. If all you want is a series of links, it’s easy. But if you want a way for users to create content, you’ll need to build forms, storage methods, etc. For this, you might want to look into adopting an existing solution. The BuddyForms plugin is a pretty powerful starting place for this kind of thing: https://themekraft.com/buddyforms/

Hi @kevinc4m – The BuddyPress Followers plugin allows users on a multisite installation to follow specific sites: https://github.com/r-a-y/buddypress-followers

It sounds like this is not quite what you’re looking for – you want the ability to follow tags/categories, and it doesn’t sound like multisite is part of the equation – but this plugin may serve as a sort of inspiration for how the tag/category feature might work, at least in the UI. I also think that the plugin could probably be a basis for building the feature you’re looking for, as it does much of the work: storing user follow status, integrating items into user activity streams, and so on.

Unfortunately, I’m not aware of an existing tool that will do this without some customization.

Can you share the format of the “view content” links in the digest emails? (I’m assuming you’re using buddypress-group-email-subscription – let me know if that’s correct.) They should have a redirect_to parameter, but it sounds like it’s not being respected or is being lost somehow.

Are you using any plugins that interfere with the way that WP logins work? Perhaps Auth0 or another SSO plugin?

Hi @mycraze – It sounds as something is failing to load the jquery-cookie script. BP attempts to do it in the function bp_core_register_common_scripts(): https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-core/bp-core-cssjs.php?marks=54#L18

The first thing to check is to see whether the page is attempting to load the script in the first place. View the source of the page, and look for a tag that looks something like this, in the document head:

<script type='text/javascript' src='http://example.com/plugins/buddypress/src/bp-core/js/vendor/jquery-cookie.js?ver=2.9.2'></script>

If you *do* see this, but are still having the problem, try the following:

* Load the script URL directly in a new tab. Does it load?
* Open the Network tab of your browser’s developer tools. Is the browser unable to access the file for some reason? Perhaps a 404 or some other error?

If you do *not* see the script tag, then it’s a server-side issue. My guess, in this case, is that you are using a third-party theme that loads the bp-legacy JS file without also properly declaring the dependencies. To verify, switch to a default WP theme (like Twenty Sixteen) to see if the problem clears itself up. If this is the problem, you may want to talk to your theme author, or share the relevant code from the theme (probably looks like wp_enqueue_script...) and we may be able to help you correct it. In the meantime, you may be able to work around this problem by manually enqueing the cookie script in your functions.php file. Something like:

add_action( 'wp_enqueue_scripts', function() {
    wp_enqueue_script( 'bp-jquery-cookie', buddypress()->plugin_url . 'bp-core/js/vendor/jquery-cookie.min.js', array( 'jquery' ) );
} );

Hi @redcompolitica – I’ve built multi-page registration processes for clients in the past, but unfortunately, it’s not very easy to do – BP’s registration system is not built in such a way as to make it easy.

If your main goal is to make registration less overwhelming, you might consider moving some or most of your registration fields out of the “Base” group. This will mean that they don’t show up during the registration process, and users will have to fill them in by editing their profile after signing in.

If your goal is to have *conditional* registration steps – where, for example, step 2 depends on a specific value provided in step 1 – then I’m afraid it’d have to be custom-built. Much of the work could be done with a custom theme template members/register.php and by modifying the way that registration data is saved and validated https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-members/bp-members-screens.php?marks=113#L72

Some Trac tickets that are somewhat related that you might want to follow:
https://buddypress.trac.wordpress.org/ticket/1842
https://buddypress.trac.wordpress.org/ticket/4278

Good luck with your project!