BuddyPress

Going to give it a few days to see if any issues pop up. If you’re comfortable doing a little testing, the branch of code is considered stable enough to be the next bug fix release. I’ll be combing through the 1.2.5 enhancements to see if there’s anything that can be snuck in next.

You can download it from the link on the bottom of of the page on our bug tracker and manually FTP up to your install, or svn up if you run your install in an SVN checkout of the 1.2 branch.

Thanks to everyone that’s contributed this round. Provided no major bugs crop up, look for 1.2.5 to drop sometime in the next day or two.

Hi @johnjamesjacoby. Yawn… a nice sunny Sunday morning, so I thought, “Why not?” Copied the files into the right folder, ran my local test installation and got;

Warning: require(BP_PLUGIN_DIR/bp-xprofile/bp-xprofile-admin.php) [function.require]: failed to open stream: No such file or directory in C:xampplitehtdocswp-contentpluginsbuddypressbp-core.php on line 8

Fatal error: require() [function.require]: Failed opening required ‘BP_PLUGIN_DIR/bp-xprofile/bp-xprofile-admin.php’ (include_path=’.;C:xampplitephpPEAR’) in C:xampplitehtdocswp-contentpluginsbuddypressbp-core.php on line 8

The readme.txt file is full of php code. Should I be renaming that and running it, or creating a new folder, or something? Haven’t tried a test version of BP yet (as you can tell) but am happy to if I can get it going.

You may want to try your download/upload again, as it appears something might have occurred during your file transfer.

Just checked the readme.txt and the files you show throwing an error, and they don’t contain anything like you’ve mentioned.

I updated the link in the first post to take you to the trac source page rather than the zip directly. Maybe try it that way?

Hmm… @johnjamesjacoby; I did as you suggested, then disabled all BP plugins and BP, deleted the BP files, and copied the new ones in. The readme.txt is still code by the way, starting with;

<?php
define ( 'BP_XPROFILE_DB_VERSION', '1870' );

/* Define the slug for the component */
if ( !defined( 'BP_XPROFILE_SLUG' ) )
etc., etc.

On activating the new BP I get;

Plugin could not be activated because it triggered a fatal error.
Fatal error: Cannot redeclare bp_loaded() (previously declared in C:xampplitehtdocswp-contentpluginsbuddypressbp-loader.php:55) in C:xampplitehtdocswp-contentpluginsbuddypressbp-loader.php on line 56

Everything else in WP and BP has been running fine so far.

There is no way this is a problem with the zip. I’ve checked it a few times now and it’s perfect.

There is guaranteed no PHP code in the readme.txt. This has to be a problem with your installation.

Try to download the zip again, and open readme.txt in a text editor. It is the standard readme.txt.

Just to clarify, it’s this link (as of now, anyway. Anyone coming to this thread after today will need to follow the trac link to get the latest revision)

@johnjamesjacoby ok I checkedout trunk which on reflection was not what I intended as that is bleeding edge soon to be tagged 1.3 isn’t it? On a side note there installed that for fun and it breaks straightaway with an undeclared function bp_page_title() which isn’t a new function!

It’s been a while since I used Subversion – mainly due to disliking it using the repo browser I am downloading:

http://svn.buddypress.org/branches/1.2

That is I presume is the current state of play for the 1.2 branch to be tagged as 1.2.5

@johnjamesjacoby; I’ve just downloaded the zip file again, and oddly enough the readme.txt is now as expected. No idea what was going on there! I’ll have a look at the latest BP soon and let you know how it is.

@hnla That is correct. The 1.2 branch of code is what we’re working with. Anything up until 1.3 will exist in that branch of code. SVN can be confusing, but it works really well for large project development with multiple developers and various states of progress; projects like WordPress and BuddyPress would be a nightmare without it.

@lincme Awesome; look forward to your response

CVS is vital for projects, and I had once pushed for using SVN on a web app project but was overruled by the rest of the team as they thought it would be too confusing! I was proved right and they regretted not implementing it. If I ever have cause to implement a CVS in the future I’ll probably be looking at GIT As at first glance it does seem one whole heap less confusing than SVN and like the decentralized approach.

The branch Installed with no issues despite having activated bleeding edge, deactivating it, removing bleeding edge folder, replacing with branch and reactivating, alf expected that to cause issues in the DB but at initial test all seems to be fine.

1.2.5 in testing and for now no problem thanks JJJ, a question about translation there will be changes?

@hnla Awesome thanks!

@arturo84 Good question… If there are, they are very few and probably tweaks to %s or %d that were incorrect. Could run a diff of fhe buddypress.pot and see what comes up different.

@johnjamesjacoby; Just a quick note, as I’m off out for a while. I noticed in the previous version of BP that the ‘?’ symbol on the profile age next to the avatar was reporting names wrongly. I hacked it in core, but now it’s back in the new version.

Eg., with a user ‘fred’, when logged in as fred the message is correct. But if I’m logged in as ‘admin’ I get this when looking at fred’s profile (notice ‘admin’ in second sentence);

@ fred is a unique identifier for admin that you can type into any message on this site. admin will be sent a notification and a link to your message any time you use it.

When I hacked it I removed the extra names, as they’re not required;

@ fred is a unique identifier for this person that you can type into any message. He/she will be sent a notification and a link to your message when you do this.

That message uses the bp_get_displayed_user_username() for the @ and bp_get_user_firstname( bp_get_displayed_user_fullname() ) for the 2nd/3rd references.

BUT if bp_get_displayed_user_fullname() is empty – bp_get_user_firstname falls back on $bp->loggedin_user->fullname

So either the core logic needs to change or you can filter on bp_get_user_firstname and just remove it

JJJ – bump the version number on the style.css?

@nuprn1 Just patched the branch for that issue. Care to test?

The style.css will get bumped when 1.2.5 is tagged.