[Peter Kirn]

Yeah, I’m giving Humanity a try — seems to be quite effective.

There’s a big thread here:
https://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/buddypress-spam/?topic_page=6&num=15

Also trying to get this group active again:
https://buddypress.org/community/groups/spam-eater/home/

Nice name. Needs some spam-related icon, though.

[Peter Kirn]

Incidentally, I still like the idea of getting folks together in a BP Group to attack the issue. I had suggested starting such a group on an IRC chat a few weeks ago, but I see now that there *is* a (small) group someone had set up. If people are interested, we can use that. Or maybe it’s fine to just continue this thread for now, though not having to dig through a few dozen posts has some appeal.

https://buddypress.org/community/groups/spam-eater/home/

[Peter Kirn]

jwack – since you had such trouble with this even after taking some measures, what was the final regimen you installed for blocking spam?

[Peter Kirn]

Hi Jeff, I can’t make the chat Wednesday as I’m going to be on a plane between London and Hamburg, but I wanted to add to this:

1. wp-recaptcha — I’m working with the developer of this plug-in so that we have one fork that works everywhere, BP included. Given that this is the topic, let me try to get that basic code up. Even with simple recaptcha support, there’s a huge decrease in spam signups. It seems not to solve the smartest scripts, the ones that send PMs (at least not on our site), so I think once we get one recaptcha working, making the “failed” recaptchas more intelligent to avoid these automated bots would be great. Thanks for the ideas above — this is great fodder — so I’d encourage people to get involved on the same fork so we can put this into action sooner rather than later. Let me post a separate update within the next couple of days.

2. Since PMs are a big problem, and this thread is getting very, very ambitious, why not at least begin testing this with a separate plugin? I’d like to at least see something that stops mass-mailings and highlights that user, as that’d be an easy way to weed people out, at least as more comprehensive solutions are developed.

3. Reviewing core is probably worthwhile. A mistake in bp_signup_validate’s code was being exploited by hackers. I know this is part of 1.2.4, but I went ahead and applied the diff attached to this (now-closed) ticket to our current 1.2.3 install:
https://trac.buddypress.org/ticket/2289
— this made a big difference. I wonder if anything else follows this pattern, and how we might hunt it down.

Grand, wide-reaching plans sound terrific, but I’d hate if that derailed some short-term fixes; seems we can have both.

[Peter Kirn]

@r-a-y: Excellent. Let me refactor the code accordingly, as I think we’re in agreement that the ultimate goal is to do one wp-recaptcha that works everywhere. I need to actually go off the new 3.0 codebase from Blaenk, anyway; won’t be hard to do that. Once I have a new version up, I’ll have it in Git; that way, other BP users can look at it and try it out before there’s an official release bringing wp-recaptcha and the temporary bp version back together later this summer.

[Peter Kirn]

Scratch that — spoke to Blaenk, and I’ll just contribute to his project. So R-a-y, if you have any more thoughts for improvements looking at that, let me know, as I’ll try to clean this all up this weekend and make it less of a hack.

The beauty of Friday evening (and maybe Mercury is no longer in retrograde), everything’s coming together.

[Peter Kirn]

Full code…
http://pastebin.com/mWUALgdD
And again, apologies if I’m a bit slow on this stuff; as I said, part of why I wanted to tackle this.

[Peter Kirn]

Just tested it; that code does indeed work. I did need to then add an error display function, of course; right now that looks like this:
http://pastebin.com/v65A8mrk

Some cleanup to do on CSS, but otherwise this is functioning! Thanks!

I’ll keep you posted.

[Peter Kirn]

Hi Ray,
Thanks for that help! That’s great; now much clearer to me. Huge help!

I did email the author. I haven’t heard back yet. I’m not intending to release a fork without permission.

In fact, on the contrary, my main goal here is just to learn a bit about BP development before we move on, and to make sure there’s some kind of solution – even as a stopgap – to allow switching on BP blogs without a torrent of spam. That’s made our registration system effectively unusable. I was unaware of some of the other options, but to be perfectly frank, I think it’s unacceptable that there isn’t at least some option in core. (It’s the situation that had been Akismet in the 1.x days of WP.)

But that, and since you’ve posted a lot of good info in the forum, happy to go through it and through the eyes of someone to whom this is new, try to format it in a way that could be friendlier to developers.

I’m in absolute agreement that releasing a zillion forks is not a good idea. I’ll keep testing here and document my experience but will refrain from releasing anything until I hear back from the author.

I think that’d be the next question, whether this conditional code gets rolled into the main wp-recaptcha plug-in. In that case you’d leave the WPMU and “legacy” WP checks so you’d have one recaptcha plug-in to rule them all, which is probably best.

Peter

[Peter Kirn]

PS, I think now based on your other posts I can help with that wiki documentation; it’d be my pleasure — I just have to understand what I’m doing *before* I document it, not the other way around. (and then happy to have you tech edit it to see if I’ve gotten it right)

[Peter Kirn]

Here we go, here’s the issue: I understand how to hook in now, and I’m correctly writing errors to $bp->signup->errors. I’m just unclear on how to accurately display those errors for the ‘captcha’ field. Right now, my signup is validating properly and even recording the correct errors; I just can’t display the errors on the actual form. (Doh!)

Here’s my display code:
http://pastebin.com/QcMXCTGz

Here’s how I’m recording errors (which is in fact working):
if (empty($_POST) || $_POST == ”) {
$bp->signup->errors = __( ‘Please fill in the reCAPTCHA form.’, ‘buddypress’);
}

And for context, the whole plug-in, though most of it’s the old wp-recaptcha code (I’ll clean this up and put it on GitHub shortly)
http://pastebin.com/urNP96Nz

[Peter Kirn]

Okay, very nearly there. I now have registration working – unless you don’t enter the captcha correctly, in which case I get a page not found (curiously, still for /register) Any sense why this might happen when porting code from WPMU to BP?

So obviously more work to do. But it’s at least part way there.

[Peter Kirn]

Sorry, I realize I read that last post incorrectly.

I’ve dug into the code myself and have nearly everything working, but I’m unclear on the function for bp_signup_validate. In the WPMU plugin, there’s already validation checking for WPMU. Why not simply use:
add_action(‘bp_signup_validate’, ‘check_recaptcha_wpmu’);
?

For the WPMU code, this is called as a function:
add_filter(‘wpmu_validate_user_signup’, ‘check_recaptcha_wpmu’);

— and it looks like the same code you’d need for BP:
http://pastebin.com/MX0LHmtE

Am I missing something? Is there something else BP needs? It appears to me that the bp_signup_validate action lacks documentation.

[Peter Kirn]

Hi r-a-y — would you be interested in posting your validation function code? (pastebin it perhaps?)

Just want to avoid reinventing the wheel. I also found a plugin in bpdev that appears to be doing this, as well, even down to adapting the existing WPMU recaptcha plugin, but it doesn’t seem to work / was never finished. I haven’t worked out just why yet, however.
http://bp-dev.org/download/

You active bpdev-core and then bpdev-nospam.

[Peter Kirn]

Hi John – thanks for the detailed response. I did read the documentation. The problem is – and I didn’t realize this until after my first attempt at the upgrade was finished – that documentation doesn’t appear to cover the scenario of an existing, integrated bbPress setup with bbPress stored in a *different* database. So, initially, I tried to choose the existing installation. When that didn’t work, I went back into admin and chose the option that allows you to try again with a fresh installation. What I’m trying to fix now is a *new* bbPress installation – but with existing groups.

Certainly, what you describe makes absolute sense. So now, I’m just looking for a resolution. I’m not concerned about existing forum posts; I think we can start fresh.

I’m looking now at the database. In wp_bp_groups_groupmeta, I see id and group_id.

In wp_bp_groups, I see id and enable_forum.

But enable_forum is the boolean for that checkbox. I don’t see where the forum_id is stored; it’s not listed as a field in either of those tables. Do I need to look at the bbpress table? How is the forum id matched up with the group id, since that seems to be the issue? Presumably if I delete the fields for that metadata, then disable the forum option for each of the groups, then re-enable, it should create new forums, yes? But where do I find that forum ID metadata, or can I actually simply delete the metadata for each of the groups that has a forum?

[Peter Kirn]

Now I feel bad that I ran out of time in late August / September and was unable to contribute to the test process, but that’s how it goes some of the time.

The reason I ultimately opted for a fresh install, even with existing groups, was that I discovered the option to *migrate* an existing install a) left bbpress as a separate install, which I didn’t want, and b) because we had opted to put bbpress’s tables in a database separate from the wordpress mu database.

So, the question is, how do we take these existing 25 groups and give them forums to connect to in the new bbpress-in-buddypress setup?

[Peter Kirn]

copgarden: What were you upgrading from? How was your forum set up prior to the upgrade? I’m guessing there must be something different in your setup relative to mine.

Update – I have tried creating a NEW group and posting to that. That works fine. So I suspect that perhaps the issue is that the previous groups are trying to point to our old forums installation? I just need to figure out how to revert our existing 25 groups to whatever

In the database, how does BuddyPress 1.1 point groups at the appropriate forum in its new integrated bbPress install?

Actually, as I think about this, it makes sense that this didn’t work. Presumably, when you opt for a fresh install, it sets up bbPress inside buddypress but does not try to create any new forums. So how can I force those groups to create new forums, I wonder, if checking / unchecking doesn’t work?

On the same lines, for some reason – even though I opted to do a fresh install – the Forums link on the main homepage is still trying to point to our old forum install (that is, domain.com/forums).

http://noisepages.com

[Peter Kirn]

Hi John,

You mean in the admin for one of my actual groups, correct, not the admin for the whole site?

I’ve tried disabling, then re-enabling the forums option in one of my groups. Unfortunately, this seems to have no effect – same symptom. And nothing showing up in my Web error log, either, so I’m having a tough time even telling what’s wrong.

Is there a brute-force way to reset the groups’ forum option to zero, perhaps in a way that would be more effective than just unchecking this option? Any other way to gather some data on what may be happening here? Thanks!

[Peter Kirn]

Ah, never mind. I’ve done some more tests and the problem is that GD isn’t finding the libjpeg library – so it was the obvious problem. Because WP core uses jpeg for all its writing, well, that pretty much breaks everything. My fault.

I think I’ve also sorted out how to properly build libjpeg on a 64-bit FreeBSD system. It seems you need the ancient patches for libjpeg, as seen here…

http://cblfs.cross-lfs.org/index.php/Libjpeg

[Peter Kirn]

I’ve double-checked my GD / libpng / libjpeg install, and as near as I (and phpinfo) can tell, everything is fine.

It’s definitely failing on the cropping code. Images are all uploading successfully, but not their cropped versions. So when BP goes to look for the cropped versions that are the correct sizes, they’re not there — regardless of the size of the original file.

This also now truly rules out the upload issue (though that bug trac is interesting).

Any chance that detritus from our RC test is involved with the new BP stuff? Other things to check? I’m just running out of ideas.

[Peter Kirn]

Hi Jeff, thanks for your help – I’m still investigating.

1. File size seems not to be an issue, as we’re not seeing it work properly – ever. Maybe 50-100k, typically?

2. Again, seems not to be an independent factor, and neither jpgs nor pngs are working; they’re just exhibiting different symptoms. But both show up in preview, yet neither is getting used as the avatar.

3. 15000 kb max upload size.

4. Allowable formats: jpg jpeg png gif mp3 mov avi wmv midi mid pdf zip

So I guess that rules out the easy solutions. Sounds to me like maybe this is still some strange Gd/libpng/libjpeg issue — even though they’re working elsewhere, I wonder if for some reason BP is calling them differently? Maybe time to do some PHP image processing tests, independently?

Is there anywhere in which the developer side is documented; i.e., so I can check out on the back end how BP handles this as I look at the code / functions?

[Peter Kirn]

I should add, of course, that non-cropped images aren’t a possibility with the avatars per se — the avatars require cropping.

And some images seem not to be getting uploaded at all. I’m guessing the ones that I’m seeing in the directory were the ones initially uploaded when someone first created a user or group?

Is there no way to disable the cropping routine? Or to delete an image once it’s been added to a reference?

[Peter Kirn]

Hi Jeff,

Right, that makes sense — it’s effectively coding the exception into the URL, get that.

Basically, what works:

* uploading an image that’s the correct size (regardless of format)

* uploading an image and getting as far as on-screen cropping

What doesn’t work:

* the cropped image is not getting written to the directory (jpg)

* editing avatar images is not properly updating the URL reference in the database (png)

(and then that breaks the avatar if people use the wrong image size)

I’ve just tested this by editing the avatar on one of our groups. png vs. jpg is not an issue. If it’s a size other than the correct size — i.e., if it brings up the cropping interface — it just doesn’t work. It crops the thumbnail, then the full-size image — both correctly. It just seems not to be actually writing out the file.

So, with the jpg, I get dumped to a page that says “The group avatar was successfully updated.” Except that the image hasn’t updated, and if I navigate to that directory, no jpgs whatsoever have been written. The URL is

http://noisepages.com/wp-content/blogs.dir/1/files/avatars/2/oscemote.jpg’%20is%20not%20an%20image.

— which is correct, oscemote.jpg in this case actually is not there. That seems especially odd to me, that even the uncropped jpg is apparently not getting uploaded to the directory.

With the png, I get dumped to a 404 error — it correctly creates both the full-size and thumbnail images on-screen, but at the last step I get a 404 on the group avatar editing page.

The png’s actually ARE in the directory. So I have what is apparently the full-sized image, plus the cropped one — oscemote-300×450.png

But the avatar itself isn’t actually changed in that place; the URL is still pointing at the JPG.

[Peter Kirn]

Actually, one note – as I look again, cropping jpgs in the upload facility seems not to work; could that be a symptom of a libjpeg issue (which in turn might prevent those jpgs from getting created in the avatar)?

[Peter Kirn]

We’re likewise interested in this capability. I guess at the very least, everyone has the same basic goal for the functionality — each user of WPMU would be able to define a localization and language. John, what would be the best place to look if people were interested in contributing to testing patches / tracking this development? Ultimately, is it likely some combination like Jalien is suggesting will work, with other changes in the BP/WPMU backend?