Skip to:
Content
Pages
Categories
Search
Top
Bottom

Search Results for 'questions'

Viewing 25 results - 2,001 through 2,025 (of 2,230 total)
  • Author
    Search Results
  • #48743
    Jeff Sayre
    Participant

    Hum. Interesting. That error message is often associated with someone trying to run BuddyPress with the single-version WP. It would have made this issue a lot easier to resolve had that been the case!

    Okay, here are some additional questions (besides the ones asked by DJPaul):

    1. How (and from where) did you download WPMU?
    2. How did you install it?
    3. Was WPMU functioning properly before trying to install BuddyPress?
    4. Have you checked your server’s error logs for other errors? If there are errors, what are they?
    5. Do you have any other WPMU plugins installed and activated?

    #48676

    In reply to: Buddypress Fatal Error

    thebigk
    Participant

    Hello everyone!

    First of all, thank you for your responses. The problem is now solved. However, I don’t know how! I wrote to the web host describing the problem and to the best of my guess, they changed few PHP.INI settings [Don’t know how it got messed?]

    The system did not have bbpress. I’ve upgraded buddypress to latest stable and everything seems to be working fine now.

    To answer the questions :-

    1. Are you running WPMU 2.7.1 or WordPress 2.8? You mention that you were running WPMU before. Did you upgrade to the beta version of WPMU 2.8 from trunk? Or, did you accidentally upgrade to WP 2.8? WPMU 2.8 is not yet in public release.

    -> I did not upgrade accidently. In fact, one of the members reported that there was an error. The system was running fine with WPMU 2.7.1 and BP 1.0 (the first stable release) and then suddenly the error popped up.

    2. What other plugins besides BP do you have activated? Have you tried removing them all except BP and see if you can get back to the plugins page?

    -> I do not have any other plugin than BP.

    3. Have you tried removing BP and then seeing if the plugins page returns? If it does, then deactivate all other plugins and reinstall BP. What happens?

    -> No, I didn’t try that. I could not deactivate any plugins, because I couldn’t see the plugins in the admin panel!

    From the overall experience, it looks like the issue was with me signing in as site-admin but ending up in blog admin panel (anyone knows why this happened?)

    #48669

    In reply to: Buddypress Fatal Error

    Jeff Sayre
    Participant

    I agree with Burt. My three questions and suggestions were going to be this:

    1. Are you running WPMU 2.7.1 or WordPress 2.8? You mention that you were running WPMU before. Did you upgrade to the beta version of WPMU 2.8 from trunk? Or, did you accidentally upgrade to WP 2.8? WPMU 2.8 is not yet in public release.
    2. What other plugins besides BP do you have activated? Have you tried removing them all except BP and see if you can get back to the plugins page?
    3. Have you tried removing BP and then seeing if the plugins page returns? If it does, then deactivate all other plugins and reinstall BP. What happens?

    #48622
    Jeff Sayre
    Participant

    @catincoach

    The ability to promote a group member to admin is in the works for version 1.1!

    See the BP roadmap: https://buddypress.org/about/roadmap/

    #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???

    3125432
    Inactive

    Hi Burt,

    Uploaded and installed bpc 1.0 no problem. Couple of questions:

    I see the parent and child category features. Great! Why the option to click both, versus just one or the other? Just curious. Explanation: parent category is ‘COUNTRIES’ and child is ‘United States.’ I can select ‘United States’ without selecting ‘COUNTRIES.’

    After adding the two categories described here to a group, I clicked on the just categorized group. The group profile shows tags but no categories. An ommission or a decision?

    Thanks for your hard work.

    Brian

    #48528
    TheEasyButton
    Participant

    I have a couple of questions because I still can’t get my discussion to activate in groups. Integration is fine, but that dang “you must configure forums” warning won’t go away no matter what combination of codes & plugins I use.

    1. “Upgrade to bbpress 1.0”

    Upgrade from what? I’ve never been able to get an RC version to work so I’m running alpha 6.

    2. By upgrade, do you mean install the new version or should I find an upgrade button somewhere? (not seeing one on alpha 6)

    3. Buddypress enable plugin (from buddpress>>bp-forums)

    Where did you put this? In my-plugins or bb-plugins or nowhere?

    4. “Go into bbpress admin and the wordpress integration settings. Fill out the forms properly”

    Anytime I EVER EVER (haha) try to change stuff in there, it totally boots me out of all of the bbpress logins. No login name/pw will work.

    That’s it for now but I’ll probably be back with more questions. =D

    **Edit — #5 (told ya I’d be back) Did you put the “allow user switching” code at the bottom of the bb-config?

    Thanks =D

    #48448
    Jeff Sayre
    Participant

    Please answer these questions: https://buddypress.org/forums/topic.php?id=2674

    #48391
    Jeff Sayre
    Participant

    Since you are talking specifically about altering how WPMU deals with blogs, I’d suggest posting this question on the WPMU forums so that their gurus can answer. Whereas you might receive an answer on the BuddyPress forums, the WPMU forums is the more appropriate place for such questions.

    I advise that you first do a through search of the Mu forums before posting.

    https://mu.wordpress.org/forums/

    #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.

    Firstly, in response to the post you made that got me here (which I deleted out of respect for the topic starter,) please don’t ask for help in someone else’s topic. Everyone’s questions hold the same water here, and we’re all drinking from the same cup. I have no idea what that means, but it sounds like a good analogy. :)

    If what you want to do is replace the word “Blog” all through-out a BuddyPress install, you’re going to need to modify the template in a few places, as well as some core files that gettext that out for you.

    I haven’t really tried tricking the gettext into translating specific words for me, but I bet it’s possible to do, albeit probably not easily.

    #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.

    #48249
    Jeff Sayre
    Participant

    @notme31

    Are you having the same issue as the original poster? If not, you should start a new thread as this thread is marked as resolved and few people will pay attention to new support questions in resolved threads.

    #48151
    Jeff Sayre
    Participant

    Okay, why don’t both of you go through this list to see if there are other commonalities:

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

    Please post your response to those questions here.

    #48062
    dainismichel
    Participant

    Hi Jeff, I did not notice that this was marked as resolved. I still don’t know how to create a buddypress install with a cohesive theme for members. I’ve been checking every week or so to see if someone may have answered my questions about what it is I’d need to hard code. I’ll check to see which theme I modified and I’ll see if that makes a difference. I’m still looking to distill a procedure out of this that I can follow and share with others. Best, Dainis

    Thank you very much for responding. I really appreciate it.

    #48022
    3262389
    Inactive

    This should really be in the readme, forums are a huge part of social networking, and I will be developing a tightly integrated BuddyPress and bbPress application over the next few months. I’m sure you will see a lot of questions from me, and I look forward to helping out along the way.

    Jeff Sayre
    Participant

    Well I just stuck this in to be absolutely sure:

    /* Array Test */
    echo is_array($bp_meta) ? 'Array' : 'not an Array';

    I placed this just after $bp_meta is set and the test does come back indicating it’s an array so that is all that really matters.

    I then placed this after the offending $bp_blog_signup_meta line:

    print_r($bp_blog_signup_meta);

    It looked fine. Data from both arrays were being properly merged.

    So, I don’t think from my cursory investigation that this is the PHP5 array_merge() issue.

    @Josswinn

    A few questions:

    1. Does this occur in all browsers or just some?
    2. Do you have cookies disabled?
    3. Which version of PHP are you running?
    4. Which version of Apache?
    5. Which version of WPMU?
    6. Which version of BP?
    7. Are there any other errors in your log files?

    #47877
    Jeff Sayre
    Participant

    Well, we have insufficient information about your setup. Please answer these questions.

    #47776

    In reply to: BP Messaging Question

    Mike
    Participant

    this post might help you answer some of your questions… https://buddypress.org/forums/topic.php?id=3204

    #47715
    Jeff Sayre
    Participant

    @Sean

    Are you still having this issue? Everything looks fine when I visit the link you’ve provided.

    If this issue is resolved, please set the light on top to green. If not, please answer these questions: https://buddypress.org/forums/topic.php?id=2674

    #47710

    In reply to: 3 questions

    Jeff Sayre
    Participant

    Home themes need to be located in:

    /wp-content/themes/

    Member themes need to be located in:

    /wp-content/bp-themes/

    Read this for more info: https://codex.buddypress.org/getting-started/installing-buddypress/

    #47706
    Jeff Sayre
    Participant

    We need to understand your server and software environment. Please answer these questions: https://buddypress.org/forums/topic.php?id=2674

    #47704
    ITguy
    Participant

    Jeff, thanks for the quick response, here are my answers to your questions:

    1. No, I am using the default BP themes for home and members.

    2. No.

    3. Yes there are plugins installed => bpPictures, Sitewide Newsletter System and Community Blogs. I did disable them without any change in behavior.

    4. Good suggestion, I did now go through the error log after repeating the steps and found no errors reported.

Viewing 25 results - 2,001 through 2,025 (of 2,230 total)
Skip to toolbar