BuddyPress.org

I ran across something similar.

https://wordpress.org/extend/plugins/art-direction/

Allows ‘per blog post’ custom css. Cool.

In the case of bp the css gets queued up on a very selective basis. This is from bp-groups-cssjs.php in /mu-plugins/bp-groups:

function groups_add_structure_css() {

/* Enqueue the structure CSS file to give basic positional formatting for components */

wp_enqueue_style( ‘bp-groups-structure’, site_url( MUPLUGINDIR . ‘/bp-groups/css/structure.css’ ) );

}

add_action( ‘bp_styles’, ‘groups_add_structure_css’ );

We got actions too. Hook ‘bp_styles’ and define an override for the defaults. You might have a problem getting it in the sequence properly.

function my_custom_group_css(){

// check if the file exists and if it does queue it up

‘group-custom-‘ . $bp->groups->slug . ‘.css’

}

add_action(‘bp_styles’, ‘my_custom_group_css’, 99);

Ok I have tried how to:

In this link readme standard: https://wordpress.org/extend/plugins/about/readme.txt

Not sure what you mean. You want to create a different role system or just create a ‘visitor’ account? There’s a plugin called ‘role manager’ that might do what you want.

https://codex.wordpress.org/Roles_and_Capabilities

http://www.im-web-gefunden.de/wordpress-plugins/role-manager/

I am using this plugin for that case – i think it’s great :

https://wordpress.org/extend/plugins/tdo-mini-forms/

WPMU

To translate the WPMU, which I think you want to do, do this:

1. Download the POT file for regular WordPress, current version. WPMU have a lot of strings that are the same. You save a lot of work.

2. Download PoEdit, http://www.poedit.net , install it

3. Download current WPMU

4. Open the POT file for the regular WP

5. Change the path in PoEdit to the path where you have your sorce files to WPMU

6. Run “Update from source” in the PoEdit. That will create you a POT file for WPMU, but will also keep a lot of phrases translated, so you save work.

—

BuddyPress

Same software can be used to extract and create POT file.

It’s okay to do anything you want with the theme files, just as you would do in WordPress.

You don’t need the loader.php stuff if you don’t want to, however, it does add some extra functionality, such as cross theme CSS and the ability to selectively load styles.

You should also read this:

https://codex.buddypress.org/getting-started/using-the-buddypress-themes/

I have no idea what the problem is really, but you should be using subdomains for your wpmu blogs if running WordPress MU, afaik. Otherwise you are bound to get in trouble.

I basically started going through what changes were made to your plugin since it last worked, and started replacing code block by block. Once I could debug the XML request, it gave me some eyes in the back of my head so to speak, to watch what I couldn’t otherwise see.

So basically, it sounds like there is something in the xprofile field, and/or something in some users meta info that the XML parser just doesn’t like, so it gets caught up and returns a crappy value? Is that a good guess? You think it’s time to just rip through the user meta and see if anything looks suspicious?

Here’s a question. What if there are users that haven’t yet updated their profiles in BuddyPress? They were converts from a wordpress.org install, and if they haven’t returned since then, BuddyPress doesn’t have a “fullname” for them yet, and they also don’t have xprofile info. Could that break this somehow? Is there a way to watch this user by user and have it spit out an error when it finds a bad value?

Also, just for the record. I’m using BuddyPress RC1, bbPress Alpha6, and WPMU2.7. Is it possible there was a trunk update that you’re using that I’m not that maybe gives you different results than me?

More specifically, if I comment out line 335 in oci_bp_groups_forums.php…

//$user['xprofile_' . $group->name . '_' . $field_obj->name] = array('group' => $group->name, 'name' => $field_obj->name, 'value' => $field_obj->data->value, 'type' => $field_obj->type);

And run the group import, it works without error as well.

If I put a switch on the $field_obj-> name…

switch ($field_obj->name) {

…and only retrieve the custom title and forum signature, the groups import also works (still not for all users though, only groups.) I think it may be tripping over a specific type of field. I’m going to guess the textarea field, but that’s totally a blind guess with no merit or motive what-so-ever.

My process above was using deep integration. Even if an XMLRPC request looks for the xmlrpc.php in the bbpress install directory, it still loads bb-load.php, which loads bb-config.php, which loads all of wordpress before proceeding to load the remainder of bbpress. If an XMLRPC request is being made from buddypress to bbpress (like when viewing a group forum from within BP), I don’t want to reload all of buddypress again invisibly, if that makes sense?

That’s why I did…

if ( !defined('ABSPATH') & !defined('XMLRPC_REQUEST')) {

in bb-config.php, to prevent reloading ALL of wpmu and bp just for a quick xmlrpc peek.

What I don’t get is why it works in every version but this new one.

WordPress allows you to subscribe to the wp_head filter to add things through plugins to your site. More information is found here on that. An example of this in use would be looking at this one even though it is a little different than you are looking for, but gives idea how to do it.

Really, you create a little plugin to put in your /mu-plugins/ folder that has a function that adds the stylesheet to the wordpress header of every page. Then you subscribe that function to the wp_head filter.

Trent

WordPress has had a patch submitted for this imagejpeg() thing and it’s already been added into the source, so future releases (and therefore future releases of WPMU) should let us use our filter. Hurrah!

WordPress detects the currently enabled theme’s root and css directories via the bloginfo(‘template_directory’) and bloginfo(‘stylesheet_directory’) functions.

To call the css and images from the home theme in a member theme template you would have to hard code the path references as “/wp-content/themes/buddypress-home/styles.css”.

Personally, as hard coding is generally a bad idea, I would suggest simply copying the elements you wish to use from the home theme directory to the member theme directory and reference them the usual way.

I couldn’t agree more with donnacha. I would rather see patience and success, than instant gratification and failure. (not that it would ever fail of course:)

You already know that,possibly,

but just to make it sure: You are Great, people.

WP to WPMU wasn’t hard at all, actually. I was really nervous taking my site from WP to WPMU but it went without a hitch.

BP for WP sounds sweet!

Mornin’ John.

I’ve got my system setup to use deep integration now. This way in bb-config.php:

if (file_exists(‘../wp-blog-header.php’))

require_once(‘../wp-blog-header.php’);

else

if (file_exists(‘../../wp-blog-header.php’))

require_once(‘../../wp-blog-header.php’);

Very first thing under the comment block in that file. I’m also using your code to fix the require_once() problem on both sides.

I deleted *all* the meta data that bbGroups puts into bbpress meta and wp user meta tables. Started completely from scratch. Configured bbGroups to use the utility user and password that is setup in the bp group forums side.

Imported all my test groups and users. Both all users and just users who belong to groups. I get the proper numbers and data. I don’t have 100+ users but that shouldn’t matter. If Andy was going to try and import the 500,000+ users from wordpress.org I’d be worried about the amount of data getting generated.

I don’t think I have to worry about that scenario right now.

I’m not having any problems importing even with deep integration. Lemme know what you find on your side. I have to do some running around today so I’ll be gone till this afternoon. I’ll check back in then.

What i’m concerned about is that every user can create his own blog. I’ll miss the possibility to limit the users storage or traffic. Would be great if the BuddyPress Hoster could offer a basic free membership (wich is limited somehow) and if anyone special needs more the hoster could charge him for that. I’m thinking of the concept of http://en.wordpress.com/products/

Is there anything like this in the pipeline?

Given that you are delaying the release of BP until site-wide plugins are introduced into MU, it might also be an idea to wait until the WP version is also ready.

Although as anxious as anyone to see the official release, it occurs to me that any project only gets one shot at it’s 1.0 release and all the publicity that attends it. That one-off burst of attention can make all the difference to how much traction you gain in the long-run.

IF BuddyPress jumps into the spotlight as an MU-only project, that’s obviously going to be of great interest to people already familiar with MU but the average blogger is going to scratch his head and not get much further than the fact that BuddyPress isn’t for “normal” WordPress. Disappointed, he will return to his extensive collection of porn and ignore all future mentions of BuddyPress.

If, on the other hand, BuddyPress appears in the spotlight as a dual-release, with both a WP and an MU version, it will garner far more publicity, will be more obviously relevant to ordinary bloggers and will generally create a far larger splash, hopefully translating into greater momentum for the project.

Just a thought

So do we have a realistic time line for BuddyPress for WP?

Supporting WP as well as WPMU will not slow down or change the development of BuddyPress at all. I just want to make that clear.

Supporting WP should (and will) be a matter of flicking a switch and continuing along the same roadmap. Most of that switch is already in place, the things I mentioned before are not really blockers, when all things are considered.

thanks for responding so fast burt, would it have something to do with the fact that im using this locally with MAMP? the path that wpmu is in is MAMP/mysite/wpmu and the home domain is my-comupter.local/mysite/wpmu/ so should it work?

Burt…

When accessing the forums using deep integration, with no modifications to your updated plugin…

Fatal error: Cannot redeclare class IXR_IntrospectionServer in /homepages/8/d149961498/htdocs/delsolownersclub/discussions/bb-includes/backpress/class.ixr.php on line 860

Think of the loop that’s happening… bbPress loads WordPress, loads ixr, which continues to load bbPress. I really do think both sides need to check to see if the other is included to ensure this doesn’t happen.

Going back to oci_bp_group_forums.php and putting

if (!defined(BBDB_NAME))

require_once(ABSPATH . WPINC . '/class-IXR.php');

and then back to oci_bb_group_forums.php and putting

if (defined(BACKPRESS_PATH))

require_once( BACKPRESS_PATH . '/class.ixr.php' );

Fixes this.

Let me find where they are declared and try to walk you through the deep integration dance. It’s a pain in the butt, but it works. I don’t see any other way to get things like the BuddyBar and all of the BP functions over to bbPress without deep integration.

When I activate the WordPress MU homepage theme it still happens.