What you are asking for is very easy.
$forums = get_forums(); gets you all the forums,
$topics = get_latest_topics( $forum_id); will get you the topics list for any forum id. So if you looped through the forums like on the front page, just fetch the $topics after each forum in the loop.
The formatting and page layout is the “hard” part.
I’ve never seen it done but the rules are fairly straightforward (just a bunch of them).
There must be a lighttpd support area where you can submit the existing rules and ask for help converting?
(then be sure to share the results back here 
The rules on this page for something called “serendipity” look very similar to bbPress’s rules:
http://edin.dk/archives/34-Serendipity-on-Lighty.html
so you might be able to use them to get an idea?
The word “swedish” is in there only because MySQL was originally a Swedish product and it’s legacy. Has nothing to do with any local language settings – just means it’s at the default.
Perhaps a database upgrade failed at some point and left it at a weird miss-match?
Anything that used admin_email with bbPress 0.8.x has to be changed to from_email under 0.9 (I am not sure why it was necessary to break all the plugins like that but what is done is done).
It should take a simple edit. I still get notification emails under 0.9. I believe I posted the fix on the plugin page.
That could be done via jquery but the ajax posting system in bbPress has been disabled/removed for awhile. Hopefully it will be back by the time 1.0 beta is released (later this year?)
My educated guess would be because it’s grabbing the link within the title, the plugin that alters the page count is not getting unhooked yet.
Try adding on a new line after global $topic;
remove_action( 'bb_get_option_page_topics', 'bb_custom_topic_limit', 200);
It’s occurred to me there might be a bug in my plugin where I don’t have that matching ,200 on the end of the same remove_action line. If I remember correctly, actions have to be unhooked with matching priority numbers to how they were added. So maybe try adding the ,200 also.
Remember that bbPress’s “topics per page” setting must be set to the actual number of posts you want listed on a topic page.
My educated guess would be because fel64’s plugin is grabbing the link within the title, so the plugin that alters the page count is not getting unhooked yet.
Try adding on a new line after global $topic; in fel64’s plugin:
remove_action( 'bb_get_option_page_topics', 'bb_custom_topic_limit', 200);
It’s occurred to me there might be a bug in my plugin where I don’t have that matching ,200 on the end of the same remove_action line. If I remember correctly, actions have to be unhooked with matching priority numbers to how they were added. So maybe try adding the ,200 also.
Remember that bbPress’s “topics per page” setting must be set to the actual number of posts you want listed on a topic page.
The newest 0.9 kakumei theme has a fix for post-author-info overflow that I think you are referring too. I posted an alternate hack around here somewhere…
Here you go:
https://bbpress.org/forums/topic/heres-a-trick-to-fix-kakumei-author-info-overflow
TARGET is deprecated?!
Throw off your shackles of validation, seriously.
I promise you that browsers 10+ years from now will still support TARGET. I’ll take html over likely-blocked javascript code anyday. At least firefox can intercept the TARGET and open it as a tab which is the user-prefered behavior.
Very nice layout!
Remember my theme switcher won’t work unless cookies are enabled. Many personal firewalls (and paranoid people like me) block them by default unfortunately.
If current time is 10 minutes off then the host you are on has it’s system clock set wrong. Contact them to see if that’s correct and if they can sync the host computer’s clock.
Wow you are right. Well that’s one for Trac to be certain!
Do you know how to file a bug in trac.bbpress.org or would you like me to do it?
I agree with not doing the actions in the templates – that was a mistake WordPress did for awhile eh? The hooks can go inside function edit_form in the core, no?
Just for clarification, because this one is important, do_action('post_edit_form') should go AFTER the </form> is closed.
do_action('pre_edit_form') should be before the <form
and do_action('edit_form') should be inside the form.
If all the post_form’s are actions, so should be the edit_forms. I don’t think any are filters, wouldn’t make sense…?
This will help other plugins like my Signatures too.
Less template edits needed, makes it easier for users.
Of course I still have to support some 0.8.3 people so it’s going to be awhile before this solves all problems but at least newer installs can benefit.
I’ve now implemented flexible restrictions in 0.0.6 based on file type or role based on your suggestion HowToGeek.
HowToGeek, that’s easily doable, just more settings to fill out
That reminds me that I’ll have to give a list of accepted file types and sizes above or below the upload form.
The ticket was months back, I’d have to search.
It’s fairly simple in theory though, why not mimic the existing hook structure for new posts to match editing existing posts:
pre_post_form -> pre_edit_form
post_form -> edit_form
post_post_form -> post_edit_form
This issue in my plugin has now been fixed, be sure to upgrade to 0.0.2
Sorry for the problem, it was because the main email address changed in 0.9 to “from_email” instead of “admin_email” and I was not aware of the change.
fel64: No, there’s been hooks for the post form for as long as I can remember.
Unfortunately that’s only for new posts. For editing existing posts there is absolutely no way to affect the template without editing it. There’s no hooks for edit_form() or any of it’s sub-functions or the template loader (the loader does the include AFTER the hook so nothing can be placed afterwards. I requested some hooks many month ago but they may have been missed (or ignored). This plugin will require (one, simple) edit of the edit-post.php template.
(In theory it could be done via the bb_get_footer but that’s really messy and the footer hook is AFTER the footer has been rendered).
Yes there used to be a limit with readfile/passthru but supposedly fixed in newer PHP and even the old limit was 2mb which is fairly high anyway. Also there is some debate that flushing output and making sure compression/output buffers are turned off avoids the limit. We’ll find out as more people test it.
I’ll have a version up for testing in 12 hours or so.
Progress is excellent, way ahead of schedule, should have a public demo Saturday night (24 hours or so).
Working on a auto-thumbnail method now for image uploads.
I’ve come up with some extra security features like the files are not directly publicly accessible (stored in non-webroot directory) so they never get fed through the parsers and cannot be executed (ie. .php .html .asp) even if someone manages to trick a file extension or mime somehow. The only downside to this is that the files must be “dumped” through PHP (readfile) which will keep the PHP session open longer but unless you are serving multi-megabyte files at high traffic rates, this should not be a big issue (optionally you can make the files directly accessible off the web if this is critical issue).
As a bonus the above method makes hotlinking impossible as you can set attachments as accessible to logged-in members only.
