Forum Replies Created
-
Ray, you’re right that WPMU (or is it BP?) strips caps on registration. But these users came from a previous bbPress installation (where caps were allowed).
I guess I could make user_login = user_nicename for all of these users, but I would like to ensure that the lack of caps support for user_login is a limitation on WPMU and not just a symptom of some other problem.
I have checked and the users have the correct role. The situation is as simple as this (using phpmyadmin for the user with user_nicename = “reboot”):
– if I set login_name to “reboot”, I can post
– if I set login_name to “Reboot”, CAN’T post
– if I set login_name to “rebootzzz”, I can post
– if I set login_name to “rebootZZZ”, I CAN’T post
UPDATE: it really is about the caps. For user_nicename “reboot”…
– user_login = rebootzzz CAN post
– user_login = rebootZZZ can NOT post
– user_login = Reboot can NOT post
I have started a thread on the bbPress support forum too.
korhanekinci, I think you may have a different issue that warrants its own thread. Particularly if you are on 2.8.1. I have something very specific going on here: only users WITHOUT caps in user_login can post.
korhanekinci, yes, I did add those four lines that the bbPress Integration plugin suggested.
I also defined WP_AUTH_COOKIE_VERSION. Without this line the cookie integration doesn’t work at all.
Like I mentioned above, my current clue is that only users who have NO caps in their “login_name” (field in the wp_users table) can post on the forum.
Now, WPMU strips caps from the username when people register, but I have bbPress users that pre-dated the WPMU integration and they do have caps in their login_name.
One other datapoint to add: I tried a standalone installation of bbPress 1.0.1 and it doesn’t have this problem. Users with caps in “login-name” can post fine.
I’m closer to figuring this out. I originally created the “wp_users” users table by copying in the table from a bbPress install (i.e. from “bb_users”).
In “bb_users” the user_login field can have caps, but the “user_nicename” is all lowercase.
It seems that users who had no caps in their user_login field can post. But a user with names like…
– user_login = RebootNow
– user_nicename = rebootnow
..can’t post.
I previously had BP integrated with bbPress 0.9.0.5 and this wasn’t the case. All users could post.
Does anyone have any idea whether this was an intentional change?
At this point I am questioning everything. Following Burt’s updated integration instructions there is only one point where I have the slightest doubt. In the bbPress admin page for WP integration, it says the following about the SALTs:
This must match the value of the WordPress setting named “auth_salt” in your WordPress site. Look for the option labeled “auth_salt” in this WordPress admin page.
There are no SALT values in “/wp-admin/options.php”. So I put values like the following in wp-config.php:
define(‘AUTH_SALT’, ‘XXX’);
define(‘LOGGED_IN_SALT’, ‘XXX’);
define(‘SECURE_AUTH_SALT’, ‘XXX’);
…where the XXX values came from “https://api.wordpress.org/secret-key/1.1/”. I have corresponding “BB_” entries in “bb-config.php”.
Nope, I just replaced all the files from the distribution and non-admin members still can’t post.
As far as I can see, *everything* works except posting on the forum (only admin can post to the forum).
– logging in and out to both forum and bp
– sending messages
– commenting on the blog
– modifying the profile
I have looked at the cookies in FF and can’t see anything obvious wrong.
I will upload the files again. Don’t think I’ve changed anything in there, but worth a try.
R-a-y, thanks for checking, but yes, I have done this.
Like many things, this wasn’t as hard as I initially thought it would be. I replaced “xprofile_edit()” with my own version “_xprofile_edit()” that I put in functions.php.
I removed all html output from the new function and put it in a variable instead. This way I could call my “_xprofile_edit()” before the header in /profile/edit.php (in the member theme) and use “wp_redirect( $bp->loggedin_user->domain )” to send the user back to the profile page if their input was valid.
My new function returns the html markup for the form, which is rendered where the theme previously called “bp_edit_profile_form()”.
My one slight concern is that I had to change the call to “wp_nonce_field()” in the function. I can’t allow it to echo anything, since this code is run before the header, so I set the last parameter of “wp_nonce_field()” to $echo = false. I understand the nonce in principle, but I’m not quite sure what this echo was achieving in the first place, so there is a chance that I have removed something that was important for security.
Any thoughts on that would be appreciated.
Ok, this is working for me too. I see that updating the BP “Name” field also results in an update to the “display_name” field in the wp_users table.
FWIW, I’m not using deep integration.
Thanks r-a-y.
BTW, I have some questions regarding the perf impact of deep integration, but I will start a new thread for that.
Sorry, I haven’t experimented with the facebook connect plugin.
No problem. Thanks Burt for the idea.
BTW, I realized why functions.php wasn’t working by default in my case. I am currently integrated with BBP 0.9.0.5, which didn’t have this feature – it was introduced in 1.0.
There is a very delicate balance here because on one hand all of the developers leveraging [Word/Buddy/BB]Press are getting an enormous head start compared to building something from scratch. So we should all be enormously grateful for that. I don’t think threats to move another platform are really productive.
At the same time, critical feedback and vigorous debate will make the product better. I don’t think this should be characterized as moaning. Active threads on the membership architecture would be great to see (I know Peter has tried to start a couple of those).
Most people here would agree with Peter that the WPMU+BP membership functionality is not ideal. They would probably also agree that Andy’s compromise is a good one under the constraints of WPMU. BuddyPress will be a good forcing function to make that improve though.
Adopting some strict framework is not the answer. The trash heap is piled high with projects that had high architectural ideals. The successful stuff delivers a good user experience, often with frightening hacks under the covers, but over time becoming more robust and beautiful inside too.
There is a key architectural aspect to *Press that makes it successful though – extensibility. The hooks make it possible to hack the system to do so many things that weren’t even considered when the projects were originally conceived. Andy has exploited the extensibility in WPMU to bend it into a social networking system. He has also been religious about putting hooks everywhere to give us the same opportunity with the things we in turn build on top of BP.
As long as we are all being creative on *Press, things won’t be pure. Andy will be bending WPMU to his will and we will be bending BP to our will. That’s the beauty of it.
I was hoping for at least one independent confirmation of the issue, but your wish is my command. Ticket #840 in trac.
I just realized that JJJ’s question a few posts up is directed at me.
@JJJ, No, I haven’t changed these settings in wp-config.php.
Does messaging use cookies? And if so, would it have this result? Just to reiterate, it is not only that mail doesn’t get sent to the second recipient. No message gets sent at all to the second recipient (they don’t even appear as a recipient in sent items).
And I have repro’d the issue on tesbp.org.
Bumping this to see whether I am the only one who can see this fairly basic bug. I have repro’d on a site with no customization and standard themes, and on testbp.org.
Well, I found a workaround, but I’m really nervous about unintended consequences. I went into the db and changed “is_required” on the “Name” field from “1” to “0”. Now I can register without the extra profile fields.
It seems that the name field gets set to the username, which is what I need.
Any thoughts about the unintended consequences of this?
Thanks.
Jeff, fantastic, this works.
Just to make sure I understand *why* it works… by just running the remove_filter() function in bp-custom as I was doing earlier, I guess it was running before the filter was added. What you are doing is delaying the remove_filter() call until all plugins are loaded.
Do I have that right?
Thanks very much.
I went over to testbp.org and this issue repros there too. When sending a message to two people where the first one is added to the “to” line using the “send message” button and the second person is added manually, the message only goes to the first.
@JJJ, did you follow exactly the repro steps that I provided?
@Burt, thanks – I used the auto-upgrade and had forgotten the about the theme directory gymnastics that one needs to do at the end of an install.
Thanks all. Just to clarify, it is not only a question of the email message not being sent. The private message itself is only sent to one of the recipients. It is as if I only had one name on the “to” line.
Also, this was an upgrade from 1.01. I assumed that the member themes were automatically upgraded too, but it sounds like that was a bad assumption. Did they change between 1.01 and 1.02?
Thanks Jeff.
So to sum up, I have the following line in “plugins/bp-custom.php”
remove_filter( 'bp_get_the_profile_field_value', 'xprofile_filter_link_profile_data', 2 );But the links still appear on my profile page. I can remove the links by commenting out line 15 in bp-xprofile-filters.php, but I’d love to get this right without the mod to a core file.
That’s pretty scary. Good luck.
Sounds like your buddypress directories aren’t there. Can you ftp into the site and see buddypress in your plugins directory under “wp-content”?
Have you done any recent administration on the site? Major changes, minor tweaks?
