Skip to:
Content
Pages
Categories
Search
Top
Bottom

Forum Replies Created

Viewing 25 replies - 1,551 through 1,575 (of 1,585 total)
  • @boonebgorges

    Keymaster

    Wow, wow, wow.

    Please let me know if there’s any way I can help, be it in development, bug-fixing, testing, whatever. Real integration with MW would be killer in my community (even more so if you could set privacy settings on group wiki pages that corresponded to group privacy settings, but that’s quite hard to do with MW), so I’d be happy to devote some of my time to getting this plugin off the ground.

    @boonebgorges

    Keymaster

    You could back up the forum data to your computer as a SQL query, do some search and replaces (mainly to replace paragraph tags with newline characters) and reimport. I did something like that and it took care of probably 95% of the HTML markup. http://teleogistic.net/2009/12/upgrading-from-buddypress-1-0-to-1-1/

    @boonebgorges

    Keymaster

    I was experiencing exactly the same problem that Tracedef describes after an upgrade from BP 1.0.3 to 1.1.3 (and WPMu 2.8.4a to 2.8.6, if it matters). Some users who’d been group admins (and uploaded group avatars) before the upgrade saw one of the group avatars on their profile page instead of their profile avatar. And when they tried to change the profile avatar, they were able to walk through the uploading and cropping process, but the group avatar was still displayed. It’s possible that the problem is only limited to users whose initial avatars were gravatars.

    A bit of poking around showed that the portion of bp-core/bp-core-avatars.php that looks for avatar files in the user’s avatar directory (the first segment pasted below) was returning multiple filenames and settling on the final one, which happened in all cases to be group avatars rather than personal ones (even though personal replacement avatars had been subsequently uploaded and appeared in the user avatar directory).

    I rewrote the logic of the loop just a little bit, so that $avatar_url would be preferentially set by a file named by the new avatar filename convention, and only failing that would it look for a legacy name. I replaced

    if ( preg_match( "/{$avatar_name}/", $avatar_file ) || preg_match( "/{$legacy_user_avatar_name}/", $avatar_file ) || preg_match( "/{$legacy_group_avatar_name}/", $avatar_file ) )
    $avatar_url = $avatar_folder_url . '/' . $avatar_file;

    with

    if ( preg_match( "/{$avatar_name}/", $avatar_file ) ) {
    $avatar_url = $avatar_folder_url . '/' . $avatar_file;
    break;
    } else if ( preg_match( "/{$legacy_user_avatar_name}/", $avatar_file ) || preg_match( "/{$legacy_group_avatar_name}/", $avatar_file ) ) {
    $avatar_url = $avatar_folder_url . '/' . $avatar_file;
    }

    After the change, I (one of the affected users) was able to upload a new avatar and have it stick, and group avatars appear to be functioning normally as well.

    Not sure if this is a core bug or not. Maybe someone out there is smarter than me and can chime in?

    @boonebgorges

    Keymaster

    Mariusooms – great plugin! Really fills a need for my community.

    I wanted the “Blog” link on the group options bar to go to the regular blog theme, so I wrote a few small functions to redirect the ‘blog’ slug to the subdomain address. Written in about five minutes, but it seems to work fine for me:

    remove_action( 'wp', 'custom_bp_groupblog_setup_nav', 2 );
    remove_action( 'admin_menu', 'custom_bp_groupblog_setup_nav', 2 );

    function custom_bp_groupblog_setup_nav() {
    global $bp, $current_blog;

    if ( $bp->current_component == $bp->groups->slug && $bp->is_single_item ) {

    $bp->groups->current_group->is_group_visible_to_member = ( 'public' == $bp->groups->current_group->status || $is_member ) ? true : false;

    $group_link = $bp->root_domain . '/' . $bp->groups->slug . '/' . $bp->groups->current_group->slug . '/';

    if ( bp_groupblog_is_blog_enabled( $bp->groups->current_group->id ) )
    bp_core_new_subnav_item(
    array(
    'name' => __( 'Blog', 'groupblog' ),
    'slug' => 'blog',
    'parent_url' => $group_link,
    'parent_slug' => $bp->groups->slug,
    'screen_function' => 'custom_groupblog_screen_blog',
    'position' => 32,
    'item_css_id' => 'group-blog'
    )
    );
    }
    }
    add_action( 'wp', 'custom_bp_groupblog_setup_nav', 2 );
    add_action( 'admin_menu', 'custom_bp_groupblog_setup_nav', 2 );

    function custom_groupblog_screen_blog() {
    global $bp, $wp;

    $blog_details = get_blog_details( get_groupblog_blog_id(), true );

    if ( $bp->current_component == $bp->groups->slug && 'blog' == $bp->current_action ) {
    bp_core_redirect( $blog_details->siteurl );
    }
    }

    @boonebgorges

    Keymaster

    Thanks a million for the suggestions, JJJ. They set me on the right track to find a solution.

    Turns out it was my own damn fault :) I was porting over an older BP theme to the new framework, which involved some cutting and pasting of old lines in header.php to the new theme. I was trying to be careful to make sure that I didn’t bring over anything that was redundant or incompatible, but it turns out that I left in some references to options.php, which has been replaced by optionsbar.php. So I fixed that, and then wiped out a bunch of plugins that may or may not have been causing conflicts, and now everything is totally copacetic.

    Still don’t know exactly what the problem was – I don’t really see off the top of my head how the presence or absence of optionsbar.php would cause problems with bbPress – but in any case it’s now working. Thanks again for your help John.

    @boonebgorges

    Keymaster

    Wrap a button in if ( is_user_logged_in() ) { and }. Only logged in users will see it.

    @boonebgorges

    Keymaster

    @boonebgorges

    Keymaster

    OK, I cobbled together a solution. Two steps:

    1. Add the following code to your bp-custom.php folder or in your child theme’s functions.php (or a plugin if you roll that way):
      function myprofile_redirect() {
      global $bp;

      if ( $bp->current_component == 'myprofile' && $bp->loggedin_user->domain != '' ) {
      bp_core_redirect( $bp->loggedin_user->domain );
      } elseif ( $bp->current_component == 'myprofile' ) {
      bp_core_redirect( $bp->root_domain );
      }

      }
      add_action( 'plugins_loaded', 'myprofile_redirect');

    2. In header.php of your child theme (copy it over from bp-sn-parent if you don’t have one there already) replace

      <input type="hidden" name="redirect_to" value="<?php echo bp_root_domain() ?>" />

      around line 57 with

      <input type="hidden" name="redirect_to" value="<?php print ( bp_root_domain() . '/myprofile' ) ?>" />

    Anytime a logged-in user types in the address http://example.com/myprofile, they’ll get their profile. Non-logged-in visitors will be redirected to the home page.

    Let me know if it works for you.

    @boonebgorges

    Keymaster

    Thanks, Jeff. You’ve confirmed the bad feeling about it I already had! I’ll find another method.

    @boonebgorges

    Keymaster

    It’s a little bit hard to do with the standard method of appending the redirect URL as an argument to the href link. At the time that the page is built from the template, you don’t know what the username is – it’s only after the user types in his username that you know what the redirect URL should be (eg http://example.com/members/boonebgorges), but by that time the page has already been built.

    Unless there’s an all-purpose logged-in-user-profile URL alias built into BP that I don’t know about (maybe something like http://example.com/members/myprofile). Actually, now that I think about it, such a thing might not be too hard to create. If I get some spare time in the next few days maybe I’ll take a swing at it.

    @boonebgorges

    Keymaster

    You can also use the following jQuery technique to put the buddybar in any application: http://teleogistic.net/2009/10/displaying-the-buddypress-admin-bar-in-other-applications/. It’s probably overkill if you’ve only got a single page (since Xevo’s method is so much more straightforward) but it’s nice if you’re trying to integrate another entire program.

    @boonebgorges

    Keymaster

    Here’s a really helpful guide to translating using poedit: http://urbangiraffe.com/articles/translating-wordpress-themes-and-plugins/

    @boonebgorges

    Keymaster

    Count me in for some sort of get together. I’ll hold off on offering to buy a round until I know how many people are going to show up though – beer is expensive in NYC!

    @boonebgorges

    Keymaster

    I’m sorry for the extremely unhelpful comment, but: I laughed out loud when I saw this topic’s title. “IE broke my CSS” would make a great t-shirt, or a band name.

    @boonebgorges

    Keymaster

    tcesco, I recently ported over a version of the more general bbPress attachments plugin by _ck_: https://wordpress.org/extend/plugins/forum-attachments-for-buddypress/. The downside is that I haven’t yet gotten inline images to work, which means that people can upload and download images but they don’t appear as images in the posts (just downloadable file links). Thus it might not work for your purpose, but it’s worth a look.

    @boonebgorges

    Keymaster

    Check out bp-core/bp-core-adminbar.php. The items in the admin bar are hooked to bp_adminbar_menus, and are ordered by the priority argument. So, for instance, if you want to put a button between the Blogs and Notifications menus, I’d write the button into a function called bp_adminbar_my_button, then use the hook add_action( 'bp_adminbar_menus', 'bp_adminbar_my_button', 7 );.

    @boonebgorges

    Keymaster

    Getting MediaWiki running together with WP/BP has two main parts: 1) sharing user login info and 2) theming them to look alike. http://dev.commons.gc.cuny.edu/2009/05/21/new-mediawiki-extension-wpmusinglesignon/ gives a method for (1). As for (2), you’re looking at lots of elbow grease :)

    @boonebgorges

    Keymaster

    Very cool, Flynn. Thanks so much for sharing.

    @boonebgorges

    Keymaster

    Hi snagfly. I’m the author of that plugin. It sounds like the problem is that you activated the bbPress trigger plugin inside of WordPress. As is stated in the readme files, this part of the plugin is only needed if you are running a separate installation of bbPress with BuddyPress 1.0.

    If you are running BuddyPress 1.1+, you can safely delete the file bb-group-forum-subscription.php, keeping and activating only bp-group-forum-subscription.php.

    @boonebgorges

    Keymaster

    Hi welshpixie – is there a chance you’re using More Privacy Options for WP? You might want to see the following https://buddypress.org/forums/topic/more-privacy-options-private-blogs-and-activity-streams

    @boonebgorges

    Keymaster

    JJJ – I really like your modular way of thinking about how the forums could work with other parts of BP. It’s just hard to envision how, say, forums could be attached to an event, given the current dependence of forums on groups. Ideally (at least from this viewpoint) forums would be more of an independent, top-level component of BP, in the same way that a wire is (and in the same way that a wire can be placed on profiles, group pages, and so on).

    @boonebgorges

    Keymaster

    @wordpressfan I think you might be right for some kinds of communities, but as the groups functionality of BP becomes richer (as it does with, for example, Andy’s new External Group Blogs plugin), the groups/forums distinction won’t seem so arbitrary. Forums then become just one of the ways that group members (ie people who share a common interest or purpose) can collaborate and communicate. But you’re right that right now there is little difference between a group and a forum, at least functionally speaking.

    @boonebgorges

    Keymaster

    Excellent, Mike. Not only am I not offended, but I would love to see the improvements that you make to the email notification itself. It was (funnily enough!) one of the last things I did when I put together the plugin, so I didn’t feel like putting a lot of time into it. If you come up with something more flexible and/or better for a wider audience, I would love to have it, and with your permission patch the plugin.

    Boone

    @boonebgorges

    Keymaster

    Another idea is to have all non-group-specific forums belong to a sort of invisible, public group that everyone on the site is a member of. That way, anyone could post to the forum, and its topics would show up in the forum directory as you’d expect.

    The trick would be to get that group not to appear on group directories, both public and individual, since the group would be nothing more than a shell for public forums and thus wouldn’t have any other content worth listing on people’s group and activity pages. It’d be easy enough to add a piece of metadata to each group that determined whether it should be listed in directories (independently of the public/private/hidden distinction). The problem is that groups are listed in lots of different places in BP, and you’d have to hijack each one of them in order to filter for this metadata. Such a plugin would be a pain to build and to maintain, I expect, as group lists are posted in more and different places throughout BP.

    @boonebgorges

    Keymaster

    Hi Ray,

    I’m glad you got it figured out. The reason I didn’t do this in the first place, though, is that BBDB_USER and those other global variables refer (if I’m not mistaken) to the bbPress db credentials, not the BP credentials that are necessary. If you’ve got the two installed in the same database, it’s not an issue and the globals will work. But I’m running bbPress and BP in separate DBs. $bb->user_bbdb_user and the like store the WP db info that the admin enters in the bbPress admin > WP integration settings.

    So I guess all this is to say that I’m glad you got your situation figured out (I think I already said that :) ) but the very same solution might not work for all installations.

    @Mike – Yes, I noticed the other day that Brent had posted the plugin, and I thought it was hilarious that we had come out with the plugins at almost the exact same time. Please feel free to pick apart my code, as I’m planning to do with your code in the near future, so that we can communicate about the best way to merge, or at least not unnecessarily duplicate work. I’ve got some ideas for making the plugin better in the future (daily digests in place of individual emails would be a big improvement but is probably pretty difficult) and we should definitely help each other!

Viewing 25 replies - 1,551 through 1,575 (of 1,585 total)
Skip to toolbar