CUNY Academic Commons

Apologies for leaving production with uncommitted changes, Boone.

I think commit 462e7bc isn't necessary since I've worked around those core bbPress mods in the following commits:

• https://github.com/cuny-academic-commons/cac/commit/bb4b5aa3dc306b6c2929083ef71d0ae210d62a03
• https://github.com/cuny-academic-commons/cac/commit/77268fc2d403d0afab216b95510e647da95b0684
• https://github.com/cuny-academic-commons/cac/commit/527a3ac800e0b63258b0f4affa1508bf2b2b3f82. Regarding this fix, please take a look at what I mentioned here -- https://redmine.gc.cuny.edu/issues/25718#note-17 -- to see if the logic is sound. I opted to always check all available post statuses for the 'forum' post that is connected to a group, but we could restrict the 'private' or 'hidden' post status check only if the group is private or hidden.

I did leave production uncommitted because commit 462e7bc included changes to the 'participate' to 'exist' caps, which I didn't make and wasn't sure if you were still doing some debugging with that.

To be clear, the original cac-bbpress-2.6.17.diff is still needed for 2.6.19, but the upcoming bbPress 2.6.20 might not need it as JJJ has made some adjustments here. We will need to test to be sure though.

Thanks, Ray. No apologies necessary - obviously I left things a mess myself with my 'exist' tests.

Regarding those unstaged changes, I understand how I can discard the bbp_include_all_forums part (and I think that your workaround in https://github.com/cuny-academic-commons/cac/commit/527a3ac800e0b63258b0f4affa1508bf2b2b3f82 is a fine fix for this), and I understand that I can get rid of the participate/exist checks. But what about the super-sticky stuff? That's covered by https://github.com/cuny-academic-commons/cac/commit/77268fc2d403d0afab216b95510e647da95b0684?

It appears that John has cleared out the 2.6.20 milestone, and it looks like it includes extensive changes https://bbpress.trac.wordpress.org/query?milestone=2.6.20&status=accepted&status=assigned&status=closed&status=new&status=reopened&status=reviewing&order=priority&col=id&col=summary&col=status&col=milestone&col=owner&col=type&col=priority Like you said, we're going to have to spend energy to test and merge our customizations when 2.6.20 is released, so perhaps we should just skip the 2.6.19 upgrade for the time being, in case that release is imminent. Let's hold off here and circle back in a week to see where things stand.

But what about the super-sticky stuff? That's covered by https://github.com/cuny-academic-commons/cac/commit/77268fc2d403d0afab216b95510e647da95b0684?

Right, so the rationale here is we should only be querying for private and hidden forum IDs if super stickies are requested since we do not want private super-stickies to be visible. The super-sticky stuff is an edge case anyway because we do not even use super-sticky threads on the Commons.

Commit 77268fc is basically the non-core hack for https://github.com/cuny-academic-commons/cac/commit/c37a78925c77b47ed184b02eaba954f7b8e48ece#diff-5a93bb033ee9df1113ad7df1fba496977ad0c458af6f3e4311bff718f32280e0

It appears that John has cleared out the 2.6.20 milestone, and it looks like it includes extensive changes

bbPress 2.6.20 was released on October 15th, so we should just go ahead and use 2.6.20 for testing. Looks like the upcoming 2.6.21 fixes a bunch of regressions, so we should hold off until 2.6.21.

There will probably be many things to test, but one main change to look out for is the one that covers activity filtering: https://github.com/bbpress/bbPress/commit/8c087ec3439ca4cdc22e95bb8dd7cdc8f2751289.

Looks like the upcoming 2.6.21 fixes a bunch of regressions, so we should hold off until 2.6.21.

Good catch. I'll check every few days for the 2.6.21 release so that we can get started.