Skip to:
Content

BuddyPress.org

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#934 closed defect (bug) (fixed)

Friends with Bears Patch 1.0

Reported by: johnjamesjacoby's profile johnjamesjacoby Owned by: johnjamesjacoby's profile johnjamesjacoby
Milestone: 1.1 Priority: major
Severity: Version:
Component: Keywords: has-patch
Cc:

Description

Giant bulk patch from a week of testing the trunk while Andy was making friends with bears.

(This patch has no comments so it's up to you to make sense of this all. Apply at your own risk. )

:)

Attachments (1)

jjj-bear-safe-patch.patch (57.3 KB) - added by johnjamesjacoby 15 years ago.

Download all attachments as: .zip

Change History (7)

#1 @johnjamesjacoby
15 years ago

Just noticed this patch had an outdated buddypress.pot and bbpress too, so ignore all the changes for those guys. Arg

#2 @DJPaul
15 years ago

JJJ, any of these changes fix any of the open tickets?

#3 @apeatling
15 years ago

Going through this this morning and applying fixes where valid.

#4 @apeatling
15 years ago

A few things for next time, hopefully this will help:

Functions like bp_group_member_is_banned() should always echo. Each of those functions should have a get_() function bp_get_group_member_is_banned() that will always return.

if ( !$id ) will validate false on zero values. No need for ( !$id
$id == 0 )

The home template can be bypassed by adding <?php load_template( TEMPLATEPATH . '/index.php' ) ?> to that file in the child theme.

Templates should always try and avoid using curly braces. Stick to the <?php if ( ) : else : endif; ?> as it's less daunting and easier to follow for non-programmers.

Don't invoke actions in the template - so bp_core_delete_existing_avatar() shouldn't be called in the template. The URL should be checked in a screen function in the plugin, then that function run if needed.

Translation functions won't work with variables. They might work at run-time, however to translate the application a script runs and pulls out the translation text from the files. If that translation text is a variable then this cannot happen, as the script is not running and that value is obviously varies.

Hope that stuff helps, thanks for the patch.

#5 @apeatling
15 years ago

  • Resolution set to fixed
  • Status changed from new to closed

#6 @johnjamesjacoby
15 years ago

Thanks for the heads up on that stuff. I've got a few better patches I can apply to more specific tickets now that there's been another trunk update.

The work around for home.php is good too. Nice catch.

I am really scratching my head at the xprofile fields and translating them however. I need a way to run those group and field names through the gettext to translate them for the set users language. The way I have outlined in this patch seems to work perfectly as long as those variables are in the theme's po/mo files and load_theme_textdomain('theme'); is called in functions.php.

If I name the default name field "Display Name" and in my functions.php I have ('Display Name', 'theme_name'); then I can use a program like Poedit to snag "Display Name" and make a translation file out of it, which I can then translate to any language I choose and save and load like above. It works, really well.

On the other hand, if there is no po/mo for the theme, then the gettext just returns the variable without any failure and it gets spit out as "Display Name" regardless of the chosen language.

If this isn't correct, can you think of any other way to run the xprofile field names and group names through the or _e functions?

Note: See TracTickets for help on using tickets.