BuddyPress.org

Try installing Email Log (https://downloads.wordpress.org/plugin/email-log.zip), which records all mails sent from the WP+BP installation, this will at least let you know if the activation email has been processed from the Site (According to the site itself).

There is also another plugin (https://buddypress.org/community/groups/wp-activate-users/) which will allow you to activate users that dont seem to get the email or are just plain lazy.

I cannot for the life of me get the activation email to send. Can anyone please help? I’ve been working on this for over 12 hours straight now and am exhausted. Please help me! I’ve checked the box next to “allow anyone to register”, saved changes and installed the latest versions of “wordpress”, “buddypress”, “buddypress template pack” and “mail from” and it still won’t work. What else do I need to do?

Well..the problem was solved when i installed the plugin, but why does that problem exists..especially with bluehost if it is supposed to be the bes option to host wordpress..right?

To remove the default tabs, you’ll need to modify the theme.

Read this page:
https://codex.buddypress.org/theme-development/building-a-buddypress-child-theme/

Then, once you’ve got the hang of that. Copy over /bp-themes/bp-default/header.php to your new child theme and modify the tab structure.

The function you’ll want is:
`is_user_logged_in()`

Wrap a is_user_logged_in() conditional around the tabs you want to show only for logged in users.

Something like this:

`

<li class=”selected”>
<a href="//” title=””>

<li class=”selected”>
<a href="//” title=””>

<li class=”selected”>
<a href="//” title=””>

<li class=”selected”>
<a href="//” title=””>

<li class=”selected”>
<a href="//” title=””>

`

Note that if someone knows the URLs to those tabs, they’ll still be able to access them.

You might want to look into some BP private plugins like:
https://wordpress.org/extend/plugins/buddypress-private-community/
https://wordpress.org/extend/plugins/private-buddypress/

Did you upload BuddyPress by FTP? There is probably a corrupt file. Delete the plugin and, if you can, install BuddyPress via the “Add new plugin” page in your WordPress admin.

@victor_moura – glad to help.

define(‘DB_NAME’, ‘whatevernameigivethedatabase’);
define(‘DB_USER’, ‘root’);
define(‘DB_PASSWORD’, ‘root’);
define(‘DB_HOST’, ‘localhost’);

root/root is the default username / password combo for MAMP. Obviously you should never have it set like this on a live public server because it’s instantly hackable, but on your local MAMP (assuming you haven’t got it set up to actually serve a Live site for a client to see online) it’s fine.

(When setting up a brand new site from scratch, you can also change your database table prefix (the setting is found in wp-config.php) for extra security. Google this to learn why it’s a good idea.)

b) I use MAMP Pro which comes with phpMyAdmin built in. phpMyAdmin can be launched from MAMP Pro’s interface. When I’m setting up a site I create a folder in my browser bookmarks for local, and one for remote. Aside from the site URLs, I bookmark the phpMyAdmin interface for both local and remote, so I can get to either database in a single click. Obviously, with the remote database it will ask you to log in during the loading, since to bookmark it initially, you’ll need to access it from your website’s cpanel (or wherever you launch phpMyAdmin from at your web host) and to do that you’ll need to be logged in to your host.

So, go into phpMyAdmin, click “localhost” (top left of main content area) to check you’re on the “home” page, and you’ll see an input field (“Create new database”). Name your db, and click Create (that’s all, no need to touch anything). This will create an empty database (a “shell” if you like) ready to be filled. I find it helpful to name the remote and local dbs differently (otherwise it’s too easy to get confused / messed up) .

3. Then click “Import”, find your backup and load it. At this stage, absolute URLs in your site will be wrong (they’re pointing to the address of your remote web server, not at your local MAMP server). To correct this in one easy find and replace (whilst protecting the structural integrity of your database tables – very important!) use http://spectacu.la/search-and-replace-for-wordpress-databases/ (it’s a very powerful tool, treat with caution).

Once you’ve got the hang of it, it’s quick. From starting a remote backup to running that db as a local mirror takes me about 30 seconds.

i. when I’m loading in a remote db, I always delete the local one (to do this go to “localhost” in phpMyAdmin, click the name of your db in the left hand column and when it’s loaded click “Drop” – it means “Delete” – it’s top right, in red), make a new local one, and load the remote db into this fresh “shell” – just to make sure everything is exact. You can delete the local db from within phpMyAdmin. Incidentally, this usually isn’t the case on a remote database (usually, to delete the remote db if you need to, you have to go into cpanel and select “Database Tool” or something similar).

ii. When saving the remote db, I select these options (you should Google this stuff) :

Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT
Add IF NOT EXISTS
Complete inserts
Extended inserts

Select “save as file” and “gzipped”. Don’t mess around with the dump, or unzip it.

All of this works for me, with my particular setup. I can’t stress enough how important it is to do thorough testing, to be certain that the backups you make actually work.

There are several standalone tools out there for more comprehensive db management, but phpMyAdmin works great for me at this point, and it’s so convenient having it all in the browser. What makes MAMP Pro so good is being able to set up multiple virtual servers – sometimes I’ll run several local mirrors of the same site so that I can try out different things and easily compare the results.

Emails are *not* a WordPress issue. They are 99.9% issues with the host or your ISP. Every. Single. Time.

The reason they get dumped into trash or blocked by your ISP is becasue they are sent thru php mailer and have different header son them. Which is entirely due to the way your box is set and (as repeatedly mentioned) the way your ISP handles them on receipt.

WHAT THE HECK? I get every email from wordpress and buddypress except the ac. email.

IT WAS WORKING like Yesterday! I upgraded to wordpress 3.0.4 and UHHHH!

It’s so funky, my emails totally fluctuate. I just installed 3.04, and activation emails are not being sent out. I will have to go into troubleshooting mode tomorrow….

I wish wordpress would really fix this, I am getting %&$% tired of email problems.

The emails at one time would appear right smack away, but I recall the emails taking a massive amount of time to appear, so I would recommend a notice on the register page about this.

You have to edit the part about the server. On mamp it will be localhost and your user name and password is usually root. This is so WP can connect to your local database.

// ** MySQL settings – You can get this info from your web host ** //
/** The name of the database for WordPress */
define(‘DB_NAME’, ‘buddypress’);

/** MySQL database username */
define(‘DB_USER’, ‘root’);

/** MySQL database password */
define(‘DB_PASSWORD’, ‘root’);

/** MySQL hostname */
define(‘DB_HOST’, ‘localhost’);

As for creating a database you go to phpmyadmin enter a name of the db in the create database input and hit create.

Then in the wp-config file you enter the name you entered here define(‘DB_NAME’, ‘ PUT YOUR DB NAME HERE’);

Yep, I just did the update, and so far so good. But if you are concerned, you should do a backup just in case.

WP upgrades, especially security and maintenance releases (ie when the version number is 3.x.x rather than 3.x), are generally very unlikely to break any plugins, including BP. I’d recommend that you upgrade to maintenance releases immediately.

Feature releases, like WP 3.0 and 3.1, are somewhat more likely to cause problems with plugins like BP. But the BP core team works closely with the WP core team to ensure that BuddyPress is ready for whatever changes come along ahead of time. If there is something in BuddyPress that absolutely cannot be fixed prior to a major WP release, we’ll do our best to warn you about it before you upgrade.

I work with local mirrors on MAMP Pro. This is what I do :

1. Copy the remote files (the whole install) to my local machine (I do this so the file creation dates are the same).
2. Backup the remote database with phpMyAdmin (be sure to select Add DROP TABLE) as a gzip file.
3. Edit the local copy of wp-config.php for my local machine’s database connection.
4. Create a new local database and import the remote backup (I personally always destroy the local db and create a new empty one to import into – then I know it’s clean).
5. Use this tool to change all absolute URLs from remote to local: http://spectacu.la/search-and-replace-for-wordpress-databases/

Then I’ll test new plugins locally before deploying. Also I update plugins locally, and then manually copy them to the server, having had a few past failures updating plugins on production servers. Once it’s running, the only files I normally have to backup from remote to local are all in wp-content (avatars etc., which can easily be sync’d).

Hope that helps.

https://wordpress.org/support/topic/need-a-cheap-reliable-hosting-for-my-buddypress-network?replies=2
https://buddypress.org/community/groups/buddypress-hosting/forum/
“Cheap” is relative.

https://wordpress.org/extend/plugins/buddypress-badge/

I also have found myself torn about using pages for BP directories. In the end, though, I think it’s a compromise that works out for the better in the short- to medium-run, and does not have awful long-term consequences.

In my view, it is a gross overstatement to say that this move ‘ruins’ BP. However, there are a few things about it that are unappealing:
1) It forces the creation of what are, essentially, dummy pages – whatever content you might add to the page through the normal WP editor is totally ignored
2) Related – It uses part of the WP page infrastructure (URLs) without using others (in particular, WP page templates)

Problem (1) is unappealing, but it is mitigated by a couple of points. First, the current system is not a whole lot better. Instead of having ‘dummy’ pages that you can see in the admin (like BP trunk has), the current version of BP has ‘phantom’ pages, so that when BP detects a URL like example.com/groups, it essentially hijacks the page load in order to do its own stuff. This is a bit jarring, and not at all transparent. So there is a trade-off, but it’s not all bad. Second, while the idea that ‘Pages in WordPress are supposed to be static content’ seems right to me in broad strokes, it doesn’t seem to me to be a hard-and-fast rule. Many plugins (gallery plugins, ecommerce plugins, etc) display their content by means of a shortcode that is manually inserted on a page or post, with pages being used for their pretty URLs.

On the other hand, there are some real benefits to directories-as-pages:
A) Easier URLs (as @driz has noted)
Integration into WP 3.0-type menus (this is the big one IMO)

How important are things like (A) and (? For sites maintained by folks with some PHP chops (and organizations with money to pay people with PHP chops), they could be fairly easily accomplished with BP_GROUPS_SLUG, etc, and with some other finagling. But – and this is just a guess – this profile does not match most of the users of BP. Nor should it, necessarily. To the extent that BP can be easy to use and install for people with little technical knowledge, without at the same time making it less flexible from a developer’s point of view, it should be. This change is good for end users, and is no more difficult for developers than the current technique, so it seems like a net win.

Another more theoretical argument for the directories-as-pages move (especially as compared to the new admin panel @driz suggests for changing slugs) is that BP shouldn’t reproduce functionality that WP could provide, unless there is a convincing reason for doing so. Using WP pages for BP directories is a step toward greater BP-WP integration. It’s not perfect (see my problem (2) above) but it is a start.

As for custom post types: It’s likely that at least some of BP’s components will be refactored to use custom post types in the future. When that happens, part of the upgrade script will probably involve removing the dummy pages at issue here. So from the user’s point of view, the transition will be seamless.

I should say that I am in agreement with a lot of the sentiment in this thread about making BP a bit more lightweight, framework-y, and disjointed than the sometimes hulking behemoth it is now. However, that kind of transition can and probably should be gradual (at least more gradual than the 1.3 release).

Sounds like you’re using an older version of WordPress.

Deactivate BuddyPress and upgrade WordPress:
https://codex.wordpress.org/Upgrading_WordPress_Extended

Well, don’t blast something for being exactly what it’s suppose to be. Since BP is a WordPress plugin and the dummies books are for absolute beginners then it makes sense to spend a great deal on the core. Is there room for more documentation? Yes!

Read the documentation on this site: http://codex.buddypress.org
Visit these:
http://etivite.com
http://bp-tricks.com
http://wpmu.org/category/buddypress

I’m sure there are more resources out there. Just search or ask.

Lol, yes, I am a troll.
I am old and smell funny and live in a cave.

Look, in today’s economic climate, the job market is pretty much empty, even in Australia. Even if you do get a job with a company, then you’re hard pressed to pay rent and bills, and you can never think of buying a house.

The only option left is web-development and small business. I’m sorry I got upset about it yesterday, but it’s really frustrating when you get to a golden package like Buddypress and you find that they documentation is really sparse. Then you find that there’s a book out there specifically about the package, and all that’s in it are the installation instructions and how to use the admin panel.

For the record, there’s a second book called ‘WordPress for Dummies’, so that’s why I thought it wasn’t right that her first half of the book is about WordPress.