[michael3185]

Holy cow. You know what I said about plugin programmers maybe not knowing what they’re doing..? Re-reading, I do wonder…

If all this inefficiency is real, then who’s writing the core code, and are they truly competent..? I would hope that those who construct a system like bbPress have some professional training behind them. If not, then perhaps we’re back into school kid land…

[adman22]

I have tried several times now, all with the same results of the setup going wrong. I keep getting this error message when trying setup things up even once step 1 is completed: Warning: cannot yet handle MBCS in html_entity_decode()! in /forums/bb-includes/wp-functions.php on line 113 Might anyone know whats going wrong, I have downloaded the most recently files? Thanks.

[Tynan Beatty]

I just upgraded a public site from the latest WP2.7.x to the latest WP2.8-beta2 and decided to upgrade the site’s bbP1.0alpha6 and the bbP Integration plugin that was made for that version (all working as expected).

I was having similar problems with wp2.8-beta2-11509 and bbp1.0-rc-1, using the bbPress Integration 1.0-rc-2 plugin. I found that adding it’s suggested changes to my wp-config.php was causing the problems. I also removed the integration speedups suggested from the bbP admin ‘WordPress Integration’ settings. Now I haven’t tested registration from the bbPress end, but everything else seems to work back and forth. Here’s what I have near the bottom of wp-config.php with everything working:

define('WPLANG', '');

define('COOKIEPATH', '/');



/* That's all, stop editing! Happy blogging. */

Where the '/' might be a '/subfolder/'

And here is the bottom of bb-config.php:

define('BB_LANG', '');

?>

The only thing I’ve found not working thus far is users logging in from the bbP side cannot log out from the WP side. Everything else seems integrated for logins/logouts (login/out from WP, login from WP/out from bbP, login/out from bbP).

This is a minor issue compared to not being able to login to WP at all when using the suggested bbP integration changes to wp-config. I also have all 4 random keys matching between configs, including the nonces (which I don’t think were mentioned in the integration video post, but I don’t remember now). I hope there’s a fix for the login from bbP/logout from WP in the next release of the Integration Plugin, and I also hope that the issue doesn’t affect registration from bbP (since it seems to be related to the plugin). Great work on this so far Sam

On a side note, further testing suggested that it was the ‘SITECOOKIEPATH’ definition causing the inability to login from WP, and the ‘COOKIEHASH’ definition seems to allow WP login, but break the integration.

peace~

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

[Arturo]

if you use poedit it generate automatically .mo when you save the .po

i use it to translate bbpress, wpmu and buddypress

[Fabrizio Pivari]

> Just ask the original poster to create a new post then delete the original.

Is there a possibility to add in a new release similar feature?

Fabrizio

[michael3185]

Yep, the idea of a minimal core engine with stable plugin hooks sounds the best way to me too, even as a non-developer.

Something I’m sure would help is a standard for plugins. I think too many people are put off when the core doesn’t have a function they want, but yippee; there’s a plugin! Then after many hours of frustration, ah crap; this fails too, and here we go with the forum questions again. It also makes the product look bad, even though the plugin developer may not be related to that product in any way.

A ‘bbPress Certified’ system would give users more confidence, and raise the bar for forum development as the outside world perceives it. I can see that plugin developers work hard to get things right for others, and every eventuality can’t be tested for of course. However, I also know from struggling very hard with different forum packages over the last 6 weeks that there really are no standards, and on a couple of systems people seem to have jumped on the plugin bandwagon because it’s fun and brings kudos. In one case, I found myself delving into posts from as far back as 2005 in an attempt to get something simple working. They have a massive forum, but it’s jam packed with ‘How can I make this work?!’ posts going back years. (bbPress is a gem by comparison, which is why I’m still here).

Non-programmers see a plugin on a ‘legitimate’ forum and naturally assume it’s going to work properly. Not everyone’s into hacking around, and some have no time or inclination to do so whatsoever, especially working people who want Open Source software but need it to just work out of the box. On the other side of a crucial plugin may sit a very competent programmer with great ideas, but it can just as easily be a school kid who’s learned a bit of php and doesn’t have the experience to make their ideas actually work. There’s no way of knowing, unless they post in an obviously off-putting way. The current user rating system looks good, but is quickly dismissed when two or three 5 star plugins fail.

Any standard takes time and effort in the background to assess the code others produce, though it sounds like that’s already being done anyway. I submitted a very simple plugin and wondered why it hadn’t appeared on the forum, and another member mentioned that it can take a while for it to be reviewed. If some checks were done for code readability, apparent competence, etc., as well as the checks already being done for maliciousness and obvious bugs, then you’ve got a working standard. If someone submits something your programmers can see is messily written, uses innapropriate function calls, etc., then they get a ‘Sorry, it doesn’t reach our standards’ email. Maybe a Certified bbPress Star System; 1 star – not rated; 2 stars – appears competent, or is excellent but has no admin panel; 3 stars excellent structure and use of core functions, and has admin panel, and so-on. No guarantees, but at least we’d know to go for 3 stars or more, or if you love to play, grab the 1 star and have fun improving it. Kudos for both developers! The user ratings could be left in as an extra, though casual, system.

It doesn’t really have to be any more labour intensive than at present, and if bbPress and associated systems want to be taken even more seriously in the working world, then standards for plugin development are essential.

[itissue]

I tested it out and it sort of works but when I miss just a few characters in the captcha, I still pass the test. It’s only when the thing I type is way off that it works. That’s probably how reCaptcha has it set up though. I guess it should be fine since bots shouldn’t be able to read images. We’ll see. Thanks for taking the time to code it into a plugin though dchest. It’s just what I’ve been looking for.

It does clash with bbPM though. I’m not sure what it is that’s doing it, but I can’t use both this and bbPM together.

[Sam Bauers]

The additional queries are probably due to the new taxonomy structure we are using for tags.

On the upside, you can now use memcached to cache bbPress objects which should give you better performance than 0.9

I’d be interested to know if the query count was also higher on other pages.

There is a small amount of code “bloat” because of BackPress abstraction layers, but it’s here to stay. It’s already being utilised in a couple of other projects including GlotPress and there are a few people interested in merging it into WordPress as well. The benefits of using it to the ongoing development of bbPress is becoming clearer all the time.

As for feature creep, it’s going to be really limited. bbPress is just supposed to do a few things simply and provide enough hooks for plugin and theme devs to add the bells and whistles. That won’t be changing any time soon. Most development over the next few iterations will be concentrating heavily on easing integration with WordPress and making the lives of plugin and theme devs easier.

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

[citizenkeith]

Thanks… the new plug-in did the trick. Still don’t understand what happened, but at least the front page isn’t as cluttered.

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