[timskii]

If BBPress is going to de-integrate with WordPress, it’s worth publicising that fact as soon as possible: Plenty of people will upgrade WordPress without checking that BBPress still works, while registration errors generally aren’t apparent to the administrator.

I hope this “bug” isn’t intended. Forcing a ‘blog registration isn’t a terribly straightforward solution for those that have historically structured everything to use forum registration…

[timskii]

Footnote: Due to Wowhead URL changes wowhead.com/?item needs to become wowhead.com/item (just below the edit options section of the code). You can also change wowhead.com/?search to wowhead.com/search , but that’s less critical.

[timskii]

Matt – That said, please consider some method for the forum administrator to turn Subscriptions off – just in case it gets out of hand. Canonical (bb-plugins) plugin, admin setting, whatever.

[timskii]

I’m clearly not awake yet (the email did arrive with Ben L.’s update), but:

It looks like it sends out an email regardless of how many minutes have elapsed since the last email.

This is going to get a few forums marked as spammers, because the sheer volume of almost-identical emails sent out could be huge. And imagine subscribing to a big forum topic, only to wake up the next morning to discover 20 emails telling you the topic had been updated. It doesn’t seem to scale well for very long and/or frequently updated topics.

Perhaps wait until the user does something on the forums before sending anything other then the first email? But BBPress doesn’t seem to record any actions against the user.

Added: A very crude test could only send out an email if the user’s last_posted time fell in between the time of this post and the previous post. It’s a very approx measure of activity, neither relating directly to the subscribed topic, nor reflecting a visit to only read. And would need some explanation (“you won’t be updated again until you post on the forums”). I already don’t like that as a solution, but it would put a cap the spamming, while still being somewhat useful as a means of getting the author back to the forum.

Second random thought: Since this function is already looking like something that might need to be turned off, perhaps it should be sitting in bb-plugins?

[timskii]

Checkbox under posting form, checked by default

I assume this checkbox auto-subscribes to this topic.

But that raises a side issues: User Settings. Remember the default per-user, as an account settings.

Currently I hack settings into the profile data (since they are easy to call out almost anywhere without special functions). Of course I also had to hack the profile data structure slightly to categorize each piece of profile data – both to split settings from public information, and do other things – like group similar data together, or define the input field type. Note that there is an array already in place to categorise profile information, although it refers to data by position (0,1,etc), not key name, which can makes hacking it messy.

Cookies would be the lazy option, but a tad confusing for users that don’t visit regularly, or visit from different computers.

(After 10 minutes I didn’t get anything – but it could be an email snarl-up.)

[timskii]

Display names are not unique (several members can have the same display name), so I hate to think what would happen if you tried to use them for login…

Display name is very important for any non-English user, since the login name can only contain standard English characters. It also gets used by people that change their “visual identity” without needing to create a new account (reasons are many, from marriage to joining a new gaming guild).

If you are concerned about spoofing, then add something to the template which clearly differentiates user roles in the template: Special icon, color changes. Regular forum users will get to know what a “real admin” looks like when they post, and anyone simply changing their display name to “Admin” will just look like a joke.

Another option would be to blacklist certain names… except people always find ways round by replacing certain characters.

If you’re still determined to get ride of the Display name, just don’t use it in your templates. If it doesn’t display against posts, it becomes irrelevant. You’re looking to hack my-templates/../post.php . If there isn’t a suitable function (I can’t remember), use bb_get_user(get_post_author_id()) there, which returns an array with all the author data.

[timskii]

This hack redirects non-editing users from their WordPress profile to their forum profile. Set $my_forums_directory to the directory or URL of the forums, and save it as a WordPress plugin.

Sometimes the page headers have already been sent, so wp_redirect() can’t be relied on, and instead the HTML has to perform the redirect.

WordPress users that can edit posts will still see the normal WordPress user screens. Since these screens don’t integrate well, it might be sensible to redirect admin users to /forums/bb-admin/users.php – but I’ve not done that here.

add_action('admin_head', 'my_wp_profile_redirect', 0);



function my_wp_profile_redirect() {

// Based on a part of Kim Parsell's https://wordpress.org/extend/plugins/wp-hide-dashboard/

global $parent_file, $current_user, $user_login;

$my_forums_directory = "/forums/"; // Set this to the directory or URL of the forums.

if (!current_user_can('edit_posts') && $parent_file == 'users.php') {

$my_profile_destination = $my_forums_directory."profile/".esc_attr( str_replace( " ", "-", strtolower( $user_login ) ) )."/edit";

if (!headers_sent()) {

wp_redirect($my_profile_destination);

} else {

echo '<meta http-equiv="refresh" content="0; url='.$my_profile_destination.'"><script type="text/javascript">document.location.href="'.$my_profile_destination.'"</script></head>';

echo '<body><a href="'.$my_profile_destination.'">View profile</a></body></html>';

}

exit();

}

}

[timskii]

Briefly on the bloat comments:

Forums are different from ‘blogs, and these differences need to be considered in the design:

• Users tend to interact more with forum pages – more page views, less use of remote feeds.
• Advertisers dislike forums – they’re much harder to fund using advertising.

So a “processor-intensive” forum can become a technical headache once you start seeing tens (or even hundreds) of thousands of users each day.

I’m in favour of features – BBPress clearly needs more to compete with mainstream expectations. The problem is specifically with features that are not optional – features that cannot be removed.

The logical approach is to include “standard” plugins in the distribution, which can be turned off as required. But that might still be problematic, if the most basic forum has to haul in the whole of WordPress before it does anything…

[timskii]

Cross-Domain Intergration

I’ve not seen anything about messy cross-domain integrations, so I thought I’d share my method. I’m using WordPress 2.8.6 with BBPress 1.0.2. Your mileage may vary on other versions. I suspect this method is not valid for 2.5/0.9.

The setup:

– example.com/blog

– example.com/forum

– example.org/forum

With shared user tables and database.

The config AUTH_KEY/SECURE_AUTH_KEY/LOGGED_IN_KEY should be the same for all (remember to add BB_ to the forum config files). Within the BBPress admin intergation, have the same auth/secure/logged in values for all forums (remember it’s the value shown within the WordPress options screen, not the values in the config files).

In this case cookiepath should be ‘/’ ($bb->cookiepath = ‘/’; // in bb-config and, define(‘COOKIEPATH’, ‘/’); // in wp-config). Set other $bb->style configurations as you wish.

Basically, everything is the same. Except: The Cookie Domain must be explicitly set**. And not always set to the same value.

In example.com/blog’s wp-config add: define(‘COOKIE_DOMAIN’,’.example.com’);

In example.com/forum’s bb-config add: $bb->cookiedomain = ‘.example.com’;

So far, so simple.

Now, in theory, example.org/forum can be set with $bb->cookiedomain = ‘.example.com’; // But I’ve not tried. Paranoid browsers would surely reject this. Instinctively having the forum rely on something that might look like a security risk is bad.

Instead, try adding this to example.org/forum’s bb-config: $bb->cookiedomain = ‘.example.org’; // Users will still need to log in separately when they switch domain, but all the other integration features seem to be fooled, with no adverse problems.

I’d welcome any feedback on this method. I’m still not sure this is the best approach.

( ** Not setting the cookie domain appears to work, until the user switches between domains – example.com/blog doesn’t simply fail to find a cookie set by example.org/forum, it may fail a fresh blog login until cookies are cleared. I’m not sure exactly what’s happening, but it’s messy.)

[timskii]

You need to recognize that there are distinct groups of people with different answers. For example:

Plugin Programmers: Lack of stability of core behavior and data structure over the last year-or-so has become a real grind. A lot of 0.9 code partly stopped working in 1.0 – “partly” being particularly annoying, because those issues are harder to spot. For the rest of us, that grind means that plugins cannot be relied upon: There’s a risk of being unable to upgrade because a key plugin won’t work anymore. While you can argue “that’s inevitable”, if important features rely on plugins, a lot more care needs to be taken to ensure those plugins don’t break.

Server Administrators: One look at this forum tells you all you need to know. WordPress’s installation is accessible to people that know almost nothing about teh internet. In contrast, BBPress integration sucks: Manual, generally bewildering, and prone to unexplained failures. Worth adding here that there is a valid “no bloat please” option: BBPress is currently attractive precisely because it can deal with massive amounts of traffic. Not everyone wants to re-create the internet in one piece of software.

End Users: Joanna Average forum reader doesn’t care about any of that, and is probably keener on things like WYSYWYG, email, etc.

Obviously these groups influence one another, but it seems likely that this poll will be swamped by the desires of the Administrator group. Now, if nobody ever installs BBPress, nobody will get to use it or write plugins for it – so there’s no harm keeping the administrators happy. But don’t forget the other groups – they’re also important!

[timskii]

I concluded this issue was related to the use of the Hidden Forums plugin, which continued to paginate all the topics it couldn’t see.

However, I then stopped using the function in my templates, so would not have noticed other bugs.

[timskii]

First attempt at providing Wowhead item links. Please post any bugs or weirdness. This requires BBPress 1.0 RC 3+ and PHP 5+ . It has no cache, so may not be suited to ultra-high volume forums.

<?php

/*

Plugin Name: Simple Wowhead Item Links

Plugin Description: Adds item sudo-html to create links to Wowhead.

Author: Tim Howgego

Author URI: http://timhowgego.com/

Version: 0.1.rc

*/



/*

Requirements:



* PHP 5 or above.

* BBPress 1.0 RC3 or above.



Install:



* Copy the file to the "my-plugins" directory.

* Active the plugin within the Admin interface.



Customising:



* Default language is English. For other languages, edit $lang (in bb_wowhead_item_search) below.

* Default will color items which are uncommon or rarer. To change this edit $commonest_color (in bb_wowhead_item_search) below.



Using:



* Users must enter the following "sudo-HTML" code within their posts: <item>Name</item> - where name is the correct name of the item to be linked to.

* Wowhead is queried each time a new link is posted. Once the link is created, it is stored as a complete link within the post. A cache should not be required given the amount of traffic on most forums.

* If Wowhead is unavailable (often due to maintenance), or some other error occurs, the link created will simply point to a Wowhead search for the item.



Thanks Drexle for some ideas.

*/



function bb_wowhead_item_search( $find ) {



// Edit Options:

$lang = 'www'; // Language: www (english), de, fr, es, ru.

$commonest_color = 2; // Only color item qualities of this number or higher. 0 colors all items. 2 does not color white and grey items. 101 (or "high") colors nothing.

// Stop Editing



$f = trim ( $find );

$s = 'http://'.$lang.'.wowhead.com/?item='.esc_attr( str_replace(' ', '+', strtolower( $f ) ) ).'&xml';

if ( function_exists("curl_init") ) {

$ch = curl_init();

curl_setopt( $ch, CURLOPT_URL, $s );

curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true );

curl_setopt( $ch, CURLOPT_CONNECTTIMEOUT, 3 );

$output = curl_exec( $ch );

curl_close( $ch );

} else {

$h = fopen( $s, "r" );

while ( !feof( $h ) ) $output .= fread( $h, 8192 );

fclose( $h );

}

if ( $output and function_exists("simplexml_load_string") ) {

$xml = simplexml_load_string( $output );

$link = $xml->item->link;

$name = $xml->item->name;

if ( $link and $name ) {

$quality = $xml->item->quality[id];

$class = ( $quality and ( $quality >= $commonest_color ) ) ? ' class="q'.esc_attr( $quality ).'"' : ' class="nocolor"';

$result = '<a href="'.esc_attr( $link ).'" title="Wowhead - '.esc_attr( $name ).'."'.$class.'>'.esc_html( $name ).'</a>';

}

}

if ( $result ) return $result;

else return '<a href="http://'.$lang.'.wowhead.com/?search='.esc_attr( $f ).'" title="Wowhead - '.esc_attr( $f ).'.">'.esc_html( $f ).'</a>';

}



function bb_wowhead_item_link( $text ) {

$text = preg_replace('|(<item>)(.*?)(</item>)|e', "bb_wowhead_item_search('\2')", $text);

return $text;

}



function bb_wowhead_item_tags( $tags ) {

$tags['item'] = array();

$tags['a'] = array( 'href' => array(), 'title' => array(), 'class' => array(), 'rel' => array() );

return $tags;

}



function bb_wowhead_item_header() {

echo '<script language="JavaScript" type="text/javascript" src="http://static.wowhead.com/widgets/power.js"></script>'."n";

}



add_filter( 'bb_allowed_tags', 'bb_wowhead_item_tags' );

add_filter( 'pre_post', 'bb_wowhead_item_link' );

add_action( 'bb_head', 'bb_wowhead_item_header' ); // Comment this line out if the Wowhead javascript file already exists in the header



?>

[timskii]

/statistics.php

[timskii]

Query times are indeed much improved – similar to 0.9 again. Thanks for your work on that.

[timskii]

Ipstenu, there is further information here. In my case, there are serious errors when tagging using default everything, with no plugins. However the issue seems to relate to tags which existed prior to an upgrade from 0.9, so perhaps does not affect a fresh install?

[timskii]

For Gravatars:

echo bb_get_avatar( bb_get_current_user_info( ‘id’ ), 32 )

Where 32 is the pixel size of the Gravatar.

(That’s 1.0 code… not sure about 0.9.)

[timskii]

https://bbpress.org/forums/topic/can-sticky-get-a-new-color-when-something-new-is-posted ?

[timskii]

Extra keywords are based on tags. If there are no tags on the page, there are not extra keywords.

All this does is take meta information that is already available within the data structure of the forum, and put it into an HTML meta field.

One could gather additional meta information by distilling the content of pages. But I suspect Google/etc would be better at distilling the content of the page automatically than any plugin. So I don’t anticipate making this much more complicated, although there are no doubt a few easy enhancements that can be made.

[timskii]

Below is the code I wrote for “SEO”-related tweaks. It tries to fill the description meta with something relevant, and adds keywords based on a combination of tags and site-wide words (added via the admin screen). It’s still rough round the edges. For example, it will produce duplicate descriptions on multi-page topics, and descriptions may not be terribly different from the title tag.

<?php

/*

Plugin Name: SEO Tweaks

Description: Adds description and keywords meta to the header.

Author: Tim Howgego

Author URI: http://timhowgego.com/

Version: 0.1.rc

*/



add_action('bb_admin_menu_generator', 'seo_config_menu');

add_action('bb_admin-header.php', 'seo_config_process');



add_action('bb_head', 'seo_meta_description');

add_action('bb_head', 'seo_meta_keywords');



function seo_meta_description() {



switch ( bb_get_location() ) {



case 'topic-page':

$description = get_topic_title()." - ".bb_get_option( 'description' );

break;



case 'forum-page':

$description = get_forum_description();

break;



case 'tag-page':

if ( is_bb_tag() ) {

$description = __('Topics tagged')." ".bb_get_tag_name();

} else {

$description = __('List of tagged topics.');

}

break;



case 'profile-page':

$description = __('Profile for')." ".get_user_display_name()." - ".__('includes contact information and posting history.');

break;



case 'view-page':

$description = get_view_name()." - ".bb_get_option( 'description' );

break;



default:

$description = bb_get_option( 'description' );

break;

}



echo '<meta name="description" content="'.attribute_escape( $description ).'" />'."n";



}



function seo_meta_keywords() {



// Includes enhancements by _ck_



global $tags;

$keywords = array();



if ( !empty( $tags ) ) {

foreach ( $tags as $t ) {

$keywords[] = $t->raw_tag;

}

}



$default_keywords = bb_get_option( 'seo_keywords' );



if ( count( $default_keywords ) >0 ) {

$keywords[] = $default_keywords;

}



if ( count( $keywords ) >0 ) {

echo '<meta name="keywords" content="'.attribute_escape( implode( ", ", $keywords ) ).'" />'."n";

}

}



function seo_config_menu() {

bb_admin_add_submenu(__('SEO'), 'manage_plugins', 'seo_config_page');

}



function seo_config_page() {



?>

<h2><?php _e('SEO Tweaks Configuration'); ?></h2>



<form class="options" method="post" action="">



<fieldset>

<p><strong><label for="seo_keywords"><?php _e('Default keywords') ?></label></strong> (<?php _e('these words will be attached to every page, so only use words that describe the forum's overall content'); ?>):</p>

<textarea name="seo_keywords" id="seo_keywords" cols="100" rows="4"><?php bb_form_option( 'seo_keywords' ); ?></textarea>

<p><?php _e('Separate keywords with a comma. No formatting.'); ?></p>

</fieldset>



<fieldset>

<?php bb_nonce_field( 'seo_config' ); ?>

<input type="hidden" name="action" id="action" value="update_seo_config" />

<input type="submit" name="submit" id="submit" value="<?php _e('Save Changes &raquo;') ?>" />

</fieldset>



</form>

<?php



}



function seo_config_process() {



if ($_POST['action'] == 'update_seo_config') {



bb_check_admin_referer( 'seo_config' );



if ($_POST['seo_keywords']) {

$value = htmlentities( trim( $_POST['seo_keywords'] ) , ENT_NOQUOTES );

if ($value) {

bb_update_option( 'seo_keywords', $value );

} else {

bb_delete_option( 'seo_keywords' );

}

} else {

bb_delete_option( 'seo_keywords' );

}



$goback = add_query_arg( 'seo_updated', 'true', wp_get_referer() );

bb_safe_redirect( $goback );

exit;

}



if ($_GET['seo_updated']) {

bb_admin_notice( __('Changes saved.') );

}



}



?>

[timskii]

If you upgraded WordPress, the wp-config file may not contain all the keys. Generate them here, and add them to WP. The first 3 of the WP keys are them added to BBPress (via the admin screen):

• WordPress “auth” cookie salt = AUTH_KEY
• WordPress “secure auth” cookie salt = SECURE_AUTH_KEY
• WordPress “logged in” cookie salt = LOGGED_IN_KEY

[timskii]

To clarify my optimization comment slightly:

It may be optimized for memcached, since all those individual pieces of user information rarely change, so all those queries will fall straight to the memory, which becomes ruthlessly efficient. If all the information used on each page is queried together, memcached would fill up with page-specific results, rather than user-specific results: So many individual queries is logically more efficient if you are caching the results of those queries.

There is some logic in this: The structure still works reasonably well on smaller (often shared) setups, where caching can be technically difficult to implement. However BBPress is aiming to support large scale deployment, which is almost inevitably going to mean the use of caching. If you can only write the code optimally for one of those users, optimizing it for someone that can save whole machines in the process, is sensible.

[timskii]

The memcached information is useful to know. And based on what I’ve found below, will logically make an absolutely huge difference. Closer to “requires memcached” on a busy forum.

You see, I’ve done some more tests. And BBPress seems to do a lot of simple queries to check information that generally doesn’t change.

I’ve hooked up _ck_’s excellent BB-Benchmark, and started looking for patterns. I assume this picks up everything in 1.0.

As a general rule, page rendering (after queries) is very slightly slower with 1.0. That can probably be explained simply by twice the volume (in bytes) of files typically being executed from 0.9.4 to 1.0. Only about 10ms difference. So, not an issue.

The crux of the problem is the volume of queries. The fastest query execution is 1ms – measured, it seems, to within 0.1ms – although I’m unsure of that accuracy. This may be due to the way the database is hosted – mySQL is on a separate machine, which is logically going to impose a delay in getting results back.

1.0’s slowest query is faster than 0.9.4. But 1.0 executes vastly more queries: It’s almost inevitable that 40 queries will takes longer to execute than 10 queries, because there is such a significant overhead associated with “running a query”, regardless of its complexity.

Here are examples of what I found:

On the front page, forum views, and tag views, many pairs of queries are being run that look like:

SELECT * FROM wp_users WHERE ID = ‘n’

SELECT meta_key, meta_value FROM wp_usermeta WHERE user_id = ‘n’ /* WP_Users::append_meta */

My first thought was that my templates or plugins were broken. But disabling everything, and switching to the default theme, still causes all these pairs of queries to be executed.

The only reason I can see for the first query is to extract the display name for each of the last post authors. I can’t see any requirement for the second query, unless you were trying to augment the name with some extra information, like a title.

The topic table contains a last poster field, but it cannot contain the display name, presumably because the display name can be changed on a whim, while the old username was unchanging. If you have a lot of active posters (rather than a handful), a 20-post-per-page view could easily require 40 individual queries, just to check a piece of information that probably has not changed.

Now, we can argue that there should be some element of caching of the display name in the topics table. I wouldn’t have a problem with, for example, always seeing the name the user displayed when they posted, rather than the name they are currently using. But there’s also a compromise position, where the last poster name is only checked against wp_users at intervals.

Profile views repeat this a lot:

SELECT meta_key, meta_value FROM bb_meta WHERE object_type = ‘bb_post’ AND object_id = n /* bb_append_meta */

And I’m only displaying recent replies.

Turning to a topic page. I’ve looked at the first 20 posts in a 260+ post-long topic. A real mix of users, some who have added a lot of custom data (I allow quite a lot to be added, which is stored in wp_usermeta). This is painful: 30ms total query time on 0.9.4, 120ms on 1.0. 14 queries plays 79 queries.

Again, the key weakness is duplication of ostensibly similar queries. Line after line of:

SELECT meta_key, meta_value FROM bb_meta WHERE object_type = ‘bb_post’ AND object_id = n /* bb_append_meta */

or

SELECT * FROM wp_users WHERE ID = ‘n’

or

SELECT post_id FROM bb_posts WHERE topic_id = n AND post_status = 0 ORDER BY post_id ASC LIMIT 1

In contrast, 0.9.4 manages to decide all the IDs it needs, throws them all into one query, and presumably lets the PHP split out the results. The wp_usermeta data continues to be pulled out in such a manner:

SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE user_id IN (n,n,n,n…) /* WP_Users::append_meta */

In 3ms. Bargain.

Keep in mind, you won’t see this pattern if your forum contains 20 posts by you. You must have the variety of posters, that tends to only be found on larger forums.

My gut feeling is that some of the loops aren’t terribly well optimized. Or not well optimized for remote databases. Or not well optimized for operation without a secondary cache. Something’s instinctively not right.

[timskii]

To put some more detail on the “bloat” thing: I’m comparing databases with identical sets of posts/users, and very similar templates/plugins (I’d hope the 1.0RC code would be better). One setup is 0.9.4/2.5.1, the other 1.0RC/2.7.1.

With 0.9.4, my forum front page is processed consistently in under 100ms (when repeatedly refreshed). With 1.0, 150-200ms is more typical. For reference a simple 2.5.1 (without wp-cache active) WordPress front page on the same hardware is just under 100ms, 2.7.1 is just over 100ms.

That’s barely noticeable to the user, who often experiences a few 100ms of latency, and is still more likely to be slowed down waiting for adverts/graphics than the forum software to dispatch the HTML. But it evidently is slower. I don’t have a reliable way to break down that extra processing time… but I’m instinctively drawn to 11 queries vs 45 queries. Probably because those are the only other number I can see!

[timskii]

If you simply visit /bb-reset-password.php in 0.9.4 the template options are if($reset) and else. The first says “Your password has been reset…”, the second “An email has been sent…”. So if the file is accessed out of context, it is doomed report the else message, even when absolutely nothing has been sent.

Bug-wise, it’s re-written in 1.0.

[timskii]

I’ve been “testing” 1.0 out privately over the last week, primarily by re-writing my custom code and templates, and then working through every user operation (to check both my changes, and the underlying software). So I’ll try and play devil’s advocate to _ck_’s “don’t upgrade!”

From the user’s perspective, little has changed. The most significant feature to pull out is the use of Display Names. That’s a huge plus on an “international” forum, because users can now set their names to contain non-English characters. And there’s no need to workaround empty display names in WordPress (when a user registers via BBPress).

Templating is similarly unchanged. About the most significant change is that the contents of tag-form.php can no longer be altered via a template – which was likely never required anyway. Semantically, existing oddities remain (like the profile edit is still a table), and usability can be clunky in places (when you register successfully, there’s a message that tells you to log in, but nothing immediately helpful, like a login screen).

Plugins very much depends on how deep they go. The only place I stumbled was in user roles, where the underlying code had completely altered. But I’m not using many plugins, and the custom code I had been using, I’d been prepared to rewrite. (Most of it was a mess anyway!) A clear “your mileage may vary” caveat, and particular risk if one doesn’t understand enough programming to work round anything that breaks.

Technically, 1.0 feels fairly solid. I have found glitches, but nothing worse than some of the 0.9 versions. 1.0 does perform many more database queries. Like 50 on certain pages. Although it is hard for me to assess the load implications without running it on a public site. Integration worked OK as an upgrade, once I’d realised that the upgrade did not automatically add the new cookie-related keys (which needed to be added manually to the existing config files). The whole package feels more “bloated”, but that may be more the fault of WordPress than BBPress. I just hope BBPress doesn’t evolve into the messy, feature-overloaded forum software I had been trying to avoid.

So, if I was just running BBPress, on balance I’d stick with 0.9, at least until the dust settles on 1.0.

But. There’s a but.

If nobody uses 1.0, hardly anyone is debugging it, hardly anything gets fixed, and so on. There’s a danger of putting 1.0 on the shelf, waiting for someone else to finish it, and then wondering why the bugs never get found. So even if you aren’t running it on a live site, it might be useful to try it out privately.

Rightly or wrongly, WordPress 2.5.1 makes me increasingly nervous: As times goes on, I’m going to find plugins and templates that aren’t designed for that version. And while it is claimed that 2.5.1 has no security flaws, if almost nobody is using it, the chance of any flaw getting found and reported is also low. In contrast, the latest version is sure to get picked apart and patched back up very quickly.

And then I started to look at BuddyPress, and… I don’t even know if it’s possible to run that on top of 2.5.1. But you can see the way I’m starting to think: An old BBPress is itself rooting me in the past. And while I knew it was unfinished software when I started using it, I had rather assumed it would at least keep pace with WordPress, not get left a year behind.

So right now, it’s a rather person decision. All other things being equal, I tend to agree with _ck_.

However, I see a lot of WordPress 2.7+ blogs with phpBB forums hosted alongside. And naturally no integration between them. In the near future, that’s the first big, obvious “market” for BBPress. Yet almost all those people need compatability with the latest WordPress. For us “early adopters” that’s important: Some of those new BBPress users will write plugins and templates, and they won’t bother trying to support outdated code. Once that starts to happen, old 0.9 users will find they are missing out – which will probably be the time for most existing users to upgrade.