Reporting issues with the WordPress blog export function should go on to the WordPress forums or Trac. It’s not to do with BuddyPress.
Please everyone keep posts here on topic, civil and polite.
Yes, I am using sub-domains. No, I did not go back and forward.
If the plugin does not work with sub-domains … <i>which, let’s face it, are pretty core to WPMU</i> … then I suggest that it would be good practise to add a block, warning or at least instructions during the setting up process which prohibits the use of the plugin.
There is nothing in the readme either.
‘example’ and ‘example.com’ is just the usual ‘example’ computerspeak not the actual name used.
The header error as above happen on the first and every attempt at blog creation, not going back and forward.
I went forward until the white error page. I could neither go back nor forward. When I came out of the plugin set up, I discovered that it had partly set up the blog on the home page (<i>but that other elements of groupblog did not work of it did not work</i>). It stalls on stage 3.
I also found that previously made groups (<i>made before the groupblog installation</i>), did not have a blog and I could not make a blog for them.
As for the rest, see my perfectly polite and helpful comments … here.
Can I also say, for the future, it would be a really great feature if, when removing the plugin, it removed (or gave the option to remove) all the changes it made to one’s database.
Its a really great idea but perhaps … in all fairness … you should reduce it from a 1.0 + release for just now until it does work?
Marius,
If you read the English, it was a comment regarding the WordPress Export function (which exports posts and page but not it seems the blogroll) … not your plugin.
That seems like an awfully strange and unnecessary omission … and a PITA to administer when it comes to having rebuild a community by hand.
I am sorry but spending one’s times to ‘beta testing’ other folks’ software, and bug reporting back, is also service to the community and improves it.
Nothing good comes from being oversensitive about fair observations … especially those addressed in polite enough terms to others.
@anointed, I think the best way to do something like this would be to extend the existing multi-site plugin(s) and introduce a method to either serialize the sites that users belong to and add it to a _usermeta field, or insert/update/delete blog_id/site_id to the _usermeta every time a user is added or removed and check against those meta’s on every page load if the user is logged in.
The problem comes from situations where site-admins technically are users on all sites, and how to deal with collisions where users can be added to blogs without being added to sites, if that makes sense?
What you would need to do is hook into all of the places where users can be added/removed from blogs, and add your own actions to those functions to perform your special tasks, which-ever you choose to do.
Then… Once that’s all done… You’ll need to modify the members directory to sniff out only the users that are in those _usermeta values that you assign them to. In my opinion, this is a modification of the kind of magnitude best left for professionals or tinkerers with lots of extra time to test and make sure you don’t corrupt the relationships between users, sites, and blogs.
There are functions already to see which users are already part of which blog_id’s, but that doesn’t really work for all users across any particular group of blogs based on a site_id. I haven’t needed to do something like this myself so I can’t say for sure, but I haven’t seen a core function to find users belonging to particular sites… It would require first checking the wp_blogs table for all blog_id’s matching your site_id, and then checking the roles and caps for users that match.
Silly questions…
- Are you 100% there’s no deep integration?
- Maybe put some echo’s in the original bbPress files and see how and when they’re getting included?
- Is there a widget or plugin that’s preloading bbPress before BuddyPress?
- Do you have the old integration plugins disabled?
- Can you confirm in wp_sitemeta that “bb-config-location” is pointing to the new bb-config.php and not the old one?
Just a few things to look at and consider…
You are right ! That’s it !
Thanks. I added that instruction to the readme.
wooooo….. ghostly
actually i have no idea why either… but i know that i had to have at least one user with all the fields filled to see the field names in the list…
That’s stupid
Thanks, I had forgotten about his.
But more stranger, I don’t see anymore the fields names in the select boxes of the admin options after having installed the plugin… Weird, uh ? I didn’t change a thing in the code about this…
the auto-install of this plugin is not working, Benoit will have to work this out… files structure is wrong.
you have to install the plugin sitewide… that’s the only reason why the panel is not showing..
and i can say that having a bp-plugins folder would avoid a load of errors like this, making support for these addons a simplier life.
Got problems with the admin menu of that plugin.
The BuddyPress admin panel does’nt expand, and instead, it goes to “wp-admin/bp_profile_real_names” which is the broken url of my plugin (and should be : wp-admin/admin.php?bp_profile_real_names).
The page itself is broken.
// Adds admin menu to WP Dashboard > BuddyPress
function bp_real_names_menu() {
add_submenu_page( ‘bp-general-settings’, __( ‘Real Names Options’, ‘bp_profile_real_names’ ), __( ‘Real Names Setup’, ‘bp_profile_real_names’ ), ‘manage-options’, ‘bp_profile_real_names’, “bp_real_names_options” );
}
add_action(‘admin_menu’, ‘bp_real_names_menu’);
Please help ! I don’t see where the problem is.
Thank you gentlemen.
I would love to get my theme working via official means. I’ve tried for a few weeks now to follow Jeff’s instructions (which he has kindly provided to me for the third time above) with no luck.
Because all my bp CSS and formatting is written for the now deprecated bpskeletonmember theme, following the “I’ve used a WordPress theme for my blog with the default BuddyPress member theme†instructions from the above link results in a member theme without my CSS after I delete the bp-themes directory. That’s why I was asking how to salvage the deprecated theme. I’m a little desperate now as I only have until weeks end to work on this.
Hi!
I’m looking for the same thing and I wonder if you were able to figure this out. help, anyone?
/public_html/wp-content/themes/
By stock you mean buddypress-home?
@Nervo thank you so much
Just found out that we got listed on WPMU.org’s 17 of the Best and Beautiful!. We’re all ecstatic here.
http://wpmu.org/buddypress-eye-candy-17-of-the-best-and-beautiful/
The resolution from apeatling (in response to https://trac.buddypress.org/ticket/1356):
If you are allowing @ symbols in usernames, then please add this to your wp-config.php:
define( ‘BP_ENABLE_USERNAME_COMPATIBILITY_MODE’, true );
https://codex.buddypress.org/how-to-guides/changing-internal-configuration-settings/
Worked for me!
@jjj Yep, I think that’s pretty much the scoop.
You get that error because you have a copy of the old buddypress in mu-plugins and you’re activating it (again) in the regualr plugins menu.
@member11 – rather than enclosing your website URL in brackets (and making your users do the same) you’d be better off specifying the website URL field in the config file as @r-a-y suggests, so that it’s not linked to the search facility:
Open up the custom-profile-filters-for-buddypress.php file and in the $no_link_fields array (starting on line 14) add in your field, so mine looks like this:
$no_link_fields = array( // Enter the field ID of any field that you want to appear as plain, non-clickable text. Don’t forget to separate with commas.
‘Skype ID ‘ ,
‘Phone’ ,
‘IM’ ,
‘Web Site’
);
– where my web site field is called Web Site.
Also you may want to add in any social networking URLS that your site uses in the $social_networking_fields array that’s below this array. Same principle.
I use a plugin by Boone Gorges called Custom Profile Filters:
http://dev.commons.gc.cuny.edu/2009/06/21/updated-version-02-of-custom-profile-filters-for-buddypress/
Needs some manual configuration in the $social_networking_fields array, but you should be able to do what you need.
Give that a shot.
Catherine’s on the money. This would make a good Trac enhancement ticket so we can see if it’s viable to hook into this WPMU page or not.
Nothing good comes from your attitude buddy:
“Serious omission in the code here folks …”
I think from this point on you are pretty much on your own and are encouraged by righting your own plugin or publishing system. With a good attitude you’ll find a lot more help.
That didn’t work for me either but your syntax correction helped. This is what I finally got to work.
<?php __( previous_post_link( ‘« %link’), ‘buddypress’ ) ?>
<?php __( next_post_link( ‘%link »’ ), ‘buddypress’ ) ?>
Using ‘_post_link’ instead of ‘_posts_link’. Also ‘%link’ displays the prev/next post name hyperlinked to the post.
You can see an example here: http://nashvillesharepoint.com/blog/2009/11/11/community-dev-testing-bp-plugins/
I don’t think it is a problem with volunteers. Automattic could just pay people to do the work, or hold an account with a translation company. It is not as though it is a huge piece of work to upkeep. Look e.g. how Mediawiki or PHPBB handles it. It only account for 10s of kb.
(Actually, in my case, Automattic has recently hired bi-lingual Japanese staff and I will be interested to see how they are used).
The problem of language files seems to be a problem that needs addressed at the core of WP, centralized, made much easier to handle and more effective.
Now that Buddypress is part of the stable, I am hoping it is also developed as an international device. I am glad to read that there is awareness of this on the development side ….
what responses about it do you get back from the main developers?
