[_ck_]

Update: okay I have a work around.

Look for 0.0.3 within the hour.

[_ck_]

Okay I’ve figured out why it happens.

It’s a very serious flaw in how the new 1.0 db caching system works. Apparently they now suddenly base everything about the WHERE clause. If the clause is slightly different for any two queries, it doesn’t use the cache and instead does it a direct db query. It’s stupid.

There is absolutely no way I can fix it in the plugin, it has to be fixed inside bbPress 1.0 and I am not sure if or when they will bother.

[_ck_]

Well it works for me.

Show me your configuration inside hidden-forums.php and how many forums do you have?

Are those queries happening on the front-page, forum-page or topic-page?

[_ck_]

Hidden Forums has not been tested yet again 1.0 alpha.

I simply don’t have time to modify every plugin for all the changes.

This is why people should not use the alpha yet for regular sites.

Update: I’m unable to reproduce your problem however.

I have no extra queries with using Hidden Forums on the 1.0 trunk. Are you using the Alpha from the download on bbpress.org, or are you using the SVN trunk?

[_ck_]

Nice list but I’ve always found function lists fairly useless, though I guess if you have zero experience with how bbPress or WordPress works, they can give you a starting point with something to browse through.

What really helps is a trace of how functions flow when a page is loaded and what files they are located in.

I have an experimental version of bb-benchmark that does something like this using a trace feature from WordPress 2.6 but it’s not available for public use yet.

[_ck_]

No, you cannot use bbPress 0.9 with WordPress 2.6

[_ck_]

Show me your mysql configuration by doing this in your shell (ssh)

cat /etc/my.cnf

and copy what it returns to a post here or into pastebin.com

I suspect we can improve it. MySQL cache is very important to bbPress performance.

[_ck_]

You (and everyone) needs to make sure this is in your bb-config.php

$bb->load_options = true;

make sure you put it BEFORE /* Stop editing */

[_ck_]

Running bbPress on a server with 128mb of ram would be very difficult unless it’s a very light setup with low use.

256mb should be doable if that is real, permanent memory and not burst memory. It’s also important if you don’t have alot of overhead like cpanel running.

#1 problem on most small VPS is you either don’t have the mysql cache turned on or it’s too small of a cache

#2 problem is you almost certainly don’t have a PHP opcode cache like eAccelerator installed

#3 problem on almost all VPS is bad neighbors.

On a shared host, you can easily tell when you have bad neighbors who are overloading the server (node). On a VPS they are hidden. If you have an inexperienced host, they may have a hard time tracking down the offender, or may not even care. If they tell you that your neighbors can’t affect you, that’s an outright lie or plain ignorance.

If you are running bbPress 1.0 alpha it has several problems generating far too many mysql queries and that could be causing you some headaches. If you are using bbPress 0.9, definitely stick with that, but you need to fine tune your settings.

WordPress has some nice caching plugins like wp-super-cache. No such creature exists yet for bbPress, so all pages must be rendered each time by the engine, making it use more overhead than WordPress.

[_ck_]

This is why it’s called an alpha.

There are bugs, some serious.

So far I’ve seen a forum query bug and a tag query bug but not a topic query bug, so that’s a new one.

Make sure you update bb-topic-views which had a query bug too. In fact you should de-activate your plugins and see if the query problem persists before we blame it on bbPress.

[_ck_]

https://bbpress.org/plugins/topic/bb-benchmark/#post-1877

[_ck_]

I’ve now added auto-insert in 0.1.11

There is only one small bug in this method that I will have to address later. If you edit an existing post and upload a new image while ALSO changing the post text, it cannot save the post text AND upload the image (it will only upload the new image). This situation should be the least likely, though it could happen and I will have to deal with when I have more time.

All other auto-inserts should work correctly however, new posts and adding more images to a post.

[_ck_]

I guess I can add that feature as an option.

[_ck_]

It must be the overseas hop. Your connect time is blistering fast in Europe. But the download time not so much.

Vancouver (CA) Resolve time: 169 ms Connect time: 168 ms Download time: 1681 ms

Amsterdam (NL) Resolve time: 10 ms Connect time: 10 ms Download time: 1747 ms

Krakow (PL) Resolve time: 79 ms Connect time: 40 ms Download time: 699 ms

New York (US) Resolve time: 108 ms Connect time: 109 ms Download time: 1430 ms

Haifa (IL) Resolve time: 91 ms Connect time: 95 ms Download time: 1063 ms

London (GB) Resolve time: 11 ms Connect time: 17 ms Download time: 566 ms

Cologne (DE) Resolve time: 22 ms Connect time: 14 ms Download time: 1325 ms

Amsterdam (NL) Resolve time: 11 ms Connect time: 10 ms Download time: 634 ms

[_ck_]

The login form is so low because you specified position bottom -200px and that means for it’s parent element.

.login {

position: absolute;

bottom: -200px;

If you wanted it 200px from the bottom of the header, that means either the header is not being closed properly or the header needs a position:relative;

#header {position:relative;}

or you could just change it to position from the top:

.login {

position: absolute;

top: 20px;

I am also concerned that it takes nearly half a minute for a page to completely load on your site.

[_ck_]

You’ll know when your query count goes down. You may not even have the bug in your version of the alpha. I think it’s only present in the newest trunk versions. If your front-page query count increases for every new tag you have in the tag cloud, then you have the bug.

There is also a bug I just fixed in bb-topic-views 1.6.2 but I don’t think you use that plugin.

[_ck_]

There is no actual page cache in bbPress. The cache setting you see is meant for the *object* cache which is meant to store things like the user data and the forum data in shared memory (memcache) for multi-server environments. It could be used on a single server but the performance increase might be trivial compared to a good cache on the mysql db since the core “engine” still has to load.

The only real cache that could speed up bbPress is a page cache like wp-super-cache which bypasses the WP engine entirely. It would have to be ported eventually. But that only helps for users that are not logged in and the idea of a forum is for people to be logged in and interacting.

Currently I cache parts of pages like the front-page tag cloud on my own installs but I have not released the plugin for that.

Speaking of tags, while they may have fixed the forum query count in the trunk, I now see another problem where apparently bbPress 1.0 is making a query for EACH tag in the tag cloud. Once they fix that, queries should go down again.

[_ck_]

How many forums do you have total?

There is a big performance problem with 1.0 that I have pointed out to Sam and MDA which I hope they fix.

1.0, unlike bbPress 0.9, loads each forum separately and then each forum’s metadata separately. This creates a huge number of queries – each forum makes 2 queries, ie. a dozen forums makes the front page use at least 24+6 queries. bbPress 0.9 would only use a single query to load them all (this was before metadata was added to forums). When it is eventually optimized, no matter how many forums you have it will use only two queries instead.

[_ck_]

leoleoleo (and everyone) put this line into bb-config.php (before the “stop editing” part)

$bb->load_options = true;

That should slice at least 100ms off that time and reduce the queries by half. I still don’t understand why it’s not the bbPress default.

“Forum is category” is not needed under bbPress 1.0 which does category forums internally.

Also, the bb-gzip plugin is only necessary if your server does not already compress pages, which is rare these days, so make sure you are not duplicating the effort.

Some of my plugins are still not optimized for 1.0 so they might be slower or cause more queries than under 0.9

[_ck_]

This all comes down to the ldap so you are going to have to ask the author directly (apparently Sam who is very busy these days on bbPress 1.0 development) or hope that there are other ldap users who know. Personally I have to go lookup what the heck ldap is in the first place

I will suggest this much – if you are using 1.0 alpha, the plugin has probably broken compatibility with it and is only meant for 0.9

[_ck_]

bbPress is also very young so expectations should not be as high as WordPress (ie. robust plugin library). It’s about equal to WordPress back in 2003. While it benefits from code development on WordPress, it’s still 5 years younger.

But writing plugins for bbPress is as easy for WordPress (and in some cases easier because of improvements over WordPress’s legacy design). I’m definitely an example of this as I had never written a full PHP program or plugin of any kind before my bbPress plugins.

[_ck_]

Also if possible please include the version of PHP and your type of server environment (linux with apache or windows IIS). This is less critical than the bbPress version but helps with more obscure problems sometimes.

[_ck_]

You can get an idea of the timeline by following TRAC bug reports: https://trac.bbpress.org/query

I suspect there will be a beta in a month and maybe gold by November. It all depends how much time Sam and MDA can put into it.

Everyone can help the process by putting the alpha through it’s rounds and writing up quality bug reports in TRAC.

[_ck_]

Only admin can see the email addresses, to everyone else they are hidden.

Make yourself a secondary login as a regular member and you’ll see how it works.

[_ck_]

You’d need to add a filter, something like this (untested)

function edit_link_icon($r,$post_id) {return "<img src='/images/edit_link_icon.png'>".$r;}

add_filter('bb_get_post_edit_link', 'edit_link_icon',10,2);