[@boonebgorges Keymaster 8 years, 11 months ago]

> I just want to say a big thank you from Boulder, CO. You guys are awesome!

Right back at ya!

It looks likely that the OAuth plugin is the culprit. I have not tested, but it looks like there’s a line in oauth2-provider/library/class-wo-api.php that redirects auth requests to wp_login_url() and tries to guess the proper redirect_to parameter, but might miss the querystring as it’s sent from the BPGES plugin. You should be able to verify by disabling the plugin and seeing if the BPGES login chain works without it. If that’s the case, it’s likely that you could fix the problem by ensuring that the OAuth plugin passes the $SERVER[‘QUERY_STRING’] or something like that, but it’d take some further digging into how the plugin works to be sure.

[@boonebgorges Keymaster 8 years, 11 months ago]

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.

[@boonebgorges Keymaster 8 years, 11 months ago]

> the form still doesn’t work with or without the avatar upload.

Could you say more about this? By “the form” you mean the *registration* form?

As David suggests above, BP doesn’t allow for avatar upload at the time of registration, at least not out of the box. This suggests to me that you have another plugin (or something in your theme) that is enabling this feature, and that it might be this feature that’s causing the problem. Can you take a look at the plugins active on your site to see if one of them might be doing this?

As for the registration form, it could be that the plugin that’s enabling the avatar upload during signup is *also* causing the failure, because it rejects registrations without an avatar attached. If so, this is something you could fix by disabling the plugin. It could also be that the registration failures are linked to something other than the avatar issue. In this context, it’d be helpful to know more about what you mean when you say that the form “doesn’t work”. Are you shown an error message after submitting? A totally white screen? A registration that appears to work but never sends the confirmation email?

[@boonebgorges Keymaster 8 years, 11 months ago]

Ha. Yes, this is an old and annoying issue in WordPress and WP plugins.

That said, we have done extensive work in the past to ensure that quotes are stripped where necessary throughout various interfaces. If you can share more detail about exactly where you’re seeing the slashed content, we may be able to help figure out where things are going amiss. For example, you say that you’re seeing this in the activity feed. But in what context? Is it when you type something directly into the “What’s new” box, or when something is syndicated from elsewhere on the site? Are you seeing the slashes when you refresh the page, or only when the content is returned from the database?

[@boonebgorges Keymaster 8 years, 11 months ago]

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/

[@boonebgorges Keymaster 8 years, 11 months ago]

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.

[@boonebgorges Keymaster 8 years, 11 months ago]

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?

[@boonebgorges Keymaster 8 years, 11 months ago]

Hi @amitrwt – The ‘Start’ and ‘End’ fields in the BP admin settings define the start and end dates of a single datepicker. That is, if you want to have a datepicker, but you only want to show dates between the years 1970 and 1990, you’d use those dates as the Start and End.

If you want your users to be able to select start and end times, my best suggestion is to create two separate xprofile fields, and name them accordingly: ‘Start Date’, ‘End Date’ or something like that.

[@boonebgorges Keymaster 8 years, 11 months ago]

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' ) );
} );

[@boonebgorges Keymaster 8 years, 11 months ago]

Hello @louisarthur – When you say that they’re “not clickable”, what do you mean? Are they disabled – greyed out, and impossible to select? Or does it simply not do anything when you click them?

You may have some JavaScript – perhaps in your theme – that is preventing the link clicks from working properly. Try disabling JS in your browser to see if it solves the problem. If so, the next step will be to find the problematic JS.

Another thing you may try is opening your browser’s developer console to see if you notice any errors that might be relevant to the issue. In most browsers, you do this by hitting the F12 key.

[@boonebgorges Keymaster 8 years, 11 months ago]

To turn the image into a link, you’ll want something like this:

<div class="bp-login-widget-user-avatar">
  <a href="<?php echo esc_url( bp_loggedin_user_domain() ); ?>">
    <?php bp_loggedin_user_avatar( "type=full&width=200&height=200" ); ?>
  </a>
</div>

If adding this link causes other content to get pushed down on the page, it’s likely that the Avada theme has some styling that is causing a elements to have some additional padding/margin, or perhaps a weird display or clear issue. Best to take it up with the Avada folks.

Good luck!

[@boonebgorges Keymaster 8 years, 11 months ago]

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!

[@boonebgorges Keymaster 10 years ago]

Hi @danbp – Sorry to hear that you’re having issues with the Group Type functionality. Your posts contain a couple different comments and questions, which I’ll try to address separately.

First: An orderby=group_type parameter sounds like an interesting enhancement idea. It’d possibly be even more interesting if we could “group” results by type, but our group loops aren’t easily set up for that.

Group type data is stored in the WP taxonomy tables. This decision was made because groups are in are many-to-many correspondence with types: a group can have multiple types, and a type can have multiple groups. But it does make it difficult to sort by type, both technically and conceptually. Technically, WP itself doesn’t natively allow sorting by taxonomy term for posts. Conceptually, if a group belongs to more than one type – say, ‘aaa’ and ‘zzz’ – it’s not clear where in the alphabetical order it should go.

That said, if you really wanted to sort by type, you could do it by filtering the group query SQL, and joining against the term_relationships and term_taxonomy table. The query would have to look something like this:

SELECT ... JOIN $wpdb->term_relationships tr ON (tr.object_id = g.id) JOIN $wpdb->term_taxonomy tt ON (tt.term_taxonomy_id = tr.term_taxonomy_id) WHERE ... tt.taxonomy = 'bp_group_type' ... ORDER BY tt.name

> And when you click for example on All Groups (the default group directory page) you remain on /groups/groupname/type/typename/. Bad UX !

For 2.7, we’re disabling AJAX for these queries, because of these UX concerns. Thanks for reporting the issue.

> My feeling about group type, is that it is implemented to be used inside of group create step first and in a single group as second. In brief, it’s an information for single groups.

As I see it, the issue here is that you’re trying to combine grouping-by-type with the groups loop. Your use case is valid, but I don’t think it’s the only, or even the primary, use of group types. Just having the ability to filter by group type (example.com/groups/type/foo) is very useful for many implementations.

Thanks for sharing your thoughts – it’s really helpful as we continue to improve the group types feature.

[@boonebgorges Keymaster 10 years, 1 month ago]

I was able to reproduce the problem described here, and I’ve opened a ticket to track it at https://bbpress.trac.wordpress.org/ticket/2992.

@ico33 Perhaps you could test the patch on that ticket, to see if it solves your problem. If so, leaving a comment on that bbPress ticket would be a great way to help.

[@boonebgorges Keymaster 10 years, 11 months ago]

The hook that is the closest to the metal, so to speak, is bp_activity_after_save. So your callback would be something like:

add_action('bp_activity_after_save', 'where_activity_from', 10, 3);
function where_activity_from( $activity ) {
    bp_activity_add_meta( $activity->id, '_source_blog', get_current_blog_id() );
}

This ought to cover any activity item created by any plugin.

The rest of your technique seems like it ought to work. If you wanted to leverage BP’s APIs a bit more (and avoid making direct SQL queries), you could modify meta_query instead of your SELECT FROM {$bp->activity->table_name_meta} WHERE.... But it comes down to pretty much the same thing 🙂

[@boonebgorges Keymaster 11 years, 6 months ago]

> should I replace on with off?

Yes, and then restart Apache to see the effects. It’s dangerous to have this running on a production site.

As for your specific issue: check your wp-config.php file to see if you have defined the constant NOBLOGREDIRECT. It probably looks something like define( 'NOBLOGREDIRECT', true );. If you see it there, comment it out.

[@boonebgorges Keymaster 12 years, 5 months ago]

See how BuddyPress does this: https://buddypress.trac.wordpress.org/browser/tags/2.0.1/bp-groups/bp-groups-template.php

I don’t know why BP does it this way (I would have to check the logs – it seems fishy) but in any case, this probably explains why you’re not seeing anything in your template. You should mimic what you see in that function.

[@boonebgorges Keymaster 12 years, 5 months ago]

Can you share more details about the problem?

– Can you see the groups in question in the Dashboard? Dashboard > Groups
– Are you logged in as an administrator or a normal user?
– Is the logged-in user a member of the groups in question?
– Can you see the groups when you go to example.com/members/yourmembername/groups?

[@boonebgorges Keymaster 12 years, 5 months ago]

> I can’t find any arguments for not including the WordPress profile in BuddyPress.

The arguments are:

– The fields at wp-admin/profile.php are hardcoded in WP. There’s no way we can ask WP which fields it provides in a programmatic way; we’d have to hardcode them as well. This is inelegant; it causes problems when other plugins add their own (hardcoded) fields, which BP won’t know about; and it will require keeping up with WP if they decide to switch which fields are included on that page.
– The fields at wp-admin/profile.php are very odd, and not appropriate for most BuddyPress installations (or most websites that were built after 2004 – who uses AIM, and who among them would want to store that information in their WP profile?)

As noted in the ticket, First Name and Last Name are the two possible exceptions I see here.

[@boonebgorges Keymaster 12 years, 5 months ago]

@j-j Thanks for your patience working through the issues. As for the original question, I agree with @henrywright that 2.0.1 is a very good upgrade for sites like yours, because some of the queries have been refactored to be much, much more efficient.

As for your 502 errors, it’s very hard to diagnose something like this without access to various logs. Since you’re hosted on WP Engine, I would suggest opening a ticket with them. Describe the specifics of the problem, and perhaps also point them to this thread. Ask if they can look in your error logs (and perhaps your slow query logs) to see what’s causing the issue. (NB a 502 error is very non-descriptive, and it could be that it’s not directly BP-related at all.) Only your host will be able to tell you for sure. If they come back with specifics that point to BP 2.0.1 as the culprit, we’ll be in a better position to help.

[@boonebgorges Keymaster 12 years, 6 months ago]

@blankpoint Sorry for the troubles. The upgrade routine necessary for BP 2.0 is fairly large.

I’ll work in the upcoming weeks on improving it, but in the meantime, a few things to try:

1. Your memory limit issue is due to the fact that WP will not allow you to exceed 256M per pageload without explicitly saying you want to (regardless of your php.ini settings). You can put the following into wp-config.php to override for the admin only:

define( 'WP_MAX_MEMORY_LIMIT', '1024M' );

2. Just to get up and running, you might also consider running the heavy migration manually: from the mysql command line.

INSERT INTO wp_bp_activity (<code>user_id</code>, <code>component</code>, <code>type</code>, <code>action</code>, <code>content</code>, <code>primary_link</code>, <code>item_id</code>, <code></code>
date_reco
                  SELECT user_id, 'members' as component, 'last_activity' as type, '' as action, '' as content, '' as
                  FROM wp_usermeta
                  WHERE
                    meta_key = 'last_activity'
                    AND
                    user_id NOT IN (
                      SELECT user_id
                      FROM wp_bp_activity
                      WHERE component = 'members' AND type = 'last_activity'
                    )
        );

You could split this up with a LIMIT clause in case you need to run it a few times.

The other problematic bit of the upgrade routine has to do with migrating your old signups to the new signups schema. (I’m assuming you have open registration + non-multisite.) That migration is not necessarily mission-critical, so you could skip it altogether. So, in other words, once you’ve run the ‘last_activity’ migration, you could comment out line 351 and lines 355-395 here: https://buddypress.trac.wordpress.org/browser/tags/2.0/bp-core/bp-core-update.php#L351 and then reload your admin to mark the migration as complete.

Again, sorry about the difficulties. You’re running a very large BP site, and the migration tools were not up to the job.

Then, you could comment out this line: https://buddypress.trac.wordpress.org/browser/tags/2.0/bp-core/bp-core-update.php#L351

[@boonebgorges Keymaster 12 years, 6 months ago]

@texrat – Sorry you’re still having trouble. Do you have access to your database? If so, you should check in wp_usermeta to see what your user ID’s value for wp_capabilities is (if any). I’d also ask you to double- and triple-check that you’ve followed all the instructions in the plugin – it doesn’t give any visible feedback, and if you make a wrong step (such as putting it in plugins rather than mu-plugins, or using the wrong user_login value), it won’t let you know.

[@boonebgorges Keymaster 12 years, 6 months ago]

@texrat – Thanks. It’s possible that other plugins would cause this sort of problem. You probably are running now, or have run in the past, the kind of plugin that would cause the behavior.

I’ve opened a bug ticket to discuss the bug and possible fixes: https://buddypress.trac.wordpress.org/ticket/5553#ticket

For anyone currently affected:
– By default, BP does not create users with a status greater than Subscriber. This issue only affects people with a role higher than Subscriber
– If your admin user account does not have access to the Dashboard, I’ve written a small plugin that you can use to repair. Instructions and code are here: https://gist.github.com/boonebgorges/4ee64723ba75caa3c7e1
– If you need to repair other users, I recommend that you use the bulk update tools at Dashboard > Users

Note that this is something that only happens during the 2.0 upgrade, so you don’t have to be afraid that it’ll happen again.

Many apologies for the inconvenience, and thanks for your patience and help as we sort things out.

[@boonebgorges Keymaster 12 years, 6 months ago]

@lchief – Many thanks for the additional details. I have a suspicion that bp-disable-activation is the culprit. @texrat – Are you by chance running this plugin too?

I’m going to do some testing and open a bug ticket. I’ll also write a very small drop-in plugin that’ll regrant access to the dashboard. Stay tuned…

[@boonebgorges Keymaster 12 years, 6 months ago]

@lchief – You might be onto something. This is supposed to be part of the migration tool to the new setup system. Can you share the following info:

– Are you running WP Multisite?
– What is your current registration setting?
– Are you using any plugins (other than BP) that modify user registration in any way?