BuddyPress.org

Could ask the theme authors.

I believe it pulls in the default. Best place to add things to registration pages in MU is to write a plugin to hook into the filters in place on that page, rather than hack the core.

Very nice. How is the marker in the map determined? Do you have registration items for address and then geocode on the backend?

Good work

AFAIK it is the register.php file that resides in the registration folder in your theme

Thanks,

Shai

Don’t modify core files.

You add new fields to registration from the backend in the BuddyPress menu area. just fill out what you want and they get added automagically.

Hello,

I have the same problem. How can ik fixed it? (social theme)

Xander

I need to figure this out as well. The xprofile fields are generated (?) with a loop from an array. It looks almost impossible to do anything with a specific xprofile field if you are not an advanced PHP whiz.

Or could you just hard code the registration fields on register.php, instead of using the ‘profile field loop’? And then use field_2 and field_3 to “do stuff” with? Are there any serious downsides to that to watch out for?

There are still issues with users not being able to add their avatar at registration. What files in the trunk do we need to replace with our local versions? Could you guys let me know which ones so that I can fix this bug and move on? Thank you!

Here’s something else that might interest a few: I installed WPMU Super Captcha over the weekend (running WPMU2.9.1 & BP1.2rc). Since then, there have been no bot signups at all, and the plugin has blocked exactly 50 attempts. Plus, it logs each attempt that it blocks so I can keep track.

I’ve also added a comment on the registration form directed towards human signer-uppers with a support email address just in case. None of the 50 blocked attempts have used it, so…

Bots had managed to get around other plugins I’ve tried before, but not this one.

Fixed in trunk (apparently).

Check your web server log; probably folder permissions.

is testing and it appears you’ll need to wp-signup in the root of where the registration page is without hacking the core.

I’m wondering about the exact same thing (only for subdirectories and not subdomains!)

Since using a subdirectory install is less obvious than a subdomain (eg. example.com/community/register vs. example.com/register), I might just theme the register page so it matches my root blog.

But, I’d love for you to figure this out, Boone!

couldn’t you just redirect in the page template for the sub install with wp_redirect()

awesome.boone.com/register > boone.com/register.

I used this plugin for a one-time, scary users import operation. Not sure if that’s helpful for your issue.

The WP/WPMU/BP members database is a patchwork designed to be as incompatible as possible with whatever else you might dream of using.

@jeffreeeeey: any luck with this? I’m getting the bp-registration-options.php on line 639

error as well.

The plugin has helped a great deal. I went and modified wpmu-functions.php to add the members profile URL so I could quickly look at the person’s info and either spam or delete them if I thought they were fake. It’s still pretty manual, but faster.

I currently have the option set that people can sign up for groups on the registration screen:

http://tkdunion.org/register

So, I thought perhaps it occurred because I didn’t join any groups. Lots of people get emailed when a new user signs up, so I hesitate to keep testing this. Any suggestions? How did you resolve this issue?