[timskii]

Fel’s code works for 0.9.x. My code works for 1.0.

Worth making clear that 0.9 code will stop working once you upgrade to 1.0: Users with bespoke roles loose their capabilities, although those old roles do remain in the database, so can be found by new code.

[timskii]

In 1.0 Release Candidate 1, roles change dramatically from 0.9.x. I appreciate there is Role Manager, but I wanted a simple fix for an existing tweak based on Fel’s original code.

The code below creates a new role, adds capabilities that mimic the ‘member’ role, plus extra capabilities you specify.

global $bb_roles; // Get the master list of roles

$key = 'role_internal_name'; // Edit: Name of new role, as used internally by BBPress

$name = __('Role Public Name'); // Edit: Name of new role, as shown in public

$cap = array ( 'view_by_ip', ); // Edit: Add extra capabilities within this array. Must be pre-defined capabilities. Empty if you just wish to apply member capabilities.

$r = new BP_Role(); // New role class

$r->name = $key; // Assign the internal name

$r->capabilities = $bb_roles->role_objects[ 'member' ]->capabilities; // Copies member capabilities to the new role

foreach ( $cap as $add ) $r->capabilities[ $add ] = 1; // Adds extra capabilities

$bb_roles->role_objects[ $key ] = $r; // Adds the new role to $bb_roles

$bb_roles->role_names[ $key ] = $name; // Adds the new role to the list of role names

Hooked using: add_action/add_filter( ‘bb_got_roles’, ‘my_function_name’ );

I have no idea whether this is the most efficient way of doing this. So I’d welcome improvements.

[timskii]

The most basic solution looks something like this:

function wow_item( $text ) {

$text = preg_replace('|(<item>)(.*?)(</item>)|', '<a href="http://www.wowhead.com/?search=s2">s2</a>', $text);

return $text;

}

function wow_item_allowed_tags( $tags ) {

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

return $tags;

}

add_filter( 'bb_allowed_tags', 'wow_item_allowed_tags' );

add_filter( 'pre_post', 'wow_item' );

(replace the s2 with $2)

That would create <item> sudo-tags that link the name of the item to a Wowhead search. But that isn’t what you want: It just send a search query to Wowhead, without creating a tooltip.

Instead, such a plugin needs to go and ask Wowhead’s OpenSearch/RSS for a result, then come back and write out a complete item URL. Fortunately that query only needs to be done once, when the topic is first posted, not every time the post is displayed. Posting would get delayed, put probably only by a second, and only where the item tag was used. So there’s no need to cache the result. And 90% of the same code would work for anything with a OpenSearch output (most major sites).

This is something I’d like to have, and it’s been on my “to do” list for about a year… So, erm, soon! Maybe.

[timskii]

Google’s counter appears to be capped by the number of posts per page, in my case 20.

For example, the first result here shows “20 posts”, yet the topic runs to almost 400.

[timskii]

This topic is an interesting read.

I don’t see that BBPress should fit established norms for “forums”, which I personally think are horribly outdated: Trying to apply a nice neat academic/usenet ontology to the “Twitter generation”, who would rather just communicate. Now.

So I believe the prime role of “forum software” is to allow users to freely express themselves. Structuring and organising the information they post is a different challenge. “Categories” is essentially a response to that challenge. But can’t we do better?

Which ironically is where things like XML-RPC become interesting. Can I make use of that now? Probably not. But it surely has potential to cross-reference discussions.

BBPress is clearly still an early stage product. It’s certainly not there yet, even if technically it works. And almost by definition nobody is going to have clear view of where it is going.

(And for the record, personally the biggest annoyance with the core of BBPress (0.9.x) is that users cannot register using a unicode-style username – Russian, Chinese, Arabic, or even oddball European characters. It’s just… rude, right? Or is there a solution I’ve missed that doesn’t involve rewriting the core?)

[timskii]

Technically, it’s not just about pretty links and sitemaps. BBPress can produce much cleaner, better structured page code than certain other forum software.

Meta descriptions and keywords are still used by search engines where available. Personally I take the tags associated with each topic and add them to the list of keywords. In the keywords meta:

global $tags;

if($tags) {

foreach ($tags as $t) {

echo $t->raw_tag.', ';

}

}

That said, I still believe that asking whether something is SEO-friendly is asking the wrong question. Work on making forums user-friendly, which then attracts “quality” posts, and the search engines will follow.

[timskii]

As the code stands at the moment, it is a little too easy to lock yourself out. There may be a cleaner solution, but the following worked for me:

Try to login to BBPress with the WP admin. If that fails to give admin access to BBPress, the user mappings were either not set, were set at the wrong stage during integration, or were set such that nothing mapped to the Keymaster.

Backup the database (just in case a bad situation accidentally becomes terminal while you’re trying to fix it).

Using SQL access to the database (eg PhpMyAdmin), open up bb_topicmeta and delete the last few lines with meta_key starting wp_. That should reset everything, allowing you to get back into BBPress on the old Keymaster account and start again.

I found the order in which the integration settings were applied was critical. Your mileage may vary, but for me that was:

1. Edit User role map (ensure Admin is linked to Keymaster), and save.
2. Add “wp_” under User database table prefix and save.
3. Hit the User role map button again.
4. Finally complete the cookie setting and save.

[timskii]

All the integration code assumes you start with a blog and want to add a forum. However, if you start with a forum, chances are the forum’s user database will be far larger than the blog. The technique below outlines how I did it. This is entirely at your own risk. I’ve not gone over the standard things, like shared secret keys: I’m assuming you’ve read the basic integration guides.

0. You’ll need to be familiar with .htaccess, SQL at raw database level, and template hacks. If your level of expertise is “pressing buttons”, stop reading here. This is very easy to mess up, so make plenty of backups. Ideally test the whole conversion first, and probably prepare scripts to run if a lot of database changes are needed.

1. Block public access to the blog and forum for all except your IP using .htaccess.

2. In the database, rename wp_users and wp_usermeta. These won’t be used, but you will need them later to cross-reference old posts to new authors. I’m assuming a standard install that uses wp_ and bb_ as prefixes.

3. Copy bb_users and bb_usermeta to wp_users and wp_usermeta respectively. Keep the original tables for now.

4. Add the missing column via SQL: ALTER TABLE wp_users ADD user_activation_key varchar(60) NOT NULL default '';

5. Delete the WordPress install, but keep the old database tables (and plugins and themes). Install WordPress in its former position. Use an entirely new user name as your new WordPress admin. (The purpose of deleting and then installing WordPress is to create a genuinely new admin user in the table. For me, this was faster than manually adding an admin user and making sure all the correct permissions were set. You mileage may vary.)

6. How much extra work you need to do to your old WordPress tables depends on the number of authors that were active on WordPress: Using SQL, you’ll need to change all the old author IDs in wp_posts and wp_comments to match that author’s ID from the forum. It is possible there are other user references deep in the system, so be careful. I had little complexity to deal with. If your were the first to register for both your forum and blog, the important IDs may match perfectly already.

7. Most WordPress templates use the user’s display_name. This is unfortunately, because BBPress tends to use user_login. The result is that most WordPress references to user names will appear blank. You’ll either need to populate the display_name column, or hack around with your WordPress templates so that they use user_login. Template call get_the_author_login() is perfect for authors, but for comment references I had to use get_usermeta($user_id,’user_login’) or comment_author_link() where $user_id was 0. Messy. Since the admin side of WordPress uses display_name anyway, it is probably a lot easier to populate that column.

8. Your WordPress install should be now more-or-less working. Let’s return to the forum!

9. It is very easy to accidentally destroy the forum Keymaster, locking yourself out of the forum before integration is complete. If this happens, edit the table bb_topicmeta by deleting the final few lines with meta_key starting “wp_”.

10. On the forum admin, under WordPress Integration: Set the User role map such that Admin links to Keymaster and everyone else is a subscriber, and save. Add “wp_” under User database table prefix and save. Hit the User role map button again. Finally complete the cookie setting and save. The order is important – simply filling in all the boxes and saving can wipe out the old Keymaster access before the new one has been set up.

11. In WordPress, check the user list. I found that some user types did not convert automatically – notably moderators. Hopefully 99% of users will have been automatically assigned as subscribers. If you use a lot of plugins, take care that nothing conflicts. For example two separate plugins trying to write user meta data using the same key name. You may also wish to test a dummy registration and profile change.

12. Remove the old bb_users and bb_usermeta, and the copies of your original wp_users and wp_usermeta.

13. Remove the .htaccess blocks, and celebrate your newly integrated setup.

I’m now having fun trying to marry a second forum to the first WordPress-Forum pair. Everything is easy, until one tries to alter the admin permissions…

[timskii]

Previous thread on this topic.

[timskii]

Dreamhost does allow mod_rewrite. And technically they do support Multiviews, but as a .htaccess hack.

However. I remember having terrible trouble trying to configure BBPress to use Multiviews, because it appeared to work, but didn’t on certain pages. I ended up manually adding mod_rewrite.

As an aside, in automating anything like this, keep in mind that people like to do strange things with their directories. One of the annoyances of WordPress is that it assumes almost complete control of the layout of all directories below where it is installed.

[timskii]

What you are probably looking for is Flickr-in-a-box as a separate application with a common user database. Just as I’m looking for a Facebook-in-a-box application to run alongside the forum to foster the more personal social side. I don’t believe these should be core parts of the forum software, but there is a need for them somehow.

This notion of modular is important, because it is easy to get side-tracked and try and build the entire internet into one application. That might ultimately happen (mirroring the history of the Microsoft platform model), but at this stage of the game, nobody has the resources to do everything, so doing one part of the jigsaw well is the best plan.

BBPress should focus development on its core, which still has weaknesses. IMHO the most urgent is augmentation of futuristic geek-only features with the traditional ones that most users understand. The need for these functions has been acknowledged in BBPress’s design, however the current implementation is lacking because they are too complex for “normal people”.

So RSS needs to be mirrored with bespoke email notifications, because the only people that “get” RSS are ‘bloggers. Gravatars need to be mirrored with uploadable avatars, because the only people that get Gravatars are ‘bloggers.

Ok, I generalise on the “bloggers” part. But I know moderately technical people that can’t manage to set up a Gravatar, and have no idea what to do with an RSS feed. So the clueless masses stand no chance of using these features for the purpose they were designed.

BBPress’s killer feature at the moment is spam control without forcing users to jump through hoops just to register and post. Easy to work with code, and general lack of bloat are good to. But take a look at this, and tell me the #1 feature requirement of forum software (and if anyone can point to why that’s affecting phpBB 2 sites more than other software, I’m curious). That’s literally hundreds of spam posts an hour. Most admins faced with that kind of nightmare won’t be too worried about forcing users to host files elsewhere.

[timskii]

Broken JavaScript is a non-trivial, since it will trigger a very visible error message for some users… on essentially every topic page, when logged in. The error isn’t FireFox-specific.

Commenting out the contents of the “addLoadEvent( function() { // TopicMeta” block of code in topic-js.php appears to remove the error without creating new issues: The underlying AJAX behaviour is broken anyway. A proper fix would be appreciated.

Edit: Ok… playing with *this* forum, it seems there is already a fix: The equivalent code in https://bbpress.org/forums/bb-includes/js/topic-js.php?ver=433 appears to work just fine.