[@peterverkooijen Participant 16 years, 9 months ago]

On the wire the delete button DOES work. The link again looks something like this:

<a class="item-button delete-post confirm" href="http://mysite.com/members/admin/wire/delete/2?_wpnonce=4ce0247d7d">Delete</a>

I still get the annoying ‘Are you sure?’ popup, but when I click OK the page refreshes with ‘Wire message successfully deleted’.

Why/how are delete-activity and delete-post different? I tried with class ‘delete-post’ on the activity delete button, instead of ‘delete-activity’, but still get the same ‘Page not found’ error.

To recap, the problem is only on delete buttons on the Activity wire. Am I really the only one with this problem (in 2.8.6+1.1.3)?

[@peterverkooijen Participant 16 years, 9 months ago]

I installed the Buddymatic theme, but get exactly the same error. The problem must be in the Buddypress core files somewhere – I had reuploaded those to make sure they are the untouched 1.1.3 files.

Any other suggestions what I could try to fix this or pinpoint the problem? This is driving me nuts…

The delete link looks like this:

<span class="activity-delete-link"><a href="http://mysite.com/activity/delete/20?_wpnonce=0f239e493d" class="item-button delete-activity confirm">Delete</a></span>

When I click I get the ‘Are you sure?’ popup and then when I click OK it redirects to ‘Page not found’ with the same wpnonce URL still in the address bar.

Why? Where is it supposed to go? Which piece of code is supposed to handle this wpnonce URL?

The problem is not in the theme. I tested two clean themes, default and buddymatic. Both had the same problem.

The problem has to be in the bp core code…

The delete button is produced by this function in bp-activity-templatetags.php:

function bp_activity_delete_link() {

echo bp_get_activity_delete_link();

}

function bp_get_activity_delete_link() {

global $activities_template, $bp;



return apply_filters( 'bp_get_activity_delete_link', '<a href="' . wp_nonce_url( $bp->root_domain . '/' . $bp->activity->slug . '/delete/' . $activities_template->activity->id, 'bp_activity_delete_link' ) . '" class="item-button delete-activity confirm">' . __( 'Delete', 'buddypress' ) . '</a>' );

}

When I remove ‘confirm’ from the class, the annoying ‘Are you sure?’ popup disappears, but the page still redirects to ‘Page not found’ and the unwanted wire item is still on the page.

I assume this function only produces the link; there must be another function somewhere that is supposed to process it. Where?!

ajax.js is loaded – I double-checked… – but what is the connection between the delete link and the javascript? Is that where the processing should take place?

ajax.php has this:

<div class="wire-post-metadata">

<?php bp_wire_post_author_avatar() ?>

<?php _e( 'On', 'buddypress' ) ?> <?php bp_wire_post_date() ?>

<?php bp_wire_post_author_name() ?> <?php _e( 'said:', 'buddypress' ) ?>

<?php bp_wire_delete_link() ?>

</div>

bp_wire_delete_link, not bp_activity_delete_link…

[@peterverkooijen Participant 16 years, 9 months ago]

I installed the Buddymatic theme, but get exactly the same error. The problem must be in the Buddypress core files somewhere – I had reuploaded those to make sure they are the untouched 1.1.3 files.

Any other suggestions what I could try to fix this or pinpoint the problem? This is driving me nuts…

[@peterverkooijen Participant 16 years, 9 months ago]

In version 1.0 the delete link was part of a file bp-wire-ajax.php (deprecated in version 1.1.3.), via a bp_wire_delete_link() function in bp-wire-templatetags.php that looked like this:

function bp_wire_delete_link() {

echo bp_get_wire_delete_link();

}

function bp_get_wire_delete_link() {

global $wire_posts_template, $bp;



if ( empty( $bp->current_item ) )

$uri = $bp->current_action;

else

$uri = $bp->current_item;



if ( ( $wire_posts_template->wire_post->user_id == $bp->loggedin_user->id ) || $bp->is_item_admin || is_site_admin() ) {

if ( $bp->wire->slug == $bp->current_component || $bp->profile->slug == $bp->current_component ) {

return apply_filters( 'bp_get_wire_delete_link', '<a href="' . wp_nonce_url( $bp->displayed_user->domain . $bp->wire->slug . '/delete/' . $wire_posts_template->wire_post->id, 'bp_wire_delete_link' ) . '">[' . __('Delete', 'buddypress') . ']</a>' );

} else {

return apply_filters( 'bp_get_wire_delete_link', '<a href="' . wp_nonce_url( site_url( $bp->{$bp->current_component}->slug . '/' . $uri . '/wire/delete/' . $wire_posts_template->wire_post->id ), 'bp_wire_delete_link' ) . '">[' . __('Delete', 'buddypress') . ']</a>' );

}

}

}

The same function in version 1.1.3 has some subtle differences:

function bp_wire_delete_link() {

echo bp_get_wire_delete_link();

}

function bp_get_wire_delete_link() {

global $wire_posts_template, $bp;



if ( empty( $bp->current_item ) )

$uri = $bp->current_action;

else

$uri = $bp->current_item;



if ( ( $wire_posts_template->wire_post->user_id == $bp->loggedin_user->id ) || $bp->is_item_admin || is_site_admin() ) {

if ( $bp->wire->slug == $bp->current_component || $bp->profile->slug == $bp->current_component ) {

return apply_filters( 'bp_get_wire_delete_link', '<a class="item-button delete-post confirm" href="' . wp_nonce_url( $bp->displayed_user->domain . $bp->wire->slug . '/delete/' . $wire_posts_template->wire_post->id, 'bp_wire_delete_link' ) . '">' . __('Delete', 'buddypress') . '</a>' );

} else {

return apply_filters( 'bp_get_wire_delete_link', '<a class="item-button delete-post confirm" href="' . wp_nonce_url( site_url( $bp->{$bp->current_component}->slug . '/' . $uri . '/wire/delete/' . $wire_posts_template->wire_post->id ), 'bp_wire_delete_link' ) . '">' . __('Delete', 'buddypress') . '</a>' );

}

}

}

I’ll try to replace some code and will report back…

[@peterverkooijen Participant 16 years, 9 months ago]

Have you tried scattering alert statements to see where in the ajax process things are getting hung up?

I can’t find a function in ajax.js with “delete-activity”, the class on the delete button, so I don’t no where to put that test. Is that function supposed to be there?

In the 1.0 version of my site I had no classes at all on the delete link (custom theme). Deleting an item does not have fancy Ajax; the page reloads with “Wire message successfully deleted” in <div id=”message”>.

At least that works! I’d like to just recreate that for my 1.1.3 version.

So I tried removing the following:

class="item-button delete-activity confirm"

from the delete button link in bp-activity-templatetags.php.

That kills the ugly “Are you sure?” popup, but it then goes to “Page Not Found’ and when you go back to the page the item is still there. So it also kills the delete process…

Next trying to spot the differences with the process in version 1.0…

How do those wpnonce links work? What do they do? There’s nothing about them in the codex.

[@peterverkooijen Participant 16 years, 9 months ago]

Thanks Boone Gorges. That at least gives me another thing to try.

I’ll report back when I know more…

EDIT: All these points should be OK though, since I have a clean install – I will double-check them.

Could there have been a change in WPMU’s javascript files between 2.8.4 and 2.8.6 that clashes with Ajax in BP 1.1.3?

[@peterverkooijen Participant 16 years, 9 months ago]

I’ve noticed probably the same problem.

Buddypress has no welcome email by default. You can remove the Buddypress function that kills the welcome email, but then the password in the email is wrong.

I don’t believe this is a WPMU issue. It must have something to do with Buddypress’ changes to the registration process. And I’m also pretty sure that themes have nothing to do with how a password is grabbed from the database and put into an email.

[@peterverkooijen Participant 16 years, 9 months ago]

I just did an entirely fresh install of WPMU 2.8.6 + BP 1.1.3 with default themes. I still get the same errors on the delete buttons (in the My Latest Activity feed and other places).

Am I the only one who has this problem?

What parts need to be in place for the Ajax around the delete buttons to work correctly?

[@peterverkooijen Participant 16 years, 9 months ago]

I also use the email login plugin, but generate a username from the fullname using Javascript (link is for blogname from blog title, but the principle is the same). I think that’s a cleaner solution that avoids a lot of the issues you ran into.

[@peterverkooijen Participant 16 years, 9 months ago]

Just this in a file:

<meta content="0; URL = http://bloggingwire.com" http-equiv="Refresh" />

[@peterverkooijen Participant 16 years, 9 months ago]

@JJJ, you are basically saying that it’s up to the end users/members to keep their data synchronized? And if it’s not, it’s their problem? It’s just not a very user-friendly approach.

Also, I’m very much in favor of keeping all options open for all use cases, but Buddypress does not offer any built-in firstname/lastname option. Simple built-in syncing with wp_usermeta upon activation like in my custom function would solve that problem and wouldn’t hurt anybody.

Maybe Andy refuses to include it in the core just to spite me, which would be at least somewhat understandable…

[@peterverkooijen Participant 16 years, 9 months ago]

Please, don’t cram BP full of this type of features! Leave them to third parties; basic free plugins, sophisticated paid plugins, external apps with a plugin interface, etc.

There are already so many WordPress plugins available. Why not start with adapting and extending those, instead of reinventing the wheel within BP.

Please core developers, concentrate on the core! Make sure it’s clean, solid and secure. Concentrate on APIs that make it easier for third parties to hook into BP.

Photo albums may be core to some, but not for everybody. I can think of dozens of other applications that could be core to someone; event management, mailing lists, groupware, file sharing, paid membership levels, video galleries, group video editing, chat rooms, video conferencing, shopping cart, credit card payment bridge, mobile apps, geolocation … etc.

[@peterverkooijen Participant 16 years, 9 months ago]

Thanks for the feedback. I thought I’d seen somewhere that some Ajax had been taken out or simplified, but that’s not what’s going on here then.

I must have broken something. What parts do I need to put Ajax back together? Where is the Javascript for these delete buttons?

My delete link looks the same, including the class. I also have the template_notices line. I probably get the popup because Javascript is missing.

This thread has some clues. I’ll get back to this next week…

[@peterverkooijen Participant 16 years, 9 months ago]

I’ve seen no more than ten people complain about this out of everyone who uses BuddyPress. If this was a widespread issue then there would be endless complaints and tickets.I’ve seen no more than ten people complain about this out of everyone who uses BuddyPress. If this was a widespread issue then there would be endless complaints and tickets.

You will see more complaints when Buddypress moves out of the current audience of typical wp-users/coders/bloggers to businesses, schools, associations, etc.

You seem to have a tendency to approach people in a very direct and confronting way.

I’m not trying to make friends and don’t expect a lot of help anyway. I use the forums partly to keep track of my own development issues and partly to let the developers know where the real pain points are for a regular user, who knows some html/css and a bit of php, but is not a programmer.

I also represent the people who are not on this forum; who try BP, get frustrated and give up.

But yes, this is all off-topic. The question is still wp-bp profile syncing!

[@peterverkooijen Participant 16 years, 9 months ago]

I don’t understand your issues with member management? WordPress MU provides excellent member management tools, and BuddyPress rides on the back of this. What is it that you need so desperately?

What is your solution to the main question of this thread? I have given my hack, but it doesn’t work for Dan Butcher.

Also if the member management tools are so great, can you answer how to display basic profile information anywhere in the theme?

My main issue with member management in BP is that there is no built-in consistent way to store firstname+lastname, as I’ve explained over and over to the annoyance of many on this forum. It makes it much more difficult to integrate third party scripts that do require firstname + lastname, like mailing list ListMessenger in my case.

Commercial membership plugins apparently create their own members table to not be stuck in WP’s built-in users management. If WP had a more solid solution that would not be necessary.

WordPress provides a decent base, but over the years bits and pieces were apparently added in different tables – nickname, display name, first name, last name, … – and BP added xprofile on top of that without synchronization with wp_usermeta. But I’m repeating myself again…

Just trying to help so you’re not completely ignored.

I’m ignored anyway.

[@peterverkooijen Participant 16 years, 9 months ago]

As much as I agree that you want to keep it simple, the last thing I want to do is a. auto-generate usernames (you have to tell them and they have to remember – let them decide)

They don’t in my site. They log in with email address. The only reason to still have an (autogenerated) username is because you need it for the URL.

parse a field into various name fields (parsing is just begging for errors – too may what-ifs) … But look deeper: they then auto-generate a username. why? who knows … Additionally they auto-gen a drop down list of “display names” … So what’s the diff between me and FB?

Also not much difference between me and FB. The difference between your solution and FB is what the user actually sees on the registration form. I don’t believe a new user will be all that interested in those extra choices.

I hearby declare it off limits to refer to Andy’s decision not to include firsname/lastname ever again.

It’s not up to you to decide what the limits of discussion are. You may get it, but until Andy/WP/Automattic gets it I’ll keep bringing it up. I like the features WP/WPMU/BP offers, there are really no alternatives for those, but they need to get central member management and the database structure up to standard.

[@peterverkooijen Participant 16 years, 9 months ago]

Why not do the following (as we have) …

1. username

2. 1st name

3. last name

4. display name (the bp required field)

Because it’s not necessary. The goal should be to keep the registration form as short and simple as possible and not annoy new users.

Look at the registration process on Facebook, LinkedIn, etc. Most have:

First Name:

Last Name:

Email:

Password:

I use a javascript trick generate the username from the fullname in a hidden field – I can use email as username thanks to this plugin. Since BP has a built-in fullname field I’m stuck with splitting that out in firstname and lastname.

I have considered using fullname for firstname and creating a field_2 for lastname, but that causes all kinds of other issues.

Unfortunately there is no check/validation on what’s entered in the fullname field. The input is also not cleaned up to get capitals on the first letters and small caps on the rest. So the input could be anything, often just a first name or even ladiesman269.

Which undermines any reason of having that required fullname/display field in the first place…

All you have to do is create a function that writes the xprofile field values for 1st and Last name over to the WP table, in addition to setting the “display name value accordingly.

You have to do that straight from the registration form, to make sure that the data is there where/when you need it. That is basically what my function does. If you can get it to work. Apparently it doesn’t for Dan Butcher.

Now, with the (lame) fact that WP user table is actually different (not sure why it wasn’t co-opted for BP purposes)

That had mystified me since last Spring, but here’s Andy’s reason.

[@peterverkooijen Participant 16 years, 9 months ago]

What does that plugin do? It has some vague requirements:

Create three news fields that will be used by the plugins (ex. “Member name”, “Member firstname”,”Member bothnames”). I suggest “Member name” to be a required field.

Fill the values of those fields for your profile (the datas for at least one user are needed to setup the plugin options)

Where are you supposed to create those fields? xprofile? In addition to the existing fullname field? You can already do that without this plugin.

wp_usermeta is nowhere in the plugin. That is the table WP uses to store firstname and lastname. Any solution in Buddypress should leverage wp_usermeta or at least synchronize with it imho. This plugin solves nothing.

If you’ve got a repeatable case of BP changes not syncing to the WP profile, please create a bug ticket on https://trac.buddypress.org/.

The problem Dan Butcher described looks like standard Buddypress behavior to me. It’s not a bug, it’s a feature, based in Andy Peatling’s design decision that firstname + lastname would cause international incidents.

Below again my hack as I use it in my sites, minus creation + update of a fullname-derived username for user_login, user_nicename, user_url and integration with a mailing list script I use:

function synchro_wp_usermeta($user_id, $password, $meta) {

global $bp, $wpdb;



$uid = get_userdata($user_id);

$email = $uid->user_email;



$fullname = $meta[field_1];

$space = strpos( $fullname, ' ' );



if ( false === $space ) {

$firstname = $fullname;

$lastname = '';

} else {

$firstname = substr( $fullname, 0, $space );

$lastname = trim( substr( $fullname, $space, strlen($fullname) ) );

}



update_usermeta( $user_id, 'nickname', $fullname );

update_usermeta( $user_id, 'first_name', $firstname );

update_usermeta( $user_id, 'last_name', $lastname );



$wpdb->query( $wpdb->prepare( "UPDATE {$wpdb->users} SET display_name = %s WHERE ID = %d", $fullname, $user_id ) );



}

add_action( 'wpmu_activate_user', 'synchro_wp_usermeta', 10, 3);

I have this code in bp-custom.php or functions.php, not as a plugin. Adding a plugin header could have caused Dan Butcher’s error messages.

BTW, I’m still looking for code to validate the fullname input for at least a two part name, so make a space required. I now get a lot of users only entering a first name. In that case the lastname field in wp_usermeta will stay empty.

[@peterverkooijen Participant 16 years, 9 months ago]

It’s sad that people have to apologize and jump through all kinds of hoops just for wanting to get paid for their work. GPL is free, open code. Beyond that what people do with it is their business.

[@peterverkooijen Participant 16 years, 9 months ago]

Looks like the function is already in your bp-custom.php, which is not part of standard Buddypress. Can you check in the file if it’s the exact same code?

If so, how did it get there…?

If it’s not the same function, you can probably fix the problem by search/replace in the function: synchro_wp_usermeta -> custom_synchro_wp_usermeta

I don’t remember if I replaced an existing function with the same name. Buddypress did have a function to update wp_usermeta when profile info is updated, but I think that one had another name.

[@peterverkooijen Participant 16 years, 9 months ago]

This is my big pet peeve with Buddypress; there is no consistent built-in way to store fullname (as firstname + lastname). Profile synching only happens when members update their profile using the WP backend.

This is by design. BP’s lead developer Andy Peatling believes firstname/lastname would not work for international users.

My ugly workaround is here. Also see this one. I use the Javascript trick to generate a username from the fullname, so at least those are easier to recognize.

[@peterverkooijen Participant 16 years, 9 months ago]

As far as I can tell LDAP is not just about user authentication, but also about exchanging or synchronizing data with other directories or member management systems. So it includes issues like getting data out of xprofile etc.

Thanks for the WPMU-LDAP plugin! I’ll try that one first.

[@peterverkooijen Participant 16 years, 9 months ago]

I’ll be reworking the schema in 1.2, interested to hear your ideas.

Could LDAP standards be a useful guideline?

[@peterverkooijen Participant 16 years, 9 months ago]

We were discussing displaying single xprofile fields here.

Someone gave me this function:

function custom_xprofile( $field ) {

echo bp_custom_get_member_list_xprofile_data( $field );

}

function bp_custom_get_member_list_xprofile_data( $field ) {

global $site_members_template;

return xprofile_get_field_data( $field, $site_members_template->member->id );

}

So you can use this in the members index.php:

<p><?php custom_xprofile('Company') ?></p>

But it only works in members_template. I’d like to have a function for xprofile fields that works anywhere…

Haven’t had time to try variations on this one. Suggestions very welcome!

@Anton Koekemoer, I’m pretty sure the key would be in replacing $site_members_template in the function, but I wouldn’t know with what.

EDIT2: Here’s the thread where I originally got the function, from John James Jacoby.

[@peterverkooijen Participant 16 years, 9 months ago]

I’d finally discovered the solution David Lewis mentioned. It seems to work in most modern browsers, including the latest IE. And Suzanne’s Javascript solution covers the rest.

So this is resolved. Forget I asked…