BuddyPress.org

Register.php is a BuddyPress file whereas wp-signup.php is a WPMU file. If you use register.php, then wp-signup is automatically not used. In other words, you use one or the other. To choose to use wp-signup.php, you would need to delete register.php from your theme.

Many people have issues customize wp-signup.php. Therefore, I’d recommend using register.php and customize that file instead.

I was wondering if this is what you guys were looking for:

http://wpmudev.org/project/Menus

The plugin gives you control of what menus are turned on site-wide for each member. Well, it’s kind of a “global” thing right now, but it seems to take care of disabling back-end menus.

Here’s the description of the plugin:

“….If, like me, you need to hide the Themes or Import Menu, or don’t want anyone messing with their Permalinks menu, or are frightened by the Delete Blog menu, this plugin will help.

Toggles the following in WPMU 2.7

‘Site Administrator Gets Limited Menus?’,

‘Posts’,

‘Posts Add New’,

‘Posts Edit’,

‘Posts Tags’,

‘Posts Categories’,

‘Links’,

‘Links Add New’,

‘Links Edit’,

‘Links Link Categories’,

‘Pages’,

‘Pages Add New’,

‘Pages Edit’,

‘Media’,

‘Media Add New’,

‘Media Library’,

‘Comments’,

‘Appearance’,

‘Appearance Themes’,

‘Users’,

‘Users Authors and Users’,

‘Users Add New’,

‘Users Your Profile’,

‘Tools’,

‘Tools Import’,

‘Tools Export’,

‘Tools Turbo’,

‘Settings’,

‘Settings General’,

‘Settings Writing’,

‘Settings Reading’,

‘Settings Discussion’,

‘Settings Privacy’,

‘Settings Permalinks’,

‘Settings Media’,

‘Settings Miscellaneous’,

‘Settings Delete Blog’,

‘WPMU Media Buttons’,

‘WP Media Buttons’,

‘Dashboard’

If you use other plugins to add/disable/hide admin menus, there will be collisions/errors. Happy testing!

Plugins adding menu pages to WPMU 2.7 Adminbar may not be hidden in all browsers.

Favorites menu items toggle as well….”

Burt-

Well, that was one of my thoughts–and why I’m asking Grandslambert to clarify what he meant by

Using WPMU 2.7 and the latest TRUNK of bbPress

I assume he meant BuddyPress. If so, is he running WPMU 2.7 but with BP 1.0_RC2? Did he install the BP folder in the proper spot? You’ve seen my questions above.

But, I’m tired and JJJ had an intriguing idea as well. So, perhaps I should get some sleep tonight and all the problems of the universe will disappear overnight!

Failed opening required ‘BP_PLUGIN_DIR/…

Not using latest trunk because BP_PLUGIN_DIR is not defined or just installed in some fashion that bp-core.php isn’t running on all blogs which means the latest 2.7.1 wpmu isn’t running and the bp plugins aren’t sitewide.

maybe so?

@JJJ-

Hum, I guess that could help…

Grandslambert,

In your buddypress-user/functions.php, take out ALL of the code besides what you need to make your sidebar(s) for your widgets.

Forgot to mention that little part.

Some initial questions:

1. Which versions of WPMU and BuddyPress are you running?
2. Have you enabled all of BuddyPress’ components?
3. Where did you install the suite of BuddyPress components?
4. Are you using custom themes of the standard themes that came with BuddyPress?

WPMU 2.7 and the latest TRUNK of bbPress

I assume you mean BuddyPress, and not bbPress. If so, then here are a few questions:

1. What do you mean by “latest TRUNK”? Did you actually download the BP trunk from trac as a zip or use SVN? Or, did you obtain BuddyPress from the big, orange Download button that can be found on the top of any BP page?
2. What version of BuddyPress are you using?
3. Where exactly did you place the BuddyPress folder?
4. You are using WPMU 2.7 and not WPMU 2.7.1-beta1 or -beta2, correct?

Well, hell Andy. Where did all these template classes come from all of a sudden? Maybe I’m just noticing them. Looks like as soon as you say:

bp_has_<component type>() a template class is instantiated and we get an instant <component type> loop. I see them for all the components. That’s going to make creating and extending themes pretty easy.

Look in each component directory in the bp-<component>-templatetags.php file

Have I just been so buried in other stuff I never noticed them?

I’m not sure what you did exactly to make this so broken, but I can tell you how I did what you’re trying to do.

1. Copy “buddypress-home” theme to a temporary folder.
2. Rename “buddypress-home” to “buddypress-user”.
3. Delete “buddypress-user/home.php”.
4. Open “buddypress-user/style.css” and at the very least, rename the theme to include something with the words “User Theme”
5. Upload this theme, and activate ONLY it in your admin panel.
6. Make sure that theme is the ONLY active theme. This ensures users will only get that theme provided to them at default.

That should do it.

If you setup new blog users to be Authors, they only have limited access to the dashboard and can’t see the themes. They can still add posts, media, and a few other things. Just enough for what most of them will need.

An added bonus is that the “switch theme” option is removed from the cascading menu viewable in the user’s profile.

Hope this helps!

As to your first question:

Look in the loop in your theme’s index.php file for this:

<p class="date"><?php the_time('F j, Y') ?> <em><?php _e( 'in', 'buddypress' ) ?> <?php the_category(', ') ?> <?php printf( __( 'by %s', 'buddypress' ), bp_core_get_userlink($post->post_author) ) ?></em></p>

Make the necessary changes.

As to your second question, look for this also in the same file:

<div class="widget" id="latest-news">

<h2 class="widgettitle"><?php _e( 'Blog', 'buddypress' ) ?></h2>

Change the word “Blog” To whatever you like.

Please note: if you plan on sticking with BuddyPress’ standard themes, you will lose these changes the next time you upgrade BP. So, either you live with that and make the changes again with each upgrade, you create your own custom themes (possibly by simply copying the current themes and renaming them), or you never write over the theme files when upgrading.

The second option is the best in my opinion. But, with each upgrade, you should still evaluate any changes that may have been made in the new standard theme as they could be important.

No I don’t see the problem. If there is a problem, only logged in users can see it. Can you give me a demo/test login username and password?

It might be useful to start a new topic for any theme specific issues. The title of this one doesn’t lead anyone to know that it’s a theme issue.

I don’t know the nature of your theme customization. I’d install the entire member theme and take a look at the differences between the current theme and your mods.

I don’t have much experience with the themes. When you find that you need help with that area I know that others have been modifying and creating new member themes. I’m sure they can help out with specific issues.

You mean top left of theme? That’s an image – you’ll find it in /wp-content/bp-themes/buddypress-member/images/logo.gif.

That fn ‘bp_activity_user_install’ doesn’t exist in the latest core trunk. bp no longer uses individual activity tables for each user so the call fails. I’m guessing you are mixing recent core and an older version of the member theme code.

It wasn’t scarasm per se, it was a complaint. It takes time to hunt down issues. Especially on previous versions of bp. It helps for you to be specific and informative.

Anyway, I think you are going to continue to have problems like this with an older version of the member theme as your code base. The member theme reflects changes in the core and there have been plenty.

Ninh-

I’ve looked at your site and of course cannot duplicate the problem without logging in. But, that’s okay.

You mention that you’re using a custom theme. Read the first post in this thread, paying close attention to the parts that talk about custom themes. Also, there are more posts within this thread that discuss theme issues that could apply.

It appears that you are still using BuddyPress 1.0_RC1. I cannot remember if any of these issues apply to RC1. Perhaps someone with longer BP experience can chime in.

There’s nothing confusing about this at all.

We’ve got wpmu installed on a linux type subdomain using the subdirectory blogs option with bp’s home theme running on a blog id other than the default root blog id of ‘1’ using beta versions of both wpmu and bp including a new restriction from bp that it be installed in /plugins/buddypress and activated sitewide with a new mechanism that replaces the old /mu-plugins scenario.

lol. Time for a nap.

Okay, putting aside the subdomain versus subdirectory issue for a second, you state that:

…the bp link in the menu works but where is says “disbale components using below form” nothing shows

It sounds like BuddyPress is not activated. With the 1.0_RC2 changes, BuddyPress is now considered a single WPMU plugin. You must first login to the WPMU backend as site admin and then go to Plugins > Installed and make sure that BuddyPress is activated.

Once it’s activated, a new menu group is created at the bottom of the menu tree called “BuddyPress”. You click on BuddyPress > Component Setup and you should see that all the BP components are enabled by default. It is in this admin screen where you can enable and disable individual components.

If you’ve already activated BuddyPress, then something is clearly wrong. Have you double checked to make sure that you copied all the BP component files and folders (minus the theme folders) into the /wp-content/plugins/ folder? Did you install the BP suite into the /wp-content/mu-plugins/ folder instead?

If the BP install locations and files are in their proper place, then I would recommend deactivating BuddyPress then deleting the entire BP directory and try reinstalling the BP plugin suite again and see what happens.