Skip to:
Content
Pages
Categories
Search
Top
Bottom

Forum Replies Created

Viewing 25 replies - 601 through 625 (of 1,706 total)
  • @johnjamesjacoby

    Keymaster

    Within the members loop, the problem is that you’re not feeding it any user_id to get the data for… Like I said above, without a user_id, it’s just looking for the $bp->displayed_user->id, which doesn’t exist because when you’re on a directory page, there is no displaued_user->id; you’re not looking at a member…

    Within any member related loop, you will need to make a custom function for that loop and use the user_id available to you to spit out what you need…

    Put this in your bp-custom.php… (haven’t tested this, wrote freehand, lookout for bugs)

    function bp_custom_member_list_xprofile_data( $field ) {
    echo bp_custom_get_member_list_xprofile_data( $field );
    }
    function bp_custom_get_member_list_xprofile_data( $field ) {
    global $site_members_template;

    return xprofile_get_field_data( $field, $site_members_template->member->id );
    }

    Then use it like this on fields that need checking…

    <?php if ( $company = bp_custom_get_member_list_xprofile_data('Company') ) : ?>
    <p><?php echo $company ?></p>
    <?php endif; ?>

    …or like this on fields that don’t…

    <p><?php bp_custom_member_list_xprofile_data('Company') ?></p>

    @johnjamesjacoby

    Keymaster

    The search actually searches all fields of the user/group/blog, and returns anything that is relevant to that item. So if any of my xprofile_field’s have a “k” in it somewhere, it will return me. So in theory, it doesn’t suck yet, it just hasn’t been narrowed down. It’s a blank slate and a starting point to building a better search. Search functions also greatly depend on the goal of the website and what results you’re trying to pull out.

    WPMU Sitewide Search plugins currently aren’t for the faint of heart. They take all of your posts/tags/categories for all blogs, lump them into new additional full text database tables, and search those instead. It’s the only real way to do it without a million joins that just wouldn’t make any sense… Problem is you’re duplicating your data twice over into 1 mega huge table, and rebuilding the search index for old posts on a larger website would be an astronomical task that would take days of processing.

    @erich73, those are good recommendations for the directories. Put them in a trac ticket as an enhancement for maybe 1.3?

    In reply to: html in profile fields

    @johnjamesjacoby

    Keymaster

    What error does it generate? The code looks fine. Where are you putting it. The only thing I can think is that it’s running before the filter is added somehow.

    @johnjamesjacoby

    Keymaster

    I recommend using the field name, just because it’s easier to keep track of…

    Example…

    <?php if ( $firstname = xprofile_get_field_data('First Name') ) : ?>
    <h3><?php _e('First Name', 'your-theme-textdomain') ?></h3>
    <div class="profile-data-field">
    <?php echo $firstname ?>
    </div>
    <?php endif; ?>

    …will get you the data from the field named “First Name” for the currently displayed user. If there is no user displayed (your account or anyone else’s), it will return false.

    In reply to: Syncing Status Updates

    @johnjamesjacoby

    Keymaster

    acvanrijn, re: the add new post link, in future versions of BP the links are not visible if you are not logged in. Easiest way to fix the issue for now, and we may revisit the login redirect in the future, when themeing the login page is more feasible.

    re: syncing status updates; there are hooks and filters in place to allow plugin authors to do this kind of thing, but they will probably not be built into the core. BuddyPress is designed to be a flexible product that stands on its own. Synchronizing it with other websites (while convenient and cool) isn’t really within the scope of the core app.

    Thinking ahead to 5 years from now, there may be a dozen different sites to keep up with. If plugin authors want to grab this by the horns and make it happen, that’s a great thing.

    And… Just like anything else… My opinion on this is subject to change at any moment. :) haha!

    @johnjamesjacoby

    Keymaster

    The easiest way to change the name of a component through the entire site is going to be to modify the buddypress-en_US.po and buddypress-en_US.mo files, search for the instances of the words you want to replace, and change them there.

    That will allow you to change the prepackaged strings that come bundled with BuddyPress. So if you want to change the phase “Your new avatar was uploaded successfully” to “Your new photo was uploaded successfully” that is the way to do it, without modifying the BuddyPress core files.

    The same works with the components. Change “Groups” to “Developers” and then change “Group Invites” to “Developers Wanted” or whatever…

    @johnjamesjacoby

    Keymaster

    madyogi, you’re on the right track but you’re still grasping at straws.

    Take a deep breath and look at how all the functions in bp-core-templatetags.php work. There should be a function there for every core area of BP.

    P.S. – It’s “wicks” end, like a candle that’s about to burn out. :D

    In reply to: The Nourish Network

    @johnjamesjacoby

    Keymaster

    Excellent reshaping of the bp-sn-parent theme too. Left very few stones unturned.

    Looks good!

    @johnjamesjacoby

    Keymaster

    I think you’re on the right track, but making it more complicated than it needs to be. If this is strictly for the home blog, you can try…

    bp_is_blog_page() which will return true anytime “/blog” is the current BP component.

    Check bp-core-templatetags.php for a complete list of all functions that will help you narrow down which BP page it is that your users are looking at.

    Then rather than check every other possible function, you can just check one or the other?

    @johnjamesjacoby

    Keymaster

    Can you confirm with me that you’re using bp-sn-parent as your theme, and that it contains either /registration/register.php or /register.php?

    This works for me on a “vanilla” installation.

    There is also a ticket for this in the trac already, so maybe keep an eye out there as well…

    https://trac.buddypress.org/ticket/1208

    @johnjamesjacoby

    Keymaster

    That’s a good idea, and very possible to do too.

    @johnjamesjacoby

    Keymaster

    You need to use the same tag and priority that original add_filter used. Basically just copy and replace the line of code where the filter is originally added, and change “add” to “remove”

    If you have a filter you’re trying to remove and can’t find where it’s added, ask here and one of us can chime in.

    @johnjamesjacoby

    Keymaster

    The drawback with hooking into “init” or “wp” is that it checks every single page load to see if it’s a sign-up page, even when 99% of the time it probably isn’t. Andy has a patch in for MU to filter the wp-signup.php page before header output begins, so in the meantime these are our best solutions.

    The white-screens were happening because “bp_core_wpsignup_redirect” was dieing instead of redirecting to anywhere. My fix is marginally better than dieing but isn’t the last we’ll see of the issue. haha!

    @johnjamesjacoby

    Keymaster

    The directories are due for an update sooner than later, but there are also a lot of variables to consider language wise with what characters will be involved or displayed. I just installed a few language packs on my Windows 7 installation, and my charmap must be 2000 characters big now. There’s no way to include everything as a clickable link for all languages and have it not look like an awful mess.

    What is included in the bp-sn-parent theme is a working example of how you can dump out lists of blogs, and how you can use AJAX to filter through the starting letters of them.

    @johnjamesjacoby

    Keymaster

    @slicktig1

    Can you confirm if this plugin works without BuddyPress activated? It might be the more strict MU kses that’s blocking the form.

    @johnjamesjacoby

    Keymaster

    The BuddyBar is an adaptation of the bar that was previously included in WPMU, which was a watered down version of what you see at wordpress.com. It can be restyled, replaced, or totally removed if you so choose.

    @johnjamesjacoby

    Keymaster

    …and yet it still works? Give it a try.

    I’m open to any other alternatives that might be more effective. :D

    @johnjamesjacoby

    Keymaster

    Not everyone has Photoshop, or even knows how to crop images down to exact sizes. I know that sounds silly, but it’s true. min-width type CSS isn’t supported in IE. Plus being able to adjust and crop your avatar yourself instead of trusting an auto-script to get your face just right where you want it makes more sense.

    But, if you wanted to ditch the avatar cropper and replace it with simpler automated libraries, that’s very possible to do also by unhooking and not using the existing functions, and replacing them with your own custom ones.

    @johnjamesjacoby

    Keymaster

    …and since we’re all “buddies” here, there’s not a whole lot of room for criticizing others.

    I’m just as guilty of not reading instructions as anyone else is, so I get how it’s confusing at first.

    @johnjamesjacoby

    Keymaster

    Added this to the trac for you as it’s a confirmed bug. I spent a few minutes wrestling with it and found that the posting mechanism is tied to the check_is_member function, even though is_site_admin is used to make the post-form visible.

    A quick fix would be to hide the post-form even for site admins, but I’d rather rebuild the access check to allow admins + group members to post on the group wire.

    @johnjamesjacoby

    Keymaster

    You can create a custom home theme and replace the blog avatars with a default image of your own if you’d like. And choosing the creator is obvious to you, but might not be what someone else wants. The creator of the root blog is the admin account, but I always create a new user right away and use that new user as my active account.

    When you first install WordPress and see the default theme, is your first response to say “it’s obvious the sidebar should be on the left side.” The default BuddyPress themes are designed to include all of the functions of BuddyPress to guide everyone into how to customize the use of them to do what you want and look how you want it to, just like the included WordPress themes do.

    Sure, people have made ultra elaborate theme frameworks, but don’t expect that to come bundled in the BuddyPress core. You’ve got options if you don’t like what you see, so explore them. :)

    @johnjamesjacoby

    Keymaster

    Don’t feel stupid, SVN isn’t for everyone (but it does make life easier in the long run)

    Here’s the whole function…

    /* Kill the wp-signup.php if custom registration signup templates are present */
    function bp_core_wpsignup_redirect() {
    if ( false === strpos( $_SERVER['SCRIPT_NAME'], 'wp-signup.php') )
    return false;

    if ( locate_template( array( 'registration/register.php' ), false ) || locate_template( array( 'register.php' ), false ) )
    wp_redirect( bp_root_domain() . BP_REGISTER_SLUG );
    }
    add_action( 'signup_header', 'bp_core_wpsignup_redirect' );

    @johnjamesjacoby

    Keymaster

    BuddyPress doesn’t modify any WordPress tables or data. It does add a few entries to your _options though. The easiest way to “uninstall” BuddyPress is to drop the tables it creates when it installs. They usually start with “wp_bp_”.

    Very few WordPress plugins have a real “uninstall.” Most of them pollute the WordPress tables with their data and when you deactivate and delete that plugins files, their settings and data still remain in the database. It took me a while to get used to that too, coming from a world where if you don’t need something, you get rid of it; But it doesn’t hurt anything keeping it there, and it even helps sometimes if you decide to revisit a plugin that you deleted 6 months ago.

    In the coming weeks I may write a plugin to import existing blogs into the wp_bp_* tables, but the risk with that kind of thing is just like any other aggregator, it will be a very heavy routine that goes through all users, all blogs, all posts, and all comments, and feeds them into the BuddyPress tables for future use.

    @johnjamesjacoby

    Keymaster

    @nonegiven:

    No one is forcing you to use WordPress and BuddyPress, and if it doesn’t suit your particular needs then it isn’t the right tool for the job, and that’s okay.

    Multilingual blogging and content management is a relatively new need, and as more people speak up and help out in areas of need, things like this eventually do make it into the core product

    Remember that there are very few people that can do multilingual development, and even less that can do it well. It isn’t that no one cares, it isn’t due to lack of funding (you mean people get paid to do this? ;) ), it isn’t because the need isn’t obvious, it’s because things are prioritized in the order that the WordPress community votes on, and for 2.9 the votes said media was the top priority.

    We’ll get there, I promise. But before we can do that, we need to finish some of the work we’ve already got first. :)

    In reply to: Infinite Redirects

    @johnjamesjacoby

    Keymaster

    Nice find! Marked as resolved.

Viewing 25 replies - 601 through 625 (of 1,706 total)
Skip to toolbar