@danblumenfeld, seems like that would work fine for small sites with a limited number of users and topics, but what about when you get into the thousands of users with thousands of topics? At that point you are saving an extremely long meta key for every user. I would worry about scalability, although I think that’s true of any attempt at solving this problem.
As for pagination with jumping to the first unread reply, it might be more practical to simply give the user a “jump to last read reply” button using bbp_get_reply_permalink( $reply_id );
There’s a fairly substantial difference between “topics with no replies” and “topics with new (read UNREAD) replies” 
Not to detract from the cleverness of your solution, but my point was that it can approximate “read topics” using browser side CSS, but it can’t generate a list of unread topics using PHP.
I agree this is a reasonably clever approximation for displaying which threads have been viewed by the user however there is one primary feature that most forum-goers look for in a “unread posts” feature that this does not successfully proxy for, which is the ability to query a list of topics which are unread and/or have unread replies.
I played around with an alternative approximation of this feature by generating a list of topics with replies more recent than the user’s last recorded activity (from BuddyPress), but this also only simulates the functionality that posters are used to from a VBulletin style message board.
I’m still curious if anyone has an opinion on this issue. Is there a performance gain to be had from closing threads once they reach a certain number of replies and reopening fresh versions?
Thanks for pointing that out @netweb. I’m interested to see what comes of that discussion.
@JohnJamesJacoby, Thanks very much for confirming this! I found the ticket you created with a solution: http://bbpress.trac.wordpress.org/changeset/4657
I’ll probably go ahead and push this through later today, great work and Merry Christmas!
Went through the whole disable all plugins, revert to default theme thing…no luck. Really could use a confirmation from someone else running WP 3.5 and BBP 2.2.3 that reply revision logging is working for them?
I’ve tried a few other odds and ends to sort this out, but it seems like the problem is simply that reply edits aren’t saving revisions to the posts DB. I don’t use any plugins that could be causing this disconnect. Is it possible this is simply something that is happening within bbPress core? Probably not, because I didn’t see any other reports of this issue, but maybe nobody has noticed?
Can someone else using WP 3.5 and BBP 2.2.3 confirm that reply revision logging is working on their install?
OK, doesn’t seem to be a permissions issue. I can’t get reply revisions to save to POSTS even as the administrator/bbp_keymaster.
Also disabled + re-enabled “Allow topic and reply revision logging” to try to “reset” the revision system, but no luck.
I would like to weigh in here and agree with @xmasons sentiment. The “Members” plugin, for example, is a great example of role/capability management done right IMHO. I am unable, however, to modify the capabilities of the bundled bbp roles within the Members interface.
What I have been forced to do is create my own role for “forum moderator” with additional capabilities added on top of the bbp_moderator defaults. The resulting outcome is that I am deliberately not using the bundled bbPress role, which effectively defeats the purpose of having implemented it in the first place.
I’m not sure why the new bbp roles are incompatible with the Members plugin, I get the following error when attempting to modify their available caps.
Fatal error: Call to a member function has_cap() on a non-object in /home/tamrielfoundry/tamrielfoundry.com/wp-content/plugins/members/admin/role-edit.php on line 31
Same issue here, also a bit scared to remap user roles. I looked into it, turns out as part of the new bbPress update that restructured some of its own user roles, it actually removed certain capabilities from existing roles. For example, my site-wide administrator role didn’t have the capability to read_hidden_forums or read_private_forums, in addition to 20 or so other bbPress specific capabilities.
If you are using default (or custom) WordPress roles in a bbPress environment, you may need to go in and grant them some of the bbPress specific capabilities.
@chromancer, thanks for digging into this. I worked out an alternative solution for hiding a private forum category, but it looks like you’ve nailed the issue. Might be worth working up a ticket for the trac on this one.
I can think of a number of scenarios in which having a private forum category would be ideal, this functionality would make a lot of sense to be supported in core IMHO.
I anticipate that’s not going to be feasible, because it would require him to count whether individual replies have been read, instead of simply toggling if a topic is read or not.
The database implications of flagging read status at the reply level are a bit scary.
Exact same problem. Have restored topics to be searchable, but searching for “&post_type=topic” just pulls the topic archive page.
Pippin, thanks for sharing your thoughts. Sorry the formatting of my original post was so hideous, I’m not sure what happened. I guess maybe line breaks got stripped after getting run through spam filter or something?
It’s definitely a tricky problem, I had thought about trying to write an “unread posts” function a while ago and decided against it because I was worried about scalability and database requirements. I wonder how some of the dedicated forum platforms handle this sort of feature.
Hi Pippin, great work on this plugin so far. Thank you. I read through the code and tested it out. The plugin works great, and I commend you for your hard work on this. I wanted to provide a bit of feedback in case you are planning any further revisions, just to weigh in with my 2c: 1) I realize you needed somewhere to hook the “mark as read/unread” link, and by default in bbp_theme_compat no action hook is provided in a topic header. Hooking it onto the subscribe link wedges it between subscribe/favorite and is overall a bit awkward for templating. I’m not sure what a better default solution would be, but personally I felt the need to unhook this and manually place the toggle button somewhere more appealing. 2) A standalone function to display a loop of unread topics would be great. show_unread_topics() is purpose built for the bbpress user profile, but under many circumstances users might want to call this list elsewhere (if we are using BuddyPress profiles for example). Personally I created a “View Unread Topics” page that functions similarly to the “Recent Topics” archive. Anyways, including a function for just the unread topics loop (with pagination) would be a nice addition for template flexibility purposes. 3) For a site with thousands of topics, is having that bulky a “_bbp_mar_read_ids” entry in meta a concern? 4) The plugin serves a nice function of allowing a user to track whether or not he/she has looked at topics which are posted. However, it seems to me that full “view unread posts” functionality would entail clearing resetting the “read” flag when the topic is updated with a new reply. What about saving each “read” ID to meta as: post_id?num_replies where num_replies is the number of replies to the topic when the user marked it as read. When a topic is called you can explode out how many replies it had when the user first marked it. If the topic now has more replies than when it was marked, you can override the “read” flag and reset it to unread. Probably not a very elegant solution, but I think what most users would be interested in is being able to generate a list of threads with unread content, not necessarily just unread topics. Anyways, thanks very much for your work on this. I’ll be keeping an eye on how this project develops. Andrew
Just got hit with this issue myself. Thought I’d throw my 2c on the pile.
If a category or forum has children, and no child is public, I run into some strange bugs where the category disowns all its children.
I’m trying to have a hidden category with private subforums for administrative purposes, ideally I could have:
Category = hidden
Subforum = private
Topics in Subform = public
Unfortunately both of these setups hit the bug documented above. The two setups I’ve found which works are either:
Category = hidden
Subforum + Topics = public
This has the undesirable side effect of subscribers being able to find the topic even though it’s nested in a hidden category.
OR:
Category = hidden
Subforum = private
Topics = private
This seems to work OK, but it requires that every new topic in the private subforums be switched to be flagged as private in the wp-admin area.
I’m gonna keep working on this, see if I can figure out a solution.
Well…it seems like you want a working solution more than an ideal one, so here goes. You could replace archive-forum.php with:
http://pastebin.com/NktqDANZ
Plus anything else you explicitly want in the page.
DISCLAIMER: I don’t actually advise doing this. I feel like there are probably better ways to achieve the categorical forum listing that you describe. I implemented a categorical forum listing on my own site (http://tamrielfoundry.com), using the general method outlined by Lynq in this thread:
http://bbpress.org/forums/topic/customising-bbp_list_forums-last-poster-block/
What you are asking for is outside the default scope of bbpress functionality. It can definitely be modded in using some custom php functions and templates.
Its because the first line of each post isnt getting wrapped in a paragraph tag for some reason. A quick css fix could be to assign a font-size for bbp-reply-content.
If you have your theme take control of the bbpress templates using the theme-compatibility settings you can change the header names in the various loops, specifically loop-forums.php and loop-single-forum.php
Not sure what the answer to your question is, but for what it’s worth the Simple Local Avatars plugin works flawlessly with bbpress.
http://wordpress.org/extend/plugins/simple-local-avatars/
Have you taken over control of bbpress templates using theme compatibility? If so you can modify yourtheme/bbpress/loop-forums.php and remove the list item:
li class=”bbp-forum-freshness”
Next from yourtheme/bbpress/loop-single-forum.php remove the same section and its contents:
li class=”bbp-forum-freshness
Finally you’ll have to adjust the CSS of your forums to compensate the width of the remaining forum columns for the missing freshness. Hope this helps.
EDIT: sorry, I tried to post the exact code blocks to remove, but the forum here isn’t letting me embed the code 
Adam,
This is definitely be possible. There’s a fair bit of work involved, but I re-wrote most of the bbpress templates from the ground up for my new site using the bbpress functions included in the plugin as well as a few custom ones I wrote myself.
Just install bbpress, set it to theme compatibility settings, then take over the css and template files in your theme directory.
CSS goes in yourtheme/css
Base bbpress page types go in yourtheme directory (archive-forum, archive-topic, single-forum, single-topic, single-topic-edit, single-reply-edit, and single-user are the most important ones)
All the sub-templates (content, loops, forms, and pagination) goes in yourtheme/bbpress
Using this as a general guide you can rebuild bbpress from the ground up to suit your needs. Check out my bbpress enabled theme at http://tamrielfoundry.com
Ok, this is definitely NOT the most elegant solution, but I contrived a crude fix to the problem. Since the false 404 flagging was happening only on user profile pages, I added the following to my single_user.php template just before the header.
global $wp_query;
$wp_query -> is_404 = false;
get_header(); // Loads the header.php template. ?>
Basically I’m just forcing the profile page to not be 404. I may try to work out a better solution, but for the time being, this appears to work.
EDIT: looks like the code snippet is having trouble displaying a greater than sign, anywhere you see > above, it should be a greater than sign (>).
-
This reply was modified 9 months, 3 weeks ago by
aaclayton.
-
This reply was modified 9 months, 3 weeks ago by aaclayton.
Same problem, did you ever discover a solution?
