[@boonebgorges Keymaster 15 years, 1 month ago]

Very strange. Well, if the problem arises again, take careful note of what plugins you may have turned on/off around that time, and then post again here. Thanks for your patience.

[@boonebgorges Keymaster 15 years, 1 month ago]

Sorry about that, I misread what you were writing. I understand now.

Have you, by chance, turned off any BP plugins recently? I have a hypothesis that there are notifications in your database corresponding to a component that no longer exists (ie, because you disabled it). Or maybe you have shut off one of BP’s core components?

[@boonebgorges Keymaster 15 years, 1 month ago]

So what happens when you do
`var_dump( $major );`
after all of this? Does it show up as `false`, or undefined? If false, the problem is that the user has not filled in the data (or the field doesn’t exist). If undefined, then there is a more significant problem.

You might check your database table wp_bp_profile_data to make sure that there is indeed a row corresponding to the logged in user id and field 19.

[@boonebgorges Keymaster 15 years, 1 month ago]

Hm. Your upgrade must not have completed properly. In BP 1.5 RC1, there is no file called bp-core/bp-core-notifications.php. That file, along with the files that called it, must be left over from your pre-upgrade version of BuddyPress. You might consider deleting the contents of the entire /buddypress/ directory, and then reuploading BP 1.5-RC-1’s files into that folder.

[@boonebgorges Keymaster 15 years, 1 month ago]

Very strange. I wonder how old notifications might have caused this problem. You don’t happen to have access to your server’s PHP error log, do you? It might help to see whether this is a problem with BP itself.

[@boonebgorges Keymaster 15 years, 1 month ago]

The plugin folder must be called ‘buddypress’. Yours is called ‘1.5-rc-1’.

[@boonebgorges Keymaster 15 years, 1 month ago]

The current stable version of the template pack has not been verified as compatible with BP 1.5. You can get the dev version from https://github.com/boonebgorges/bp-template-pack

[@boonebgorges Keymaster 15 years, 1 month ago]

Did you upgrade from BP 1.2.9 or another version?

[@boonebgorges Keymaster 15 years, 1 month ago]

BuddyPress 1.5 has not been released in a stable version yet. We are in Release Candidate status. https://buddypress.org/2011/09/buddypress-1-5-release-candidate-1-and-buddypress-1-2-10/

[@boonebgorges Keymaster 15 years, 1 month ago]

@mercime ‘s method will work correctly. But, as of https://buddypress.trac.wordpress.org/changeset/5124, it shouldn’t be necessary. The method that @alanchrishughes suggests should work properly. Please ensure that you’re running 1.5-rc-1, or an svn checkout of at least r5124.

[@boonebgorges Keymaster 15 years, 1 month ago]

The functions are not new – the whole point of a framework like BuddyPress, from the beginning, has been so that you *don’t* have to reinvent the wheel

I think that for your purposes you can use `xprofile_get_field_data()`. See bp-xprofile/bp-xprofile-functions.php.

[@boonebgorges Keymaster 15 years, 1 month ago]

That’s what `xprofile_set_field_data()` is for.

`xprofile_set_field_data( 1, $iallusersUserID, $nicename );`

No need to use $wpdb!

[@boonebgorges Keymaster 15 years, 1 month ago]

+1 to using the `xprofile_` functions if you can.

[@boonebgorges Keymaster 15 years, 1 month ago]

Components register their table names themselves. See https://buddypress.trac.wordpress.org/browser/trunk/bp-xprofile/bp-xprofile-loader.php#L85

In the case of xprofile, they are
`$bp->profile->table_name_data
$bp->profile->table_name_fields`
and so on.

You may find it helpful to look at https://buddypress.trac.wordpress.org/browser/trunk/bp-xprofile/bp-xprofile-classes.php to see how BP itself references these tables. Likewise for the other components.

[@boonebgorges Keymaster 15 years, 1 month ago]

Better than NY pizza? I’m dubious But glad it’s working now!

[@boonebgorges Keymaster 15 years, 1 month ago]

@simon_said – Would you mind posting a bug ticket on trac.buddypress.org, with steps to reproduce? Thanks!

[@boonebgorges Keymaster 15 years, 1 month ago]

Thanks for the link. I was able to produce this locally.

The problem appears to be that Safari does not like @font-face applied to the select element. Here’s what I had to do to make the problem go away:
`body select, body option {
font-family: ‘Times New Roman’ !important;
}`

You don’t have to use Times, just some system font (*not* @font-face).

[@boonebgorges Keymaster 15 years, 1 month ago]

The BuddyBar builds those links mostly out of $bp->bp_nav and $bp->bp_options_nav (which are also responsible for site navigation in other places). See https://buddypress.trac.wordpress.org/browser/trunk/bp-core/bp-core-buddybar.php#L423

The WP Admin Bar is built more independently of the BuddyBar. Each component essentially does its own work. See for instance https://buddypress.trac.wordpress.org/browser/trunk/bp-groups/bp-groups-loader.php#L370

[@boonebgorges Keymaster 15 years, 1 month ago]

Hm. That’s not a very good general solution Can you share the code you’re using at bp_setup_globals? I don’t think anything has changed recently in BP that would cause this kind of problem (I’ve got an install running a couple dozen plugins on the latest trunk, with no problems like this), but if there is a problem, we should figure it out soon

Do you happen to remember how much time happened between your svn ups? Days, weeks, months?

[@boonebgorges Keymaster 15 years, 1 month ago]

Wow, this issue is getting weirder.

I have copied your theme but I can’t reproduce the problem. This could have to do with the fact that I don’t have the font files on my system. In any case, I have no idea whatsoever about how a font declaration could cause the sorts of problems you’re talking about.

Just to see if it helps, you might try commenting out the BP javascript that makes the dropdown filters work. Look in buddypress/bp-themes/bp-default/_inc/global.js, around line 542, for the block beginning “When the filter select box is changed re-query”. Comment that out, clear your cache, and try again. (I’m skeptical this will actually get us any closer to the issue, since it sounded like you were having this problem with dropdowns other than this one.)

[@boonebgorges Keymaster 15 years, 1 month ago]

Just to be clear – by “autocomplete” you mean that, when you click the Private Message button, the user’s name is already filled in as a little box on the Compose screen, right?

[@boonebgorges Keymaster 15 years, 1 month ago]

Hm. I guess if I were you I would start with my child theme’s javascript. Look for something that would activate when a dropdown is changed, possible using the jquery method .change. At the very least, try disabling your child theme’s javascript (just comment it all out for a moment) to verify that that’s where the problem lies.

As it stands, it appears that this is *not* a BuddyPress problem, but is related to your theme – but more investigation on your part will make this clearer.

[@boonebgorges Keymaster 15 years, 1 month ago]

Wow, that is a very strange issue. Have you tried clearing your browser cache entirely? It’s possible that there is some rogue javascript in your cache (which may be related to BuddyPress or may not) that is causing this bizarre behavior.

FWIW I can’t reproduce this, with the same setup (except Snow Leopard instead of Lion, but I can’t imagine it’d make a difference.)

[@boonebgorges Keymaster 15 years, 1 month ago]

Could you open an enhancement ticket on trac.buddypress.org? Ideally with a patch

[@boonebgorges Keymaster 15 years, 1 month ago]

I did end up writing the plugin I talked about earlier. It’s called Unconfirmed: https://wordpress.org/extend/plugins/unconfirmed/