This PHP redirect worked beautifully for my exact same situation, thanks.
You don’t need a plugin at all, since these are not posts with the links: they’re sponsored images in your template.
You need to find this:
target="_blank"
And replace it with this:
onclick="window.open(this.href); return false;"
in whatever file you added the target=”_blank” to. Sounds like it’s in your sidebar. You will need to manually edit that file. If it’s not a static file and is being generated by WordPress or something, then you would need a WordPress plugin to add the links with the javascript onclick instead of deprecated target=”_blank”.
@Gautam: yeah sorry, I suggested that because I’m testing with no users db sharing, so I’ve to use bb_is_user_logged_in() instead of WP’s function.
You can use is_user_logged_in() WordPress function for that, like:
<?php
if ( is_user_logged_in() ) {
// Logged in HTML here
} else {
// Login form HTML here
}
?>
The solution suggested by Pelle would work, but would add a lot of load on your blog.
Before calling the bbPress function just add:
<?php require_once ABSPATH .'/forum/bb-load.php'; ?>
I had the same problem. After I had transfered all my bbPress users over to wp_users, I just logged back into the bbPress adminpanel, went to WordPress integration settings and just clicked saved again.
Then all the user roles was correct and updated when I refreshed the WordPress adminpanel.
I am using bbPress 1.0.2 and WordPress 2.9.2.
I originally did hardcode the menu items however the dropdown menu did not seem to work when hardcoded so I went back to including the header.
I will give hardcoding another try.
Thanks,
David
would be far better to start a new thread.
im wondering how to recover the admin password, i lost it and im stuck,
thanks guys, sorry for the off topic post, seems like you guys know how to get around bbpress
What version of bbPress are you using ?
What version of WordPress are you using?
Are you using “deep integration”?
That said, I’d hardcode them if I were you. Given that you know you’re going to be on your forum page, and therefore dont need to having anything dynamic or highlighted, you can just hardcode it to work.
Not an ideal solution, but its one that you can control completely 
Good Luck
Not going to happen for WordPress 3.0. I wouldn’t plan on it any time soon.
I want BBPress to be a standalone program. But I want it to be possible to include it as a page in WordPress.
I would love to see bbPress as a WordPress plugin.
You are totally incorrect.
There is nothing in the GPL license which prohibits you from selling GPL licensed themes.
WordPress.org even has a page dedicated to promoting the sale of various GPL themes … https://wordpress.org/extend/themes/commercial/
The error
Warning: require_once(includes/admin.php) [function.require-once]: failed to open stream: Not a directory in /homepages/0/d188981313/htdocs/.org/wordpress/forum/my-plugins/after-the-deadline/after-the-deadline.php on line 68
Fatal error: require_once() [function.require]: Failed opening required 'includes/admin.php' (include_path='.:/usr/lib/php5') in /homepages/0/d188981313/htdocs/.org/wordpress/forum/my-plugins/after-the-deadline/after-the-deadline.php on line 68
I know I don’t have an “includes” folder
/**
* Require Admin/Public/AJAX File
*/
if ( defined( 'DOING_AJAX' ) && DOING_AJAX == true && in_array( 'ignorealways', (array) $atd_plugopts['enableuser'] ) ) /* Load Ignore Phrase file as we are doing AJAX */
require_once( 'includes/ajax-ignore.php' );
elseif ( bb_is_admin() ) /* Load admin.php file if it is the admin area */
require_once( 'includes/admin.php' );
else /* Else load public.php file as it is the public area */
require_once( 'includes/public.php' );
I think in the long run, that rather than porting bbPress to a WordPress plugin as a “straight port”, there will be a halfway house of using WP3.0’s custom post types and taxonomies. I’m guessing at this, but haven seen some attempts at this on the beta already, it seems to make alot of sense.
EDIT: found justin tadock’s example @ http://justintadlock.com/blog/wp-content/uploads/2010/04/forum-post-type.png
(sorry for the number of spelling mistakes, i simply can’t read these hideously small text they’ve forced on us by using font-size in pxels)
Your code is very decent so keep writing 
You have the status right.
WordPress finally has an admin menu generator? Good to hear.
Sadly I’ve lost touch with the WP codebase since 2.5 or so, I was getting really turned off by the bloat.
The problem is every website has different needs.
Some have only 10 visitors a day but the site operator wants every feature including the kitchen sink. They don’t care if it takes several seconds for their page to render as long a they have every fancy feature available and they can just use wp-super-cache to deal with the load.
But other sites have thousands of visitors a day and when a page takes too much cpu time or mysql time to render, then you multiply that by hundreds of simultaneous connections. Then you fail and your host kicks you off or you have to buy a bigger server.
WordPress started lean and mean, 1.5 was good, 2.0-2.1 was a great product. Then they started throwing in the kitchen sink. Then with every next release started breaking compatibility with every release, changing cookies, changing admin structure. 3.0 is a scary creature indeed.
There is no doubt in my mind that a bbPress plugin under WordPress is going to require 1 megabyte of code executing per instance with plugins in a realistic environment. The site operator with 10 visitors per day won’t care because they have every feature the could want in one package. The operator with an active, growing user based is going to have to constantly upgrade their server to handle the problem.
Active forums don’t deal well with caching, unlike blogs.
Blogs are write once, read many times.
Forums are write many times, read many times.
Different environment, different needs.
But performance should always be designed into software.
[edit: thanks for the feedback
]
Yeah, the option settings is a pain, they finally added that into WordPress, so I’m hoping it’ll be added into bbPress as well at some point. I copied the form from akismet, thought that way I’d get it right first time 
And yes I did use that, nice starting point – hadn’t realised what was being passed to the trusted (must have missed that part). So yeah that’s trivial enough to add in.
One reason I didn’t add in the trusted was that I totally missed it after intending to put it in! This was due to my not being able to add a user profile field in the form of a select. So I’ll re visit that and see if I can utilise radio buttons instead.
Wasn’t sure what post_status were… so is it:
0 for standard posts, 1 for deleted and 2 for spam ?
I’ll work on it …
I’ve released a few WordPress plugins (and have loads of small unreleased ones), I’m not saying I’m good, but have experience. Plus it is why I have moved back to bbPress after years of using other forums, I should be able to code plugins for it!
Looking back at WordPress it look like it may not have been added into bbPress as yet. Ahh well one page for one setting is bit OTT but looks like I’ll have to stay with that for now.
paulhawke, there is nothing “clean” about wordpress design. The code may have been cleaned up over time, but the result after 5+ years is there is a ton of code.
But the critical part is it loads EVERYTHING, regardless of the task at hand, all functions, all options, all plugins. Only the admin area is excluded from the load. But even the admin functions in plugins are loaded because there is no api structure to load those portions only in admin. (I’ve attempted to address that last problem in some of my later plugins for bbPress).
Loading a bbPress page as a plugin for WordPress will require the same process, EVERYTHING has to load, but now it will be worse.
This is why caching is critical with WordPress or it gets slaughtered when there are many requests. As soon as bbPress 1.0 was retooled to use backpress, it inherited the same problems as WordPress.
bbPress as a plugin will have the same problems as with backpress, but now even more so as all the wordpress plugins are loaded. It’s deep integration regardless if the user wants it or not. You will not be able to use bbPress functions without all of WordPress loaded because it will be substituting for backpress.
It’s forced deep integration, easiest way to explain it, and that’s a very bad idea.
I’m running into an issue writing the “import” side of things – my first thought is to create a plugin that mimics what is in WordPress. I found myself creating the infrastructure that is already present in the main body of WP.
Writing both import and export tool really would be a lot simpler when bbPress is a WordPress plugin. Why make it like the WP one, when we can utilize the real one?
Coming at this as a software engineering problem I cant see why a both/and rather than either/or situation shouldn’t prevail. Let me explain, as it’s not particularly outside the box for it to happen.
I write a lot of automated tests for the code I produce day-to-day and that means I need to isolate the most important pieces of business logic from how they are invoked. For instance, a given request comes into the a webservice telling it to create a user for the system. I would separate the code that handles the webservice part (pulling parameter data from the incoming HTTP request, etc) from the code that then creates the user. I would isolate the steps, wrap automated unit tests around each, and be done.
Applying the same thing to bbPress, there is some core code that handles the management of forums containing topics, that contain posts by users. This code is packaged into a clean unit of deployment – the WordPress plugin – and there is absolutely no reason why the code shouldn’t also have a second wrapper that allows for its deployment stand-alone from the main body of a WordPress installation.
Just as I might have a webservice making calls to a body of well-tested code in my day-job, I dont see why a cleanly written WordPress plugin shouldn’t make calls into the tested bbPress core code. The body of WordPress code provides additional services that another wrapper could also provide – the core of bbPress should be unaware of the actual physical storage mechanisms being employed, or how it’s being invoked (assuming its written correctly).
At the end of the day the conversion to a WordPress plugin should bring health to the codebase – a level of focus on what is most important (managing structured conversations in a forum/topic format), and an abstraction from what is not important (that is, the underlying physical storage, web-hosting, etc).
I tried renaming the user to lowercase but no luck. These users were imported into wordpress from another system. So they are just in wp_users. So I figured I had to ad into wp_signups but that didnt work.