[woodlandstar]

Plugins

bb signatures

bozo

Admin add user

Approve User Registration

bb code lite

[Ipstenu (Mika Epstein)]

I started with a WP2.7 blog so I had no choice but to jump into 1.0 land (this was before the workarounds for .9 were found). And I regret nothing. I have few issues (one, really, but I have a trac ticket #1076 and it seems to be a user pagination vs pretty permalinks issue) and the rest… my users have never noticed.

The current admin experience on trunk is a bit wild Some work needs doing, but I like that effort is being made to mimic WP again. I have no issues with the plugins I use (very few plugins) and other than my own stupidity of developing code on a live site, I like 1.0. Will it bloat? Yeah, but since I’m headed down the path of ‘community’ site and will, in all likelihood, end up with BuddyPress one day, I’m not too worried.

On developer principle of the whole thing, I’m with _ck_ with a caveat.

If you’re a nerd who likes mucking around with code, who doesn’t mind bleeding edge, who is comfortable with blowing yourself up and cleaning up, you’ll be fine with 1.0. If you KNOW what you’re getting into (that is you’re reading and are aware of and comfortable with everyone’s troubles), then you’re fine. If you just go ‘Yeah yeah SHINY!’ then you’re in for a world of pain with any product. If you’re not a little bit of a developer, if you’re not good with google, if you’re not okay with things breaking weirdly, then stay on 0.9 and you’ll be happier. Heck, we’ll be happier cause we won’t have to help you dig out from a hole you weren’t prepared to be in

Be aware of what you’re getting into with 1.0 and have fun. Or not. Either way works

[thekmen]

I can’t really add to the argument except to say that I never tried any older versions, so downloaded RC1 last week & love it. I only have one issue mentioned in another thread, I can’t get the function bb_new_topic_link();

to work but have worked around that for the moment using hardcoded links. The function is only used in 3 places so it’s not much of an issue.

I am using it on a live site for less than a week now – http://xfactor-updates.com/forum/ – its quiet at the moment but will get busy & fully tested in the next few months

As WordPress 2.8 is due out the door any day with it’s new widget classes, a lot of themes will have to be upgraded to take advantage of the changes so I can see a lot of people leaving WordPress 2.5, 2.72 and so on behind and making the switch to 2.8.

The sooner bbPress can be fully integrated with WP 2.8 the better in my opinion.

[_ck_]

bbPress will likely travel the same path as WordPress

so bloat and uneven internal feature adoption is unavoidable

but my hope is it will happen in far later versions than sooner.

I will fondly remember and miss the “good old” 0.9 days

Note I’m not saying NEVER use 1.0, I’m saying for an active site don’t rush into it and perhaps for any new site, don’t start with it, since it can be upgraded.

Template developers should not use 1.0 until it has extremely wide adoption as it’s features are not backwards compatible, but any template you make in 0.9 will work in 1.0 with virtually no modifications.

timskii don’t worry about 1.0 not being debugged enough, even before RC1 it has a 10% adoption:

1.0a6 : 5%

1.0 ? : 5% (1.0 using pre-a6)

0.9.x : 52%

0.8.x : 35% (this is likely wrong, it includes 0.8 installs that upgraded to 0.9)

[johnhiler]

Great points, timskii!

One note – it’s now possible to integrate bbPress v.9 with the latest versions of WordPress, using either of the plugins here:

https://bbpress.org/plugins/topic/freshly-baked-cookies/

http://superann.com/2009/02/26/wordpress-26-27-bbpress-09-cookie-integration-plugin/

I share your concerns about bbPress becoming bloated. I hope the platform doesn’t go down that path… that would be the main thing that would eventually drive me off of bbPress.

[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.

[_ck_]

I highly encourage the use of 0.9 until (and maybe even through) 2010

1.0 is a different creature internally than 0.9 and while 0.9 has a few years of development and debugging (and compatible with most plugins) 1.0 has none of these things.

IMHO 1.0 should *never* have been called 1.0

0.9 should have been finalized and released as 1.0

and then what is now being called 1.0 should have been called 1.5

People simply do not understand that 1.0 is not some kind of minor upgrade to 0.9 with just incremental fixes – large portions of code have been changed or replaced entirely. Certain database tables have been completely replaced into a much more complex scheme, etc.

Remember, you can *never* downgrade once you start with/upgrade to 1.0

but there is always an upgrade path from 0.9 to 1.0

(someone someday might be crazy enough to write a downgrade routine for 1.0 to downgrade the database tables but it won’t be me)

There is also no clear path for bbPress from Automattic.

They are replacing the WP code base with WPMU, which means the purpose of the extremely labor-intensive drive to integrate BackPress into bbPress 1.0 is now even more unclear.

I’ve yet to see a single feature/ability in 1.0 that you will miss with 0.9

ps. I also think WP 2.5 is the last decent version of WP made but that’s for another forum

[johnhiler]

I’m not sure either. But the stylesheet is showing up now! The design is a bit more narrow than the one on bbpress, but hopefully that’s a change you made!

[johnhiler]

chmod is a way to change your file permission settings. More on that here.

https://codex.wordpress.org/Changing_File_Permissions

[johnhiler]

Nope! bbPress has its own signin, and its own theme/plugin system… you can use it as a standalone no problem!

[citizenkeith]

I have Theme Switcher plugin installed, and recently installed the new bbPM plugin. Each plugin works fine, until they had to play together… I switched a theme on the PM page and it looked as though Theme Switcher was imposing pretty permalinks, causing bbPM to break.

What the heck, I thought, I’ll try pretty permalinks. I changed my settings, added the .htaccess file and all hell broke loose. The number of posts per page in a topic changed, and it was impossible to navigate multi-page threads (in a forum like mine, where friends hang out and chat, this is a big problem). For example, the thread correctly displayed 27 pages (30 posts per page), but when you went to page 10-27, no posts appeared. Turns out they were all grouped in the first 10 pages with tons of posts per page.

I switched back to regular permalinks, deleted my .htaccess file, but the problem persisted. I tried Recounting everything, and got this error for every recount:

Database error: [Query was empty]



Caller: [unavailable]

I finally turned off _ck_’s “Change Number of Front Page Topics” plugin (which I don’t think is an official plugin), and finally everything went back to normal. But I still can’t recount, and I still can’t use “Change Number of Front Page Topics” which I’ve been using without a problem for at least a year.

Any ideas where to start troubleshooting this one?

I’m running RC1 on Media Temple’s Grid Service. Recently switched over to Media Temple after using Dream Host for about a year.

[Ipstenu (Mika Epstein)]

I think you’d have to go to the guy who actually wrote BB in this case I just ‘pluginized’ it.

[thekmen]

Hi all,

Just wondering if anyone has a shared login working with bbPress RC1 & WordPress 2.8 beta?

I have WordPress installed at root level and bbPress in a sub directory using the WordPress users table.

When setting up bbPress I went through all the integration settings.

Now users can log in at either end no problem, it’s just that they are not logged in on the other end when visiting the forum/wordpress.

I then regenerated the keys using http://api.wordpress.org/secret-key/1.1/ and placed these in both config files with the required BB_ bit for the bbPress config.

I added the following to my bbPress config:

$bb->wp_siteurl = 'http://site.com/';

// that's your WordPress URL, not bbPress



$bb->wp_home = 'http://site.com/';

// almost always the same as siteurl unless you tinker



$bb->wp_table_prefix = 'wp_';

// should almost always be wp_ unless you tinkered



$bb->user_bbdb_name = 'xxxx';

// this is the MYSQL database name for *WordPress*

// you can copy it right out of WordPress !



$bb->user_bbdb_user = 'xxxx';

// this is the MYSQL user name for *WordPress*

// you can copy it right out of WordPress !



$bb->user_bbdb_password = 'xxxx';

// this is the MYSQL password for *WordPress*

// you can copy it right out of WordPress !



$bb->user_bbdb_host = 'localhost';

// 99.9% of the time it's going to be localhost, unless you are on DreamHost or some other weird ISP



$bb->custom_user_table = 'wp_users';

// 99.9% of the time it's going to be wp_users



$bb->custom_user_meta_table = 'wp_usermeta';

// 99.9% of the time it's going to be wp_usermeta



$bb->authcookie = 'auth code i set with wp plugin';

// in theory you should be able to leave this out

// but this is going to be copied from WordPress cookie

// this *must* match the WordPress setting

// do NOT use the 1234567 part, use your own cookiehash from WordPress - see the note at the very bottom



$bb->cookiedomain = '.site.com';

// note the leading DOT - this is important

// this *must* match the WordPress setting



$bb->cookiepath = '/';

// I *highly* recommend you set the cookie path to /

// this *must* match the WordPress setting



$bb->sitecookiepath = '/';

// I *highly* recommend you set the cookie path to /

// this *must* match the WordPress setting



$wp->cookiedomain = '.site.com';

define(COOKIE_DOMAIN,'.site.com');

// note the leading DOT - this is important

// we list both for WordPress legacy compatibility



$wp->cookiepath = '/';

$wp->sitecookiepath = '/';

define('COOKIEPATH', '/' );

define('SITECOOKIEPATH', '/');

// I *highly* recommend you set the cookie path to /

Now when I log in at the bbPress side, a wordpress_logged_in_xxxxx cookie is created but then when I visit the wordpress end, I am not logged in.

When I do then log in on the WP end, it creates another wordpress_logged_in_xxxxx cookie, the cookie names are both the exact same but their values are different.

Anybody got any tips on how to fix this?

[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.

[rdsr]

Hey i got this working, the only problem is, when i log into WP or BBpress, it logs the other out. Its not a big deal but i was just curious if theres a way to fix this. Thanks

[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.

[Atsutane]

@johnhiler

I want to correct something here. Bbpress latests discussion is a wordpress plugin, not a bbpress plugin. It should not conflict with any bbpress function.

[john500]

<bbPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘t posted was that when is Rugby Canada going to have a stadium policy. Are we go’ at line 1]

INSERT INTO bb3_posts (topic_id,post_text,post_time,poster_id,poster_ip,post_status,post_position,forum_id) VALUES (’57’,”,’2009-06-01 05:18:02′,’13’,’24.80.235.218′,’0′,’4′,’2′)

Warning: Cannot modify header information – headers already sent by (output started at /home/content/a/l/e/alexander9999/html/forums/bb-includes/db-mysql.php:130) in /home/content/a/l/e/alexander9999/html/forums/bb-includes/pluggable.php on line 232>

Here is message minus the post. The forum is on this site Canadianrugby.ca

there doesn’t seem to be a problem with latest discussions but with postings on the Forum it seems that a long message and perhaps punctuation such as , or apostrophe can cause the error and the post not posting

[citizenkeith]

@windhamdavid Thanks! I’m familiar with the O’Reilly series (loved the CSS book) but didn’t know if this was good for absolute newbs. I’ll check it out.

[chrishajer]

Does *your* database, the one you’re using, support it though? Apparently, it does not, according to the error messages. Unless of course the error message is erroneous.

You can do this from a MySQL command line or phpMyAdmin once you connect to your database:

SHOW COLLATION LIKE 'utf8%';

That will show you all collations that begin with utf8.

[john500]

Can anyone help me with this issue. I knew that BBpress.org didn’t have paid support but I thought I could get some assistance from the forum or community. My developer can’t get it fixed and I need some assistance. Now the problem is that when you make a post it says that it is interfering with the topic header and the post is left blank. Here is the error message.

bbPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘t posted was that when is Rugby Canada going to have a stadium policy. Are we g’ at line 1]

INSERT INTO bb3_posts (topic_id,post_text,post_time,poster_id,poster_ip,post_status,post_position,forum_id) VALUES (’57’,’

Warning: Cannot modify header information – headers already sent by (output started at /home/content/a/l/e/alexander9999/html/forums/bb-includes/db-mysql.php:130) in /home/content/a/l/e/alexander9999/html/forums/bb-includes/pluggable.php on line 232

[_ck_]

This would be a very good beginners plugin to write, it’s very simple (other than the admin interface).

bbPress fetches stickies via a separate query (which I have always found to be a waste, except for this case) and you could manipulate the results before the final template is loaded.

For example on the front-page if you looks at index.php

you’ll see that

$super_stickies = get_sticky_topics();

and then there is

do_action( 'bb_index.php', '' );

so you hook the action bb_index.php

and then you do a global on $super_stickies

and then you manipulate the order of the array as desired.

for forum pages it’s

$stickies = get_sticky_topics( $forum_id, $page );

and

do_action( 'bb_forum.php', $forum_id );

same concept

That part would take less than an hour to write.

and you’d store the order in the topicmeta

But the part that will take much more time is the admin interface.

Instead you could simply add an extra field on the post edit page that only admin would see and let them chose the topic stickiness priority.

(this is not a plugin I will be writing)

[michael3185]

1. Fixed. Finally got to tags.php (duh) after trawling through core files. Moral: don’t work past 2am.

2. Not resolved. I’ve searched through CSS tutorials on various sites, but can’t find an easy test for the browser type without using php or javascript. Is there a way to set a font size in CSS at, say, 10pt for IE, and 11pt for any other browser?

Also – for moderators – I’m not bumping deliberately. I’ve noticed others editing posts now and then, as I have, to say they don’t require help any longer. Can’t the allowed edit time be changed to 24 hours or something like that? Maybe even let members delete their post if it has no replies? It’d keep things tidier.

[Edit]

For the font size issue, could a different stylesheet be selected by browser type, based on something like the code _ck_ gave to stop IE8 messing up the header?

function fix_ie8() {if (strpos($_SERVER,”MSIE 8″)) {header(“X-UA-Compatible: IE=7”);}}

add_action(‘bb_send_headers’,’fix_ie8′);

I can see how this works, but don’t know how to modify it to discover any IE browser version, and select style_ie.css, else select style.css – any ideas folks..?

[chrishajer]

Sounds like your database does not support uft8_general_ci collation? Maybe you need to set define('BBDB_COLLATE', ''); in your bb-config.php to something the server supports? Maybe you can look at the collation for the existing WPMU tables, and just use that in bb-config.php?

Never seen this before, just guessing at a solution.

[RWB]

I dleted the tables. I deleted the user files for bbpress.

This is the error message I get now.

The database failed to install. You may need to replace bbPress with a fresh copy and start again.

SQL ERROR!

>>> Database: lilienbr_wpmu (localhost)

>>>>>> CREATE TABLE IF NOT EXISTS bb_forums (

forum_id int(10) NOT NULL auto_increment,

forum_name varchar(150) NOT NULL default ”,

forum_slug varchar(255) NOT NULL default ”,

forum_desc text NOT NULL,

forum_parent int(10) NOT NULL default 0,

forum_order int(10) NOT NULL default 0,

topics bigint(20) NOT NULL default 0,

posts bigint(20) NOT NULL default 0,

PRIMARY KEY (forum_id),

KEY forum_slug (forum_slug)

) DEFAULT CHARACTER SET ‘utf8’ COLLATE ‘uft8_general_ci’;

>>>>>> Unknown collation: ‘uft8_general_ci’

SQL ERROR!

>>> Database: lilienbr_wpmu (localhost)

>>>>>> CREATE TABLE IF NOT EXISTS bb_meta (

meta_id bigint(20) NOT NULL auto_increment,

object_type varchar(16) NOT NULL default ‘bb_option’,

object_id bigint(20) NOT NULL default 0,

meta_key varchar(255) default NULL,

meta_value longtext,

PRIMARY KEY (meta_id),

KEY object_type__meta_key (object_type, meta_key),

KEY object_type__object_id__meta_key (object_type, object_id, meta_key)

) DEFAULT CHARACTER SET ‘utf8’ COLLATE ‘uft8_general_ci’;

>>>>>> Unknown collation: ‘uft8_general_ci’

SQL ERROR!

>>> Database: lilienbr_wpmu (localhost)

>>>>>> CREATE TABLE IF NOT EXISTS bb_posts (

post_id bigint(20) NOT NULL auto_increment,

forum_id int(10) NOT NULL default 1,

topic_id bigint(20) NOT NULL default 1,

poster_id int(10) NOT NULL default 0,

post_text text NOT NULL,

post_time datetime NOT NULL default ‘0000-00-00 00:00:00’,

poster_ip varchar(15) NOT NULL default ”,

post_status tinyint(1) NOT NULL default 0,

post_position bigint(20) NOT NULL default 0,

PRIMARY KEY (post_id),

KEY topic_time (topic_id, post_time),

KEY poster_time (poster_id, post_time),

KEY post_time (post_time),

FULLTEXT KEY post_text (post_text)

) TYPE = MYISAM DEFAULT CHARACTER SET ‘utf8’ COLLATE ‘uft8_general_ci’;

>>>>>> Unknown collation: ‘uft8_general_ci’

SQL ERROR!

>>> Database: lilienbr_wpmu (localhost)

>>>>>> CREATE TABLE IF NOT EXISTS bb_terms (

term_id bigint(20) NOT NULL auto_increment,

name varchar(55) NOT NULL default ”,

slug varchar(200) NOT NULL default ”,

term_group bigint(10) NOT NULL default 0,

PRIMARY KEY (term_id),

UNIQUE KEY slug (slug),

KEY name (name)

) DEFAULT CHARACTER SET ‘utf8’ COLLATE ‘uft8_general_ci’;

>>>>>> Unknown collation: ‘uft8_general_ci’

SQL ERROR!

>>> Database: lilienbr_wpmu (localhost)

>>>>>> CREATE TABLE IF NOT EXISTS bb_term_relationships (

object_id bigint(20) NOT NULL default 0,

term_taxonomy_id bigint(20) NOT NULL default 0,

user_id bigint(20) NOT NULL default 0,

term_order int(11) NOT NULL default 0,

PRIMARY KEY (object_id, term_taxonomy_id),

KEY term_taxonomy_id (term_taxonomy_id)

) DEFAULT CHARACTER SET ‘utf8’ COLLATE ‘uft8_general_ci’;

>>>>>> Unknown collation: ‘uft8_general_ci’

SQL ERROR!

>>> Database: lilienbr_wpmu (localhost)

>>>>>> CREATE TABLE IF NOT EXISTS bb_term_taxonomy (

term_taxonomy_id bigint(20) NOT NULL auto_increment,

term_id bigint(20) NOT NULL default 0,

taxonomy varchar(32) NOT NULL default ”,

description longtext NOT NULL,

parent bigint(20) NOT NULL default 0,

count bigint(20) NOT NULL default 0,

PRIMARY KEY (term_taxonomy_id),

UNIQUE KEY term_id_taxonomy (term_id, taxonomy),

KEY taxonomy (taxonomy)

) DEFAULT CHARACTER SET ‘utf8’ COLLATE ‘uft8_general_ci’;

>>>>>> Unknown collation: ‘uft8_general_ci’

SQL ERROR!

>>> Database: lilienbr_wpmu (localhost)

>>>>>> CREATE TABLE IF NOT EXISTS bb_topics (

topic_id bigint(20) NOT NULL auto_increment,

topic_title varchar(100) NOT NULL default ”,

topic_slug varchar(255) NOT NULL default ”,

topic_poster bigint(20) NOT NULL default 0,

topic_poster_name varchar(40) NOT NULL default ‘Anonymous’,

topic_last_poster bigint(20) NOT NULL default 0,

topic_last_poster_name varchar(40) NOT NULL default ”,

topic_start_time datetime NOT NULL default ‘0000-00-00 00:00:00’,

topic_time datetime NOT NULL default ‘0000-00-00 00:00:00’,

forum_id int(10) NOT NULL default 1,

topic_status tinyint(1) NOT NULL default 0,

topic_open tinyint(1) NOT NULL default 1,

topic_last_post_id bigint(20) NOT NULL default 1,

topic_sticky tinyint(1) NOT NULL default 0,

topic_posts bigint(20) NOT NULL default 0,

tag_count bigint(20) NOT NULL default 0,

PRIMARY KEY (topic_id),

KEY topic_slug (topic_slug),

KEY forum_time (forum_id, topic_time),

KEY user_start_time (topic_poster, topic_start_time),

KEY stickies (topic_status, topic_sticky, topic_time)

) DEFAULT CHARACTER SET ‘utf8’ COLLATE ‘uft8_general_ci’;

>>>>>> Unknown collation: ‘uft8_general_ci’

Database installation failed!!!

Is bbpress compatible with wordpress or am I wasting my time?