Forum Replies Created
-
Adding BP_REGISTER_SLUG worked in terms of now the signup form is on a new page (the new slug) *but* the wp-login.php?action=register still points to /register which of course shows a “page not found” given the new slug is not “register”. I checked everywhere that I thought could be a “register” URL setting and the .htaccess but there is none. Where does that “/register” direction come from?
Awesome, thanks!
Adding that function was the solution. Now it all works again as supposed to, being able to choose what to show on the frontpage:
– Activity stream
– Page
– Post
The previous version worked as supposed to, for accounts created with the default signup page and all activities for those accounts. Also, for all other accounts (created via Gigya) each time I hit the retro button manually. No errors with that version.
I use latest WPMU and BP with Achievements 1.2.
Previous achievements worked fine except for the error (this thread is all about) and it didn’t catch (same as this version) accounts created by plugins instead of the default signup page.
I upgraded to the latest version and it stopped working. Then I removed it, installed again but it still failed. Problems:
– no achievements collected
– no retro-achievement when manually triggering the retro function as per your instruction of editing/saving an achievement.
When I click the save button on an achievement editor page, the following error occurs:
“There was an error updating the database; please try again.”
Editing achievements and saving results in
“There was an error updating the database; please try again.”
No retro-activation done after that.
The new achievements moved the admin menu link into the BuddyPress group but now I can’t find the retro-activate function anymore. Is that gone?
It’s important when the site uses Gigya’s login as accounts created that way are not (or were not in previous releases) registered by the Achievements plugin until after running the retro-activate manually.
Any news on this call_user_func_array() issue?
I have the same problem but it’s not so much the issue of spammers coming to the site than non-working defense measures.
I have failed to find any reasoning behind the dropping of wp-signup.php and replacing it with /register (what’s the .php file for that btw?) in BuddyPress but that’s the reason for a lot of spam problems.
When you install a number of WP and WPMU anti-spam plugins, they add their own features to the signup page – which in WP and WPMU is wp-signup.php.
Now as it has been pointed out in about all spam-related posts, people even delete that file with no success to the spam issue. This confirms the problem that I believe could reduce the spamming significantly:
– WP and WPMU anti-spam plugins do *not* have any affect on the BuddyPress /register page.
Is it because some hooks are missing? I’m not sure as I’m not that deep into it but I think so.
My request to solve this problem and address the spam issue:
– either BuddyPress will return to use wp-signup.php, or
– makes sure that anything added by plugins to wp-signup.php is also added to whatever page is serving the /register URL.
No matter hashcash, captcha or security question (all nice and working (with wp-signup.php) plugins), they can’t add their stuff to the BuddyPress signup page.
Why I don’t use wp-signup.php manually (like redirect URL to there)? Because it’s a blank page (told to die somewhere in BuddyPress if I remember right).
I had the same issue as the original post here but the suggested custom CSS modification didn’t work for me. I solved the issue nevertheless, as below:
– Originally I used Remove BuddyPress Admin Bar 1.3 by Alessandro Raffa
That worked perfect (normal plugin for blog admins to use as they wish) *until* upgrading to BuddyPress 1.1. After the upgrade, the problem above appeared.
– Now I use Remove BuddyPress AdminBar 1.2 by NetWebLogic LLC
Just when I was about to mention my problem on this forum, I noticed that earlier today the “other” version (1.2) was released on the BuddyPress Developer > Plugins page.
What I did:
– I disabled the 1.3 plugin for all and mass-deactivated it.
– I enabled the 1.2 plugin and now all blogs activating it have no more space problem.
No idea why that is but I thought it might help some running the same version(s).
Just reporting:
I deleted the “other blog” and recreated it: no more problems.
Regarding the blog ID 1 issue, new users are *not* added to “dashboard” blog (as subscriber) at all, they still go all straight to blog ID 1. The dashboard function is totally ignored other than for its manual import when activating it for the first time.
Waiting for the next patch then.
Your explanation theoretically solves the blog ID 1 issue, if it applies not just during “signup” but also during “logged-in visit”.
But it still leaves open the question for why one of the many “normal” blogs acts the same as blog ID 1 in terms of adding every logged-in visitor as a contributor.
So based on your information, I just leave it for blog ID 1 and remove users once in a while manually – at least the new dashboard blog already works as well. Furthermore, I will just rebuild with a new ID the affected “normal” blog as it then should act as any other one recently created. Let’s see how that goes…
