[_ck_]

There’s no official documentation or codex yet.

A few people have done phpxref for bbpress but I find that kind of output fairly useless.

If you have access to linux shell you can do a grep to get a function list in the template include like so (or install the grep for windows)

grep -oe ^function.*) bb-includes/template-functions.php | sort > functions.txt

modifying that you can also get the filters/actions

grep -oe apply_.*) bb-includes/template-functions.php | sort > filters.txt

grep -oe do_.*) bb-includes/template-functions.php | sort > actions.txt

If you use the grep for windows, leave out the escapes (backslashes) or it won’t work.

[_ck_]

Allowing iframes is a massive security issue.

Whatever you are trying to do, you need to find another way.

The code button is the same as backticks, it’s for placing encoded text, not actual code to execute.

[_ck_]

Do not use the Private Forums plugin, it has not been updated in awhile and has bugs.

Use my Hidden Forums plugin instead. The code above is not sufficient in itself.

[_ck_]

No one else can answer what is best for you.

It takes ten to twenty minutes tops to install bbPress.

Install both, play with both for a weekend, delete the one you don’t want.

Here is someone who tried six different forums and went with bbPress:

http://www.beholdgenealogy.com/blog/?p=591

http://themehybrid.com/support/topic/best-wordpress-forum

Which is better bbpress or wp-forum plugin ?

https://bbpress.org/forums/topic/bbpress-10-alpha#post-18532

[_ck_]

This seems a great time to mention a new hidden feature in bbPress 1.0 based on a suggestion I made: “Safe Mode”

When you don’t know why something isn’t working, one quick and easy way to prove if it’s a plugin gone wrong or not is to temporarily try “Safe Mode”

The way to activate safe mode is to edit bb-config.php and insert

$bb->safemode = true;

Then your forum will temporarily switch to the default theme (which you should never have tampered with) and disable all plugins, temporarily.

When you are done testing, remove the line from bb-config.php

This is far easier than deactivating 20+ plugins, one at a time and then having to activate them again.

[_ck_]

We could make another query to delete usermeta where the id doesn’t appear in wp_users.

I’m not crazy about deleting rows entirely but I guess it could not hurt if the user id # never gets reused, which mysql should not do.

Definitely do a backup first.

This will show all “orphaned” usermeta:

SELECT user_id,meta_key, umeta_id FROM wp_usermeta

LEFT JOIN wp_users ON user_id=ID

WHERE ID is NULL

so delete the wp_users rows first using the first query and then delete the orphaned usermeta

[_ck_]

Thanks for the fix Sam.

What’s really scary is the code it replaced.

I can’t believe what I was seeing – did they really build the $table on EACH and EVERY call instead of making it static? That’s some serious non-performance thinking.

I mean just look at it, ugh:

function htmlspecialchars_decode( $str, $quote_style = ENT_COMPAT ) {

$table = array_flip( get_html_translation_table( HTML_SPECIALCHARS, $quote_style ) );

$table = array_merge( array( ''' => "'" ), $table, array( '&' => "&", '&' => "&" ) );

return strtr( $str, $table );

on EVERY call it builds $table?

Well it’s gone now so I guess that’s what counts.

I hope the error catching routine doesn’t slow things down too much.

Personally I am waiting for PHP 5.3 to finally “upgrade” from PHP 4

It won’t be worth it until then.

[_ck_]

Okay instead of commenting it out, do this instead

error_reporting(0);

[_ck_]

Confirmed working in 0.9.0.4 with apparent speed boost.

Those using my mini-plugin, you MUST delete it when using 0.9.0.4 or 1.0-alpha-5 or you’ll find that all topics disappear.

[_ck_]

No you miss the point that both are put into the template so the ajax can hide or unhide the link as necessary depending on the post status.

But older themes without the two classes above will never hide the alternate link by default. So they both show.

There will be hundreds of questions about this now.

Put these two classes into your style.css

#thread li .undelete-post, #thread li.deleted .delete-post { display: none; }

#thread li.deleted .undelete-post { display: inline; }

and it should fix.

[_ck_]

This will show in you in PHPMYADMIN all users older than at least a month who have never posted:

SELECT ID,user_login,user_registered FROM wp_users

LEFT JOIN bb_posts ON ID=poster_id

WHERE user_registered<DATE_SUB(CURDATE(),INTERVAL 30 DAY)

AND poster_id is NULL

[_ck_]

To remove the warnings when using PHP 4, until Sam fixes it, go into bb-settings.php and change the error_reporting line (line 51 in 0.9.0.4 and line 29 in 1.0a5)

old:

// Modify error reporting levels

error_reporting(E_ALL ^ E_NOTICE);

new:

error_reporting(0);

[_ck_]

Might be a trunk bug but strange how it works in the default.

They changed how the links work to bb_post_admin so it’s all internal now.

If there is a bug, it would be in

function bb_get_post_delete_link( $post_id = 0 ) {

Unless maybe in your template you have both

bb_get_post_delete_link() and bb_post_admin()

which should not be.

Wait, I take that all back

something crazy is going on with line 1599,

you now MUST have in your theme both classes to hide the inactive link.

So they essentially broke every theme in existance with the new trunk. Nice.

$r = "<a href='$delete_uri' class='$ajax_delete_class delete-post'>" . __( 'Delete' ) . "</a> <a href='$undelete_uri' class='$ajax_undelete_class undelete-post'>" . __( 'Undelete' ). '</a>';

Go into your stylesheet and copy from the default kakumei stylesheet the styles for

#thread li .undelete-post, #thread li.deleted .delete-post { display: none; }

#thread li.deleted .undelete-post { display: inline; }

Are they calling everything threads instead of topics now? Ugh. More confusion.

[_ck_]

Are the links for delete/undelete actually valid? What post do they link to?

Sounds like the function doesn’t actually see the current post in your template.

[_ck_]

There’s no official documentation or codex yet.

A few people have done phpxref for bbpress but I find that kind of output fairly useless.

If you have access to linux shell you can do a grep to get a function list in the template include like so (or install the grep for windows)

grep -oe ^function.*) bb-includes/template-functions.php | sort > functions.txt

modifying that you can also get the filters/actions

grep -oe apply_.*) bb-includes/template-functions.php | sort > filters.txt

grep -oe do_.*) bb-includes/template-functions.php | sort > actions.txt

If you use the grep for windows, leave out the escapes (backslashes) or it won’t work.

[_ck_]

>> The same performance gain is achieved using the existing forum_time index.

Ah so in that case, no ALTER required and there is zero extra storage required and the plugin can be used like this:

<?php

/*

Plugin Name: Topic Time Index

*/

add_filter('get_latest_topics_join','topic_time_index',99999);

function topic_time_index($join) {return " $join USE INDEX(forum_time) ";}

?>

[_ck_]

Chris, you are missing the concept that if there are 100 people hitting the mysql server with the same or different queries and they can’t be cached, the load goes up exponentially.

Sam’s benchmark is on a high performance, dedicated mysql server.

Imagine someone with 40,000 records, non-indexed, on a shared server.

[_ck_]

Very nice. So it’s definitely proven to be way faster.

But another question is, how much space does a non-unique index on 42,000 rows take?

[_ck_]

I bet it only doubles the performance when it can sort in memory. Once it spills into a temporary disk sort, then you start seeing a more radical increase in performance between the forced index and not.

I should also point out the mini-plugin (and index) will also help on any forum/sub-forum page in addition to the front-page. So all that extra index storage is at least multi-purpose.

One way to boost this even further would be to ORDER BY the topic_last_post_id and then use the last_post_id as a UNIQUE index (key) since no two posts can have the same post_id (and no two topics can have the same last post_id). topic_time is not unique at all so it takes a tad longer for mysql to sort/larger index.

[_ck_]

Wow that is very significant, thanks for sharing that!

[_ck_]

One possible way to benchmark the performance is to run these two queries in phpmyadmin (via SQL tab)

SELECT SQL_NO_CACHE t.* FROM bb_topics AS t   USE INDEX(topic_time)  WHERE t.topic_status = '0' AND t.topic_sticky != '2'   ORDER BY t.topic_time DESC LIMIT 25

vs.

SELECT SQL_NO_CACHE t.* FROM bb_topics AS t  WHERE t.topic_status = '0' AND t.topic_sticky != '2'   ORDER BY t.topic_time DESC LIMIT 25

On my setup the one with the forced index takes half the time of the one without, however we are talking 0.0026 sec vs 0.0013 sec so that is almost meaningless. What we need is someone with 10,000 topics and then you’ll know for certain.

[_ck_]

Should work on both 0.9 and trunk.

Seems fine on my 0.9 and trunk.

Unfortunately I have too few topics to benchmark any significant performance increase since this is only helpful to more active forums (ie. > 1000 topics)

[_ck_]

Not extensively tested but this will do it without a core hack

(once ALTER TABLE bb_topics ADD INDEX (topic_time) is done)

<?php

/*

Plugin Name: Topic Time Index

*/

add_filter('get_latest_topics_join','topic_time_index',99999);

function topic_time_index($join) {return " $join USE INDEX(topic_time) ";}

?>

[_ck_]

This is the SQL query to use if others want to add such an index:

ALTER TABLE bb_topics ADD INDEX (topic_time)

But that in itself is not enough, bbPress has to be forced to use the index.

I am trying to figure out a way to do this without hacking the core, via a mini-plugin instead.

[_ck_]

That’s funny I was just about to make a TRAC ticket pointing out there is no index on topic_time for the latest view.

Strange you have to force the index though, what is the default ORDER BY, let me go look…

yup, they order by topic_time, with no index, that’s just crazy, even for just 1000 topics, because it would have to do a full column scan. Ordering by topic_last_post_id would be even faster with an index too though I guess in a very strange circumstance the last post might not be the last time.

Still, you should not have to force the index.

Oh wait, I see why – it’s because mysql decides to use the stickies key instead, ugh.

Yeah I can see why that would bring a large forum to a crawl.

I think whomever designed the bbPress database tables had a misunderstanding how mysql indexes work because they are using multiple field indexes that are not the primary key. Or a key at all. Which is useless because mysql will only use one index per query regardless of it’s complexity (or lack of). An index on multiple fields is useless unless it’s used as a key. MySQL 5 can use different indexes for the query vs ORDER BY or GROUP BY but bbPress doesn’t take advantage of that at all.