Understood, and thanks for the warning. Perhaps we can use this thread to identify which ones break.
Anyone else? I just wanted to check before I filed a bug.
Turns out the Manage -> Recount didn’t solve the issue.
I did a clean install of BBpress integrated with WordPress and reproduced the problem. I failed to reproduce the problem the first time since I only had two users.
Try this on a clean install-
0. Use keymaster account to write a two posts under two topics.
1. Create user #2.
2. Login user #1 and create two posts under same two topics written by user #1.
3. Using wordpress admin delete user #2.
4. Create user #3 and log in as user #3.
5. Display topics.
6. Note that the keymaster account is ‘inactive’. This is a result of the SQL request for the account level failing.
I never found the source of the problem, but was able to find a solution.
I used the Manage -> Recount function in the BBPress interface and recalculated all parameters. After doing this, things appeared to work.
Perhaps this function should be called whenever there is a database upgrade.
Additional info:
Following the error, the page displays fine with the exception of user roles and the link to the user profile. All are listed as invalid, with the exception of the user that is logged in.
The malformed SQL request is listing the user ID’s in the thread. The ID’s are in order of post appearance. Once an anonymous post is in the sequence it fails to insert the userID.
Another example is below:
SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE user_id IN (17,23,1,18,) /* WP_Users::append_meta */
The fifth post in the topic is an anonymous poster with no corresponding wp_user or wp_usermeta information but it appears a null is inserted in the request rather than the legacy user ID.
If I look into the database and examine topics and posts made by anonymous users the legacy user ID’s are there. bb_posts has the old user IDs for the posts made by deleted users . Somehow, this data isn’t making it into the request.
Just did a clean install of 1.0r6 w/ the same WP2.7 user tables and saw no problem.
There must be some issue as a result of the upgrade from 0.83
Very nice theme. A great candidate for an accompanying WordPress theme too.
Phplist is pretty good and a plugin could be written.
There is also a plugin that does this.
I can’t find the plugin link, it was one of fel64’s specials and it isn’t in the repository. It was called ‘page’ and added a > at the end of each topic title.
Can I upgrade from 0.8 series of BBPress to 1.0? I did some sandbox upgrading and ran into some issues.
Specifically an upgrade from 0.8 series to 0.9 required additional uri path variables in bb-config.
https://bbpress.org/forums/topic/unable-to-upgrade-081-to-0902#post-16890
But even after uncovering that special little surprise I am still having issues.
Before I debug further to find outstanding problems, other than the path variables that needs to be inserted in bb-config prior to running the database upgrade- can I go from the .8 series directly to 1.0 alpha or do I first need to upgrade to 0.9, then upgrade THAT to 1.0.
Thanks. I do need integration.
I may set up a dev.domain.com area and get things up and running first. I have never done this but it would seem to be the safest path.
I can’t seem to get this to use the time offset in config.php. It displays the post time in GMT, all the time. I have this in my config.php.
$bb->gmt_offset = -5;
Changing the value has no effect on the displayed time.
I’ve also pulled this off. It’s fantastic.
After much hacking about I figured out the problem.
This post offered a clue:
https://bbpress.org/forums/topic/getting-bbpress-and-wordpress-to-talk-to-each-other?replies=6#post-6068
It turns out that any global variables declared or set in header.php must also be set in the calling page. I added the following to the top of front_page.php and now the variables are properly set after calling bb_head().
<?php global $research_subscriber; // ‘1’ if user is research subscriber
global $forums_subscriber; // ‘1’ if user is forums subscriber
?>
The global variables don’t need to be set in the calling page in wordpress (single.php, search.php). I have no idea why bbpress handles this differently – must be in the way the header is called.
Much frustration. I hope someone finds this post useful.
Note I mistyped above – the variables in the if statement match the global declaration. I just neglected to edit out the ‘nyquist’ from the if statement in the name of a little privacy.
Never mind, I think I just figured it out.
<?php echo $_SERVER['REQUEST_URI']; ?>
I can live without integration but it would be nice to have shared header and sidebar code. I just wanted to log my observation in case someone else had the same problem.
I imagine with all the new focus on forum software these issues will eventually get mowed down.
I have reverted to straight BBpress. Topic page loads went from 4-6s back to 200ms. The js components, for reasons I do not understand, load much more slowly with a full wp include.
I just completed a WP/BB integration and have noticed a speed decrease.
According to Firebug, most of the delay is in the downloading of the .js ajax components.
The other thing I noticed is gmt_offset no longer seems to work- the time displayed is always GMT.
I found a better solution. I kept rss.php in the core and edited the rss2.php file in my theme to display titles, authors, time, etc but not post content. This was the perfect solution for me.
So many unarchived plugins that are so nice…
I deleted rss.php (just as I did register.php) from the core. I suppose deleting core files isn’t as bad as editing them, though I don’t like the solution. I also am in the process of editing the theme.
