Skip to:
Content
Pages
Categories
Search
Top
Bottom

Search Results for 'registration'

Viewing 25 results - 7,301 through 7,325 (of 7,641 total)
  • Author
    Search Results
  • Dewey Hulsey
    Participant

    Surely.

    I put this in my custom.css:

    #blog-or-username, #blog-details-fields label, #blog-details-fields input,
    #blog-details-fields span, #blog-details-fields p,
    #blog-details-help, #blog-details-fields br {display:none;}

    #blog-details-fields span.suffix_address {
    display: block;
    color: #eee;
    }

    #blog-details-fields span.suffix_address:after {
    content: "Please choose a name for your blog and click Signup to complete registration.";
    display: block;
    color: #555;
    }

    input#blog_title {display:block;}

    Basically, this changed the dialog to “Please choose a name for your blog and click Signup to complete registration.”. This way, the user could still select the name for the blog, but was never prompted to create the blog and the subdomain of the blog is the user’s username.

    Not a perfect fix, but it works.

    #48607
    gen-superman
    Participant

    Your right, I tried this again and it worked fine… See, what I thought was that with this code, that the display name would be grayed out completely, which I don’t think it is for Admins, but regular users might see the box empty. Currently, users can still edit their display name from the bppress profile with this code, BUT when they go to save it, the changes won’t actually take place, which is a very good thing. I understand the purpose of having a login username and a display name, which I guess is fine for security purposes. But, for old school people like me, I prefer one username and one login name combo in one.

    Now, the user can still change their display name by going to the wp-profile area, and then choose which display name they want to go by. Which I guess is not that bad. But, I guess, I would still prefer to find a way to shut that off in the near future.

    But, then again, WP is so picky about using duplicate e-mails. I have not found a way to allow for users to register a new account with the same e-mail address. That can be a real pain in the rear, especially if you are testing the user registration process yourself. So, that leaves users that want to change their display name in the future with the option to change it in the WP-Profile area. Although, I prefer to find a way to shut that off entirely. But, I can’t just get rid of the WP-Profile link, because it has the ability for users to change their password and so far I don’t see a way for BP to allow users to change their password in the BP areas? Unless someone knows a way to add that option in the users BP-profiles or knows a link that leads directly to the option for a user to change just their passwords?

    I want to say that I am impressed that by adding this code to either its own blank .php file and placing it into the mu-plugins, that it worked so nicely. I did try it in the regular plugins directory and it did not take effect. I also had embedded it as you ‘Jeff Sayre’ had stated in the bp-themes template functions.php and that worked fine too.

    I then did one more test with this. I registered a new user through the registration process, and of course the Username field comes up due to WP requesting it and the BP-Display Name field comes up due to BP requesting it. Luckily, because of the code, it didn’t matter what the user entered in the BP Display Name, it would only recognize the username from the WP Username field in the registration. Which, yes I know, they are two totally different things, but I feel more at ease that this actually worked.

    Although, now users that register will be confronted with both of these questions, and I guess if they think their entering a display name for the BP-Field they will be very disappointed to find that their username will take default.

    So, for now, I guess the only remedy is by changing the label ‘display name’ that BP profile uses to ‘username’. Because, although a person enters a display name in the registration part of the BP display name field, it doesn’t show up in the WP-profile area as a nickname option. Either because of the code conflicts or BP wasn’t made to do that. Not sure. OR I guess you could just relabel to inform that display names can only be changed or created in your WP-Profile area… Oh… So confusing…

    My hats off to ‘Jeff Sayre’ and ‘Andy Peatling’. I truly hope that this might become an actual option in the newer bp press versions.

    #48586
    Jeff Sayre
    Participant

    I tried very hard to get this to work, and I can not get that code to work, even in the default template or even by creating a blank .php with pasting in the code listed above to upload to the mu-plugins directory.

    First of all you should not be placing the code in mu_plugins. Either place it in your bp-custom.php file, create your own plugin that resides in /wp-content/plugins/, or put the code in your member theme’s functions.php file.

    But, in the BP Profiles section, the users can simply change their login username to anything they want. This will obviously lead to database errors and people changing their usernames to cause conflicts.

    Where do you see the option in BuddyPress to change your login username? The only option you have is to change your display name. This is an entirely different piece of datum.

    Yes, when a user registers for a new account, if they choose to enter the exact same datum in the username field as the “Full Name” field, then that is their choice. But, this data is stored and used in different ways. The datum from the “Full Name” field gets placed in two different tables: it populates the display_name field in the wp_users table and it is recorded in the wp_bp_xprofile_data table corresponding to the meta field entitled “Full Name” in the wp_bp_xprofile_fields table.

    When a user decides to edit their “Full Name” field via BuddyPress, the changes to that piece of datum have no affect on the login username field stored in the user_login field of the wp_user WordPress table.

    So, on the same registration page, you have two questions requesting for what their username is going to be. This is quite ridiculous, and so far their is no way to shut that part off. Does anyone have any ideas?

    This is not correct. These fields serve different purposes as detailed above. One field is the user_login, the other is the user’s display name.

    #48560
    gen-superman
    Participant

    I tried very hard to get this to work, and I can not get that code to work, even in the default template or even by creating a blank .php with pasting in the code listed above to upload to the mu-plugins directory.

    I am very surprised that this worked for you, as I really needed this bad. Because, for some odd reason, in the WP-Profiles section, users are NOT allowed to edit their main username, but they can edit their display name, which is fine… But, in the BP Profiles section, the users can simply change their login username to anything they want. This will obviously lead to database errors and people changing their usernames to cause conflicts.

    So, this I consider is a major security risk, and there is no way to stop regular non admins from changing their usernames in the BP Profiles. Hey, at least WP got it right, by not allowing it…

    I’m not sure why the code listed above didn’t work for me. I have a totally different theme called, “Darkpress theme 1.1.”. But, I edited the functions.php file in both the themes directory and in the bp-themes where the themes are located. Because, there are actually two of the same themes located in two totally different directorys on the site. As there should be.

    But, I’m not sure if this code was suppose to go into an existing plugin or create it is as a plugin, as I tried an empty .txt file and copied the code listed above then uploaded it as a .php mu-plugin. But, that didn’t work, it honestly didn’t even recognize the code. Nor, did it change anything.

    So, does anyone have any ideas of how to STOP people from being able to change their “LOGIN Username” from being edited within the BP-PRESS profiles edit areas.

    One more thing, the WP-Registration profiles that request for new username and e-mail address, show up above the BP-PRESS profile questions and it also asks for the username. So, on the same registration page, you have two questions requesting for what their username is going to be. This is quite ridiculous, and so far their is no way to shut that part off. Does anyone have any ideas? This is quite frusterating… As, the regisration page should only ask one time for a username, but it seems that the BP-PRESS profiles is also asking for it.

    And yes if you fill out a different username for the WP-Registration username field versus the BP-Registration username field, the BP-Username field that was filled out will out win the WP-Registred username field.

    I am so confused, how do I fix this???

    #48558
    gen-superman
    Participant

    Since nobody has figured this out yet, I was wondering, maybe there might be a different way. Such as when people signup, it automatically logs them in upon signup. Then while it automatically logs them in, it leads them to the change the password/profile page.

    Although, it would be great to see buddypress profile section to actually have the option to change passwords, as right now we have no other choice but to edit the passwords in the wp profile area.

    Hopefully, somebody will get this figured out, as it is a horrible idea to send out e-mails in this manner, because most of the time the e-mail could get lost or placed into the spam areas or the e-mails can become delayed and users never check for it, or they just don’t bother to login because they are concerned that they may not have the option to change their passwords so readily.

    Time will tell. But, there needs to be a way to automatically log people in upon them creating their own account, then they can change their passwords as they like. Otherwise, if they don’t change their password right there upon auto login, they will still be e-mailed the password that the website created for them by default.

    #48477
    peterverkooijen
    Participant

    I had this test version of a reordered registration form. It works.

    But leaving the one fullname field as it is and splitting separate firstname and lastname to wp_usermeta using xprofile_sync_wp_profile() is probably the better solution – thanks Jeff Sayre and Nicola Greco.

    How would that work? Has anyone done it? Can anyone point me to code examples?

    I’ll try to figure this out myself, but don’t know where to start. Codex and bp-dev.org provide very little information. I don’t know where else to look.

    Why is this not built-in to Buddypress registration by default? It would make the system much more consistent, in particular with an added check to make a two (or more)-part name in fullname required.

    Everyone is always very quick to advertise the benefits of a single-sign on service, or a go-between to allow users to sign into your website using any number of different credentials, but there are a few major flaws with this idea, and they are going to become extremely apparent very soon.

    The first MAJOR flaw I see in this design, is that all it takes is one website to put up password stealing/sniffing code, and now you’ve given your twitter password to anyone with access to the sites malicious intentions.

    The second MAJOR flaw I see from a developers standpoint is that you as a site administrator no longer have control over the user data that is using your website. This means tracking down a problem user that creates an account with their facebook, you ban them, their google, you ban them, their open_id, you ban them, etc… That, along with the fact that these user registrations tend to add their own cryptic names into your database fields; now you’re forced to try to know who “fb8288373” really is, when had they registered the normal way, you could see they are “johnjamesjacoby.”

    From a user perspective, I don’t plan on using Facebook for the rest of my life, so when I delete my account in a few years, that means I can no longer use your site without creating a new profile.

    Also, if I’m logged into facebook on my computer, and close facebook, and then my girlfriend walks over to a site and clicks on facebook connect and continue, it logs her in as me because I am still logged into facebook. Now I’ve registered at a website that I didn’t want to register at, and I have no way to delete that account, and who knows what kind of information they’ve decided to store about me by this point…

    Quite frankly, I can’t wait for this trend to die. It’s a headache waiting to turn into a brain tumor in my opinion. :)

    #48422
    flynn
    Participant

    Hey all, sorry to bump and old thread, but it’s related, I promise ;)

    I’ve installed reCAPTCHA in the plugins folder, and it works brilliantly for comments. (For that matter so does wmpu-captcha in the mu-plugins folder) But neither seem to work on the registration page.

    Working – http://thompsonjason.org/2009/04/11/hello-world/#comments

    Not Working – http://thompsonjason.org/register

    Is there a bit of code that I should be inserting into my registration page to make reCAPTCHA show up. I’ve been getting a lot of spam accounts being created lately, so I really need to get this going before we can launch the site. Any help is greatly appreciated.

    #48390
    Jeff Sayre
    Participant

    I’m using bluehost.com and used their simplescripts to get it installed version 1.0.2

    I’m asking what version of WPMU, not BuddyPress.

    By the way, if you continue having issues, I’d advise avoiding using SimpleScripts. Read this entire thread for more details.

    #48388
    3349590
    Inactive

    I’m using bluehost.com and used their simplescripts to get it installed version 1.0.2

    #48386
    Jeff Sayre
    Participant

    @steveyb23

    So you are not even having success installing WPMU?

    Site Admin > Options > Allow new registrations

    This menu has nothing to do with BuddyPress. WPMU must be functioning properly before installing and activating BuddyPress.

    Which version of WPMU are you attempting to install?

    #48384
    3349590
    Inactive

    Ok, I tried installing and reinstalling and I can’t get or find anywhere: Site Admin > Options > Allow new registrations

    Any other ideas?

    This is a brand new install not adding to an existing wordpress account.

    r-a-y
    Keymaster

    Hey Dewey,

    Do you mind sharing your fix with us?

    Dewey Hulsey
    Participant

    Thanks r-a-y; after a bit of tweaking, I got the result that I wanted. Innovative approach to the fix.

    #48376

    In reply to: page after activation

    Jeff Sayre
    Participant

    The vast majority of registration functions are found in WPMU.

    What you are looking for is found in WPMU/wp-activate.php

    #48362
    peterverkooijen
    Participant

    One way off the top of my head would be to inject a JavaScript into the registration page – you’d use the BP name function to get what you want. There is already Wp code for “sanitizing” blog post names, and perhaps other areas too. Then it’s a matter of using the JavaScript to set the HTML field’s value, and CSS to hide it.

    Thanks DJPaul! That sounds doable. Would it be possible to put that in a plugin or would it have to be inserted in core files?

    Well, if you aren’t looking at how the underlying registration functions are coded, then how can you say with such certainty that this is not a WPMU issue?

    What I need wouldn’t touch the underlying registration functions. All I need is another way to insert that username into the database on registration. Hiding a field on a form is basically an html/css issue, stuff that I know enough about.

    Again, if the username would be generated from Buddypress’ required fullname field, it by definition is not a WPMU issue.

    Also getting a more consistent connection in how Buddypress and WPMU handle first name + last name is not a WPMU issue; it’s about how Buddypress (x-profile) hooks into and synchronizes with WPMU.

    WPMU does not allow you to position the username field in a different sequence–not without behind the scenes changes.

    I have already done that once. It’s no problem. It’s annoying WPMU mixes presentation and functionality in the registration, but I’ll work with what I get.

    Without contracting with a coder or coding yourself, you’re out of luck.

    I am trying to code myself where I can and am certainly considering contracting a coder. I need to figure out what I need exactly first. Also with these posts I’m trying to point out some imho weaknesses in Buddypress that should get more attention and judging from the private comments I’ve received I’m not the only one struggling with these issues.

    #48357
    Jeff Sayre
    Participant

    Hiding a field on a form is not that difficult. As long as the required data gets added to the database by some other means it doesn’t change the underlying foundation at all.

    As I said, I’m sure that with enough coding you code get this to work. But it might require core hacking. If so, that would be a change to the underlying foundation. I’m not sure without trying it so your best bet is to talk with the WPMU gurus on their forum.

    It is not a WPMU issue.

    The WPMU forum will just send me back here and rightly so.

    Whereas they may indeed send you back here, it is a WPMU issue. Just because you think it is a BuddyPress issue does not make it so. I’ve said that several times, DJPaul has said that, jjj has said that as well.

    WPMU’s functions take care of the underlying registration process. BuddyPress just hooks into that process, adding a few of its own fields and checks along the way. WPMU does not allow you to position the username field in a different sequence–not without behind the scenes changes. Of course it is easy enough to hide it via CSS, but whether or not you can then write data to it, bypassing WPMU’s field validation protocols is a different story. I have not tried that. I am not sure. But, it is a question that must be asked of WPMU, not BuddyPress.

    You said above that:

    I’m not really a coder. I understand I’ll need to learn from scratch or hire someone.

    Well, if you aren’t looking at how the underlying registration functions are coded, then how can you say with such certainty that this is not a WPMU issue?

    I have not spent all the time that I have responding to your various questions in your various threads to get rid of you. If I didn’t want to help, I would simply have ignored your posts. I’m offering you support and pointing you in the best direction for the given issue. You can choose to ignore my advice. That is your prerogative.

    Perhaps you’ve already spent time on the WPMU forums and did not get the response you have wanted. We’ve been as helpful as we can here.

    Without contracting with a coder or coding yourself, you’re out of luck.

    #48353
    Paul Wong-Gibbs
    Keymaster

    One way off the top of my head would be to inject a JavaScript into the registration page – you’d use the BP name function to get what you want. There is already Wp code for “sanitizing” blog post names, and perhaps other areas too. Then it’s a matter of using the JavaScript to set the HTML field’s value, and CSS to hide it.

    #48352
    peterverkooijen
    Participant

    But I’m not too sure whether you can remove–or hide as would actually be the case–WPMU’s username field from the registration form. WPMU is the underlying foundation of the system. It controls everything. With enough coding, I’m sure it would be possible–but not that sure on the practicality of doing it.

    Hiding a field on a form is not that difficult. As long as the required data gets added to the database by some other means it doesn’t change the underlying foundation at all.

    It is not a WPMU issue. I don’t want to change the underlying foundation. I want to use Buddypress’ fullname field to generate that username.

    The WPMU forum will just send me back here and rightly so.

    #48350
    peterverkooijen
    Participant

    If during registration the user actually enters their fullname–which means that there is at least a single space between their first name and whatever comes after that–then this function will parse the datum and create first_name and last_name meta pair entries in wp_usermeta.

    Making that required would solve a lot of problems and make the system a lot more consistent imho. As it is you can’t rely on wp_usermeta (or fullname…), so if you want real names you have to come up with complicated work-arounds.

    The full name registration field is already required. Why not put some standards on it? At the moment it is unclear, to users as well, what this field is for exactly. Display name? Another username? A blog name? A blog URL name?

    The function will parse it as follows, placing these entries in wp_usermeta:

    first_name: John

    last_name: James Jacoby

    Nothing wrong with that. It’s handy to be able to use the first_name separately, but I can’t think of scenarios where I would only use the last_name.

    Even if you wanted to use last_name by itself, you have to work with the information the user gives you. If the user wants to be a pompous ass and include his middle name, that’s his problem. ;-)

    First name + last name is an issue for me because I have to import a members list where this data is separate. So I need to make a decision what to do with that.

    You could do a check to make sure that there is at least one single space in the “Full Name” field before allowing the registration to be processed, but you will have no guarantees that they have used their real full name or that they have used just their first and last names.

    Facebook and LinkedIn don’t have those guarantees either. From my existing 600+ members list, built with a PunBB-based registration form, I know that most people will give their full, real names if asked nicely – I did need to add some code to capitalize the first letters.

    It depends on the etiquette of the site. If everybody is identified with their full names, new members will give their full names to be part of the club. That’s one reason why I dislike usernames. Emphasizing usernames teaches users wrong behavior, says it’s OK to identify yourself by BS pseudonyms.

    #48348
    Jeff Sayre
    Participant

    This is a nice and succinct accounting of what you are trying to achieve. Parsing a registrants first and last names from the BP “Full Name” field and then using that as the username would be a nice option.

    But I’m not too sure whether you can remove–or hide as would actually be the case–WPMU’s username field from the registration form. WPMU is the underlying foundation of the system. It controls everything. With enough coding, I’m sure it would be possible–but not that sure on the practicality of doing it.

    As I had suggested before, I would head on over to the WPMU forums and post a similar thread since this deals with hijacking, altering, and superseding WPMU’s registration protocols. That way, you will hopefully get some feedback on both fronts and find a possible, acceptable solution.

    #48346
    Jeff Sayre
    Participant

    So this synchronization only happens when users edit their profile after registration? Would it be possible to require the user to enter a more than one-word name in the fullname field and guarantee that synchronization with wp_usermeta always takes place on registration?

    Okay, I made a slight mistake in describing this process. I should not do support after 10 pm.

    If during registration the user actually enters their fullname–which means that there is at least a single space between their first name and whatever comes after that–then this function will parse the datum and create first_name and last_name meta pair entries in wp_usermeta.

    But, if they simply put everything together as a single word, then it will not have anything to parse–it needs a space and something following that space.

    But this is imperfect as jjj has indicated above. Let’s use his name as it appears in BP.org as an example.

    John registers for a BP-based site and enters this in the “Full Name” registration field:

    John James Jacoby

    The function will parse it as follows, placing these entries in wp_usermeta:

    first_name: John
    last_name: James Jacoby

    So, the system does work to some extent but you will have to ask all registering users to make sure they enter just their first name and just their last name with a single space between. If they also include their middle name(s), then those will be assumed to be part of their last name.

    Finally, if they choose to not follow the registration instructions, instead just merge their first, maybe middle, and last names together, then the function will not create the desired first_name and last_name wp_usermeta entries. Those entries will only be created if they latter edit their Full Name profile datum, adding a space between their names.

    So, if jjj instead had entered:

    JohnJamesJacoby

    There would be no entries in wp_usermeta from which you could extract his first and last names.

    You could do a check to make sure that there is at least one single space in the “Full Name” field before allowing the registration to be processed, but you will have no guarantees that they have used their real full name or that they have used just their first and last names.

    #48344
    peterverkooijen
    Participant

    Now, there is a function in bp-xprofile-filters.php called xprofile_sync_wp_profile() that will take the datum from the “Full Name” field and split it into a pseudo firstname and lastname and then insert that as meta data into the wp_usermeta table, but it can only do that if a user actually edits their fullname field to include a more than one-word name. So if a user does not edit that field, there will not be any fname/lname wp_usermeta entries for that user.

    So this synchronization only happens when users edit their profile after registration? Would it be possible to require the user to enter a more than one-word name in the fullname field and guarantee that synchronization with wp_usermeta always takes place on registration?

    Or would it be easier to use the full name field for first name and add a custom field for last name?

    (Please forget about the username issue. I’ll put that in a separate thread…)

    #48337

    Fact is, that BuddyPress can still only build off of the weaknesses of WordPress itself. What you’re trying to do can really only be worked around with smoke and mirrors, because WordPress itself doesn’t really care what your real name is; the fields exist simply to add depth to a username.

    Short of developing your own MU/BP plugin to shift the emphasis, you’re out of luck. Usernames are 100% necessary, because it’s how you login and out of the site, along with your password. Usernames cannot include characters other than alpha-numeric, so you can’t use an email address either. This means they MUST create a username. You could make a plugin or modify your registration to force the creation of a username based on two fields (first name + last name) but that means you’ll need to tell the user what your website made their login name to be, instead of letting them make their own.

    There really are only a hand-full of sites that don’t use some kind of username as a login, and in my opinion it makes more sense because not everyone uses the same email address for life, and what happens if I registered with my work email address and get laid off, and I need to login but forgot my password? Now my new password goes to an email address I have no access to. In this case, username makes the most sense, and is almost fail safe unless you’re REALLY having a bad day and forgot your username too.

    What about people like me, that like to use their middle names? I get no respect I tell ya! :D

    #48334
    Jeff Sayre
    Participant

    First off, I do sympathize with your frustration on finding an acceptable set of solutions to your questions. Without writing the code for you, it is difficult to point you in the proper direction. There have been a number of options presented, that while being a compromise to your ultimate, desired solution, could produce satisfactory results.

    Isn’t the whole point of Buddypress to turn the WordPress base into something more user-centric?

    Yes and no. As I already said two posts above:

    WPMU is not designed as a user-centric platform. It is blog-centric. BuddyPress puts the focus on the user.

    But, BuddyPress is still a layer that rests on top of WPMU, not the other way around. BP relies heavily on certain WPMU functions to handle much of the user registration process. And WPMU requires that the username field be populated (I realize that you know that).

    This thread is NOT about the username issue.

    I understand that. But what I quoted from your past post was about the username field and that is what I specifically answered in my last post.

    This particular thread is entitled “How to use full name, first name + last name“. Burt already provided an answer to this question above via this thread where he shows you how to do exactly this in code.

    I’ve understood all along in the various threads that you’ve started on this range of related topics that you want another option, some other way to insert your desired datum into the user_login field, or use newly created fields to allow registering users to enter their firstname and lastname, or that you want a way for users to enter their email for login, or a way to use BP’s xprofile table to display fname and lname in various ways and places, or a way to rearrange fields on the registration form, and that you hate WPMU’s concept of username and want a different option. I get all of this.

    Others (including myself) have tried to be as helpful as possible in each of those threads, often rehashing the same answers. I don’t say this to be mean; I say this because we’ve tried to explain in multiple ways and multiple times that what you are after is not possible at this time without hacking the core (in some cases) or writing your own custom plugin(s).

    https://buddypress.org/forums/topic.php?id=1746

    https://buddypress.org/forums/topic.php?id=1811

    https://buddypress.org/forums/topic.php?id=2118

    https://buddypress.org/forums/topic.php?id=2119

    https://buddypress.org/forums/topic.php?id=2926

    How does Buddypress handle first name + last name?

    It does and it doesn’t. There are no firstname and lastname fields in BuddyPress unless you create them as Mike Pratt explained above. BuddyPress has its own mandatory registration field that by default is called “Full Name”. Look in the BuddyPress submenu group in WPMU’s backend. Go to “BuddyPress > General Settings > Full Name field name”

    Now, there is a function in bp-xprofile-filters.php called xprofile_sync_wp_profile() that will take the datum from the “Full Name” field and split it into a pseudo firstname and lastname and then insert that as meta data into the wp_usermeta table, but it can only do that if a user actually edits their fullname field to include a more than one-word name. So if a user does not edit that field, there will not be any fname/lname wp_usermeta entries for that user.

    Buddypress puts a default first x-profile field Name on the registration form; is it possible to replace that with separate first name + last name fields?

    You can change the “Full Name” field name to whatever you want but you cannot remove that field from the registration page nor edit it to be something other than a single textbox field–at least not without hacking the core. Look under the “Basic” field grouping in “BuddyPress > Profile Field Setup” to see what I mean.

    Or is there already a native solution for first name + last name in WPMU that Buddypress could tap into? (Nicola Greco: ‘… you could replace it with the wp built-in name & last name, or use xprofile fields fot that …”)

    In this post above, I explained that if you want to go this route, you’ll need to pull data from two records in wp_usermeta to extract the firstname, lastname combination. If you do not feel comfortable coding this yourself, you could hire a coder to write a simple function to do just that. But be aware, as I explained above, it is possible that not every user will have firstname and lastname meta date.

    From your OP:

    Default Buddypress is fine for teens/tweens who want to use their anonymous username, but it’s not suitable for a more grown-up business network, for example.

    BuddyPress seems perfectly acceptable for business users. There are many professional, adult-based sites that are successfully attracting users to their BP sites. Mike Pratt’s site is a great example, for one.

    I’ve been using my full name on this site from day one. It did not bother me that I had to use a single username when registering because I knew I had the option to fill out my full name for display purposes later. It also allowed me to brand BuddyPress.org with my unique name, creating a useful URI in the process.

    In fact, the single username approach is what many sites use to allow users to brand themselves. Twitter, youtube, FriendFeed, Delicious, Digg, LinkedIn, and many more all require a unique, single-word username. Of course, some of these then allow you to (or even require) that you use an email for subsequent logins. This is in BP’s future as well.

    In the not too distant future, there may be an option to allow users to sign on with their email address via OpenID or another protocol. See the BuddyPress Roadmap and read about the Open Stack.

    But for now, your options are limited and if you want to change things you must code your own custom solution or hack the core.

    There is not much more we can do, but as I said in my last post, if the username concept bothers you so much, you’ll have to go to the WPMU forums and see what solutions might be in the works–if any.

Viewing 25 results - 7,301 through 7,325 (of 7,641 total)
Skip to toolbar