[@boonebgorges Keymaster 12 years, 9 months ago]

@brucedongcaigmailcom Right above // If nothing sticks, load a generic template.

[@boonebgorges Keymaster 12 years, 9 months ago]

BuddyPress doesn’t have a very straightforward way to add links like this to the Groups menu. By design, the links in the group nav are intended to correspond to sub-pages of the Group (which are created by BP_Group_Extension), rather than arbitrary external links.

That said, while we don’t have a very elegant way of making this happen, you could rig something up to directly insert the link data into the navigation array, just before it gets printed to the screen. Something like this:

function bbg_add_my_profile_to_group_nav() {
    // Logged-in users only
    if ( ! is_user_logged_in() ) {
        return;
    }

    // Bail if not looking at a group page
    if ( ! bp_is_group() ) {
        return;
    }

    buddypress()->bp_options_nav[ bp_get_current_group_slug() ][] = array(
        'name' => 'My Profile',
        'link' => bp_loggedin_user_domain(),
        'slug' => 'my-profile',
        'css_id' => 'my-profile',
        'position' => 9999999, // make it last
        'user_has_access' => true,
    );
}
add_action( 'bp_setup_nav', 'bbg_add_my_profile_to_group_nav', 100 );

Note that you can’t use the function bp_core_new_subnav_item() here, because you’re not registering a valid screen callback (among other reasons). Thus the hack of directly inserting the link into the nav.

Good luck!

[@boonebgorges Keymaster 12 years, 9 months ago]

Just to clarify the future of bp-default a little. It’s not being *abandoned*. It’s just not going to continue to receive new feature updates in the same way that it always has.

I know this can be a bit frustrating for those who have built child themes of bp-default. But the fact is that bp-default is several years old, and was really beginning to show its age. There is no practical way to update it as needed without breaking backward compatibility. So, instead, it’s going to live on as a legacy theme.

But bp-default will continue to be at least minimally maintained into the foreseeable future – if not by the BP core team, then by people (like me!) who have client sites running on it.

[@boonebgorges Keymaster 12 years, 9 months ago]

Another brief thought: You say that the Register component is linked at Dashboard > Settings > BuddyPress > Pages. But make sure that the linked WordPress page has its status set to Publish.

[@boonebgorges Keymaster 12 years, 9 months ago]

It’s weird that it’s appearing as blank. This could be the case of a failed redirect.

Make sure that registration is enabled on your site. On Multisite, go to Dashboard > Network Admin > Settings; you’ll see a set of radio buttons where you can select “Users can register” or something like that. On non-Multisite, go to Dashboard > Settings > General, and make sure that “Anyone can register” is checked. (What I suspect is happening is that you don’t have registration turned on. BuddyPress tries to handle this for you by redirecting people away from the Register page when registration is closed, but it could be that the redirect is failing because of something about your Windows setup. Just a hunch.)

[@boonebgorges Keymaster 12 years, 9 months ago]

The best way to ensure that a part of a template is only visible to a logged-in user who is viewing his own page is like this:

<?php if ( bp_is_my_profile() ) : ?>
    This is only visible to users viewing their own profiles
<?php endif; ?>

This is visible to anyone.

[@boonebgorges Keymaster 12 years, 9 months ago]

@cloudbuilder When you say “the comments”, do you mean *activity* comments? Or do you mean *blog* comments? Or do you mean the entire Activity page, as seems to be suggested by the original poster?

[@boonebgorges Keymaster 12 years, 9 months ago]

If you’re talking about the author icon on a *blog* post page, then it probably doesn’t have anything to do with BuddyPress – that’s handled by your WordPress theme. In any case, it’s likely that you’ll have to change it in a template file, or at least use CSS.

What theme are you using?

[@boonebgorges Keymaster 12 years, 9 months ago]

You should be able to convert your existing WordPress site to Multisite. Here’s the page from the WP codex: https://codex.wordpress.org/Create_A_Network

[@boonebgorges Keymaster 12 years, 9 months ago]

Did this just happen with your upgrade to 1.9.1 from 1.9, or were you upgrading from an earlier version of BP?

You mention you’re not using the regular WP toolbar. What are you using to power the Notifications dropdown from your screenshot? Is it custom coded?

[@boonebgorges Keymaster 12 years, 11 months ago]

@synaptic Thanks for starting this interesting discussion (and for doing it in a more sensible and measured tone than the linked article).

I agree that the current process for selecting and advancing features is not ideal. It is indeed a shame when a ticket like the CPT one gets punted release after release. I’m not sure that I can *justify* it, but I can *explain* it.

In brief, BuddyPress is maintained and developed by a small number of volunteers. (Contrast with WordPress, which has quite a large number of contributors, and a number of people who are paid to work exclusively on WordPress core as part/all of their day job.) So, the things that get developed during any given release are those things that the small number of volunteer developers have chosen to spend their time on. How do the developers choose? Personally, I tend to gravitate toward those items that fall into one or more of the following categories:

1. Items that other people have contributed code to, either in the form of an existing plugin, or a patch, or whatever. This is both because these items mean not starting from scratch, and because it validates those contributors’ time and effort. The new dynamic menu system (described here http://www.wptavern.com/buddypress-1-9-will-include-dynamic-menu-links) is a great example of this: community member imath contributed a very nice patch, so it got moved up in the list and will be part of the 1.9 release.
2. Items that someone is paying me to build anyway. I’m a consultant working on BP projects, and sometimes a client wants a feature that would be valuable in BP itself. If I’m not mistaken, the new notifications component for 1.9 is an example of this – jjj was working on it for a client, and so was much of the way toward having it ready for BP.
3. Low-hanging fruit. Often there are relatively easy tickets, something I can knock off in an hour or two.
4. Stuff I enjoy doing. There are some sorts of features I prefer to work on, and I’m more likely to spend my volunteer time working on them.

This isn’t an exhaustive list, but it gives you an idea of the kinds of motivations that go into the contributions of a volunteer. And it means that sometimes tickets that garner interest and conversation – your CPT ticket example is a good one – can fizzle. Sizable features like this really need to be personally shepherded by someone in order to be successful, and there is simply too little developer time to cover all worthy tickets.

Is our system for choosing features and fixes perfect? No, definitely not. Your voting idea is a nudge toward something missing from my list: “items that are wanted most by the community”. If you’re interested in pursuing something like this, please please please do – the Future Release pile has lots of good stuff in it, but it really needs people to read through tickets and pick out the stuff that should be presented to the community. Feel free to reach out to me if you want to talk more about this.

As a side note: Deciding on roadmaps, etc is really hard. We want to do what’s best for the project (whatever that might be, and however you might determine it), but at the same time we want to ensure that contributors – who, it’s important to remember, are giving their free time to the project – are working on things that they personally find valuable and enjoyable. I’m eager to work with interested members of the community do a better job at striking the necessary balance.

[@boonebgorges Keymaster 12 years, 11 months ago]

> Nothing to be with BuddyPress or WangGuard (I think…)

I’m guessing that this line is part of wp_redirect(), which sounds like it’s happening because of a canonical redirect. I think you’re right that it’s probably not related, but you might still want to check out what’s causing it.

Let me know how 'bp_include' goes!

[@boonebgorges Keymaster 12 years, 11 months ago]

There are probably a couple things happening:

1. There is a hardcoded check to is_super_admin() in bp_core_process_spammer_status(). That check would fail during a cron job. BuddyPress should probably separate out the business logic of this function from the permissions checks. This would be appropriate for an enhancement ticket.

2. Certain parts of BuddyPress are only loaded at some times. If you’re going to modify BP’s behavior, or use functions from BP, you need to make sure you’re waiting for BP to be loaded before doing so. It’s possible that load order works differently during cron than during regular page loads, so it’s extra important to pay attention to these rules. In short, anything that needs to hook to a BuddyPress action, or use BuddyPress functions, should be in files that are loaded at 'bp_include' or later. (See https://codex.buddypress.org/plugindev/checking-buddypress-is-active/). I’m glancing at wangguard-admin.php, and it looks like there are quite a few places where you’re attempting to do BP stuff in the main plugin file – try breaking it out into a separate, BP-specific file, which is loaded in the manner described in that link.

If you can, you might also try turning up your error reporting level on your test installation, making sure that it’s going to your Apache error log or wp-content/debug.log. It could be that something’s happening that’s causing a non-fatal error, and your php.ini settings are too low for it to be showing up. wp-cron can be sensitive to that sort of thing.

[@boonebgorges Keymaster 12 years, 11 months ago]

Multi-network does have some issues (and has been real-world tested by relatively few people), so it could well be that this is a bug.

I’m a bit confused about how to reproduce, though. Is the issue

(a) that when you have activity streams from different networks on the same install open in the same window, and post to the stream in one of them, the update dynamically appears in all of them? (ie, it’s a JS issue)
(b) that when you post to an activity stream in one network, and then load the stream from another network, it shows up there too?

I guess I’m looking for clarification on this bit: “when I post an update on one site, that activity stream will load on the other BP site I have. It will stay there, on both sites, until I post an update on it, and then that stream shows up on both sites.”

A good starting place for debugging is to track the database tables. In a multi-network configuration, each network should have its own set of wp_bp_ tables. Post an update in one network, and then check the wp_x_bp_activity tables for each relevant network to make sure that it only shows up in the correct one.

Another related question. When user A posts to network X, my interpretation of your report is that user A can also see the update in network Y. Can user B also see that update in network Y?

[@boonebgorges Keymaster 12 years, 11 months ago]

@dennish The installation of bbPress that is packaged with BuddyPress contains a file at buddypress/bp-forums/bb-config.php. When you attempt to access the bbPress installation directly as you describe, the bbPress bootstrap loads this bb-config.php file, and sends a 403 Forbidden header to the browser. Thus, it should NOT be the case that users are able to create accounts (or do anything else) on these pages. If you are finding otherwise, it could be because your buddypress/bp-forums/bb-config.php file is missing or corrupt.

In the future, when you find what you believe are security issues in BP, please do not post them to the forums, but instead send an email to security@wordpress.org. Thanks.

[@boonebgorges Keymaster 13 years, 2 months ago]

– Yes, 'nav_item_name' should be translatable if you plan to distribute the plugin. If it’s for a custom installation, it doesn’t matter.

– Yes, you can set 'enable_nav_item' (or any other config value) conditionally. I’d do your conditional logic *inside* of the constructor, to be sure that it’s loaded late enough:

function __construct() {
    $show_nav_item = (bool) plugin_is_enabled( bp_get_current_group_id() );
    $args = array(
        'enable_nav_item' => $show_nav_item,
    );
    parent::init( $args );
}

[@boonebgorges Keymaster 13 years, 2 months ago]

The problem is, in essence, this: You are filtering for member type/role at the template level, *after* the query has already taken place. So: you run bp_has_members(). It returns 10 users that match the current params, which include the current page, the per_page number, and the dropdown filter (last active, alphabetical, etc). Then, inside of your template loop, you are only displaying a subset of those ten returned members – ie, those that match your s2member role.

In order to make a custom directory *and* have your pagination work, you’ll need to modify the query *before* it happens. One relatively simple way to do this is to pass an include parameter to bp_has_members(), which would limit the query to users that meet your s2member criteria.

Because we’re talking about custom user roles as assigned by s2member (and because user roles are stored in a way by WP that doesn’t allow this kind of query to be very efficient), this is going to be pretty tricky. This is totally untested, and probably not very fast at very large scale, but you could try something like the following:

<?php 
global $wpdb;
$level3_user_ids = $wpdb->get_col( "SELECT user_id FROM {$wpdb->usermeta} WHERE meta_key = 'wp_capabilities' AND meta_value LIKE '%s2member_level3%'" );
$level3_user_ids_param = implode( ',', $level3_user_ids );

if ( bp_has_members( bp_ajax_querystring( 'members' ) . '&page_arg=bapage&per_page=10&include=' . $level3_user_ids_param ) ) : ?>

Then you will *not* need to do the level3 check inside the loop, because the 10 items returned will already be limited properly.

Like I said, this is off the top of my head and may not work without further modification. You may have to do some more experimentation to get an accurate whitelist of user ids for each directory type. But, no matter how you do it, the above example should show you a good technique for limiting the bp_has_members() query to a subset of all users (which is the BuddyPress-related part of this puzzle – the other problem is related to s2member).

[@boonebgorges Keymaster 13 years, 2 months ago]

It’s hard to tell exactly without knowing more about how you’ve customized your templates, but it’s possible that this is a problem only with AJAX. A quick fix may be to disable AJAX pagination for the members directory. Do so by adding the ‘no-ajax’ class to the .pagination div, ie

<div id="pag-top" class="pagination no-ajax">

If you’re still having problems, please post more details about how your theme is set up – whether it’s a child of bp-default, which default templates you are overriding in your theme, and perhaps the content of the custom templates themselves.

[@boonebgorges Keymaster 13 years, 3 months ago]

You’ll have to do some more debugging. It’s probably the case that $test_customfield is empty; try var_dump( $test_customfield ); just after you’ve defined the variable, just to be sure. It’s also possible that the $post global does not contain the information that you want at this particular point in the WP load order. Try passing the $post object to your test function:

function test1( $the_post ) {
    $post_id = $the_post->ID;
    // ...
}

// ...
$not = test1( $post );
// ...

[@boonebgorges Keymaster 13 years, 3 months ago]

Try this:

function test1() {
    return 'this not';
}

[@boonebgorges Keymaster 13 years, 6 months ago]

This is pretty close to being right. I think ‘init’ is too early; try hooking to ‘bp_actions’ instead.

Also, you may find that you have to reset the default tab for ‘settings’ before removing the subnav items (or you’ll get funny redirect loops). Use `bp_core_new_nav_default()` for this.

[@boonebgorges Keymaster 13 years, 6 months ago]

You’re using form actions incorrectly. The form `action` is intended to be a URL, not a PHP callback. You’ll need to add your server-side processor to a separate function, ideally in a separate file from the screen function. Something like:

`
function bbg_handle_department_join() {
if ( isset( $_POST[‘department-request-submit’] ) ) {
$submitted_departments = $_POST[‘select_departments’];
// do something with the items
}
add_action( ‘bp_actions’, ‘bbg_handle_department_join’ );
`

I also urge you to implement some security checks. At minimum, use a nonce as well as an appropriate `current_user_can()` check. See https://markjaquith.wordpress.com/2006/06/02/wordpress-203-nonces/ for a primer on nonces in WordPress.

[@boonebgorges Keymaster 13 years, 7 months ago]

The following two changesets should address your issue:

https://buddypress.trac.wordpress.org/changeset/6826/trunk
https://buddypress.trac.wordpress.org/changeset/6829/trunk

[@boonebgorges Keymaster 13 years, 8 months ago]

I agree with those who’ve said that you should be skeptical of the equity offers. Unless this is a project that you really love, and you believe that it’ll make lots of money, and you have other work putting food on your table, it’s better to get paid for your work than to gamble on potential future success.

As for what to charge: This is really hard. For these sorts of projects – especially for BP projects, where there are relatively few devs doing professional work – there’s really no such thing as a “going rate”. How much your work is worth is really about how much it’s worth *to your specific client*. That said, you need to make sure that you make enough money to make it worth your while. I’d recommend something like this. Come up with a rough figure for what you absolutely need to make in a month (or a year, or a week, or whatever) to be happy. Then, do your best estimate of how many months (weeks, whatever) this project will take you if you devote yourself full-time-ish to it. Do the math to get your bare-minimum number. Then multiply it by two or thrtee. That’ll account for the fact that developers always forget to count in their estimates all the time it takes to communicate with clients, to fix unexpected bugs, to learn new stuff, etc. It also gives you a bit of room to negotiate if the client says no to your initial number.

One more note about flat-rate bidding. You will *need* to have a contract, it will need to contain a very detailed scope/spec, and you will need to be hard-nosed about sticking to the spec – if the client wants changes down the road, get the requests in writing, and charge for them. Every project will experience scope creep, and when you’re working hourly or on a retainer, you have built-in cushion. But with a flat fee, you have to make sure that scope creep doesn’t cost you money. That said, as long as you’re hard-nosed most of the time, you can occasionally grant a special request for an out-of-spec feature, call it a “professional courtesy” or a freebie, and the client will really think you’re swell. It’s all about setting expectations 🙂

Good luck!

[@boonebgorges Keymaster 13 years, 11 months ago]

> Reconsider finishing a solution under 1.7.

Releasing something half-finished is not in the plans. Thanks for your patience.