CUNY Academic Commons

(Of course it would be the community team that finds this bug!)

LOL -- indeed.

After a quick look the problem that I'm getting is that when I click on any of the comment pages, the page loads but there's no content. I get the header, nav, sidebar, name of the group, and the sidebar, but nothing where the doc itself and the comments should show up.

On the doc that's linked to as an example it looks like the setting has been changed to just show all the comments and not paginate them, which means I can't test to see if it's a different problem on the live site. I think they're probably the same though, as the "Your status is all email" line would still show up with the problem I'm having locally. And since it was only 52 comments on a 52-per-page setting, there was only a Previous and 1 link, which I think means it's likely that even if there were more pages they would have had the same issue.

Some debugging showed me that the problem is with the query-builder.php file in the includes folder in the plugin. Specifically, these lines:

$template_path = bp_docs_locate_template( $template );
if ( !empty( $template ) )
include( apply_filters( 'bp_docs_template', $template_path, $this ) );

The issue is that $template is never set, which happens because all the template setting lines rely on $this->current_view being set. On the first page I land on when I click on a doc, the view is "single" so it works out, but for the comment pages, with urls like ...comment-page-2/#comments, the view doesn't seem to be set at all, so it doesn't know what template to pull in.

Does this sound right? Figured I wouldn't spend a bunch of time trying to fix it myself before getting your thoughts.

Oops sorry just saw your note that you disabled pagination on the Commons for the time being!

Thanks, Dan. Yes, I think this sounds right so far as it goes. So it sounds like the right tack is to get $this->current_view to be set to 'single' when looking at one of these comment pages. Can you investigate a bit more how to do this?

So I've made a little progress here - I went into integration-groups.php and found where current_view gets set and made it so that comment pages also get their view set to 'single'. A very small change - https://github.com/cuny-academic-commons/cac/commit/8dd04b3ece170961bf2504fcfec8d651776d5dd6

However after that a new problem came up - when I click on the other comment pages the URL changes but nothing else on the page does. The same comments (from the last page) show, and the list of comment page links stays the same, so that the link for the last page is still un-linked. So for some reason [doc url]/comment-page-2 is returning the same thing as [doc url]/comment-page-1 and comment-page-3. Could this be caused by how I messed with the view?

I spent a long time trying to figure out what was going on - since the problem is showing up with both the list of comments and the paginated comment links, my first bet was that something was going wrong with the cpage query var that keeps track of the comment page, but I couldn't get it for some reason.

Then I thought it could also be some kind of caching issue - so I deleted the comments.php file entirely and reloaded the page, and the comments were still there and the links were still (not) working like before. I don't know a whole lot about caching though so I'm not sure if that could really be the issue. Anyone have thoughts on where to go next?

So I've made a little progress here - I went into integration-groups.php and found where current_view gets set and made it so that comment pages also get their view set to 'single'.

Cool, this looks right.

Anyone have thoughts on where to go next?

This is not a caching issue. I think what's happening is that we're using WP's comment-page-x URL structure, but there's nothing in buddypress-docs's URL parsing logic to take care of this. To see what I mean, look at the following on a relevant comments-page-x page:

var_dump( buddypress()->current_action );
var_dump( buddypress()->action_variables() );

I should stop here and note that we're running a 3-year-old version of BuddyPress Docs. The same problem does not happen in newer versions, because newer versions use WP's native custom post type URL routing. It's only this old version that uses BP's action_variables() etc (not to mention the current_view stuff you've already stumbled upon). So we should be careful how much time we sink into coming up with a solution.

Here's what I'd try to do. After verifying what I say above about action_variables() etc, see if there's something you can do to trick the comment template into displaying comments from the "correct" page, given the information found in action_variables(). I'm not sure off the top of my head how to do that, but I assume it's possible by filtering comments_array or something like that. Take a bit of time to muck around in there and see if you can find something. If not, let's abandon this ticket and wait to inherit the fix when we upgrade someday. Thanks!

Thanks for the direction here - I think I got it to work!

I had to make three changes:
1- I think the comments_template() function is mostly designed for use with themes not plugins. So how we had it in wasn't actually loading our template file, just the default one from the theme. I added a filter on WP's "comments_template" hook so that when the action is the one for BP Docs (stole the test for that from elsewhere in the plugin) it loads up our comments template instead.
2- I added an extra argument to the call to wp_list_comments() to make it manually fetch the right page of comments based on the URL - I did this by pulling in the action_variables and then using str_replace to isolate the number.
3 - I added an action to the 'bp_before_blog_comment_list' hook to manually update the 'cpage' query var that WP uses to generate the paginated comment links. Used the same technique as for the wp_list_comments() argument. Strangely enough even with updating this query var before the comments are listed, I still needed to pass wp_list_comments() the 'page' argument - it wasn't able to just take it from the query var automatically.

I'm realizing now it'd probably be better to pull in the 'page' argument there from my newly updated 'cpage' query var instead of pulling it in again from action_variables- do you think it's worth going in and doing that?

I added the filters to bp-docs.php, which I doubt is the right place for them. Where do you think I should put them?

Oops forgot the link to the changeset - https://github.com/cuny-academic-commons/cac/commit/ace703435f2f6060acc7bda3deee672abcc40f9b