__group__,ticket,summary,reporter,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Commit Candidates,3544,View RSS feeds return the all-topic feed if the view doesn't exist,dd32,johnjamesjacoby,API - Feeds,2.1,high,normal,2.6.10,defect (bug),assigned,commit,2023-04-11T03:07:21Z,2024-03-17T13:08:31Z,"If a request such as https://example.org/view/dd32-is-awesome/feed/ is requested, bbPress will process the request and output a valid feed.
Unfortunately, on most sites, this bbPress view simply doesn't exist.
The attached PR resolves this similar to how the non-feed query handles validating if the view exists: https://github.com/bbpress/bbPress/blob/394ae31c059228e866240076db2dc2ca2ddc8a7c/src/includes/core/template-functions.php#L650-L658",dd32
Has Patch / Needs Testing,3508,BBP_Converter_DB does not have a method “__destruct,Robin W,johnjamesjacoby,API - Importers,,high,normal,2.6.10,defect (bug),assigned,has-patch,2022-12-25T17:33:12Z,2024-01-24T10:05:17Z,"https://bbpress.org/forums/topic/bbp_converter_db-does-not-have-a-method-__destruct/#post-233566
line 33 of
says
`register_shutdown_function( array( $this, '__destruct' ) );`
but there is no function for this in bbpress
",Robin W
Has Patch / Needs Testing,3591,"Recount topics for each user, counts only published topics",GDragoN,johnjamesjacoby,Component - Users,2.6.9,high,major,2.6.10,defect (bug),assigned,has-patch,2024-01-23T10:46:55Z,2024-01-23T13:24:41Z,"This tool should take into account published and closed topics. Right now, recount counts only published topics.",GDragoN
Needs Patch,3447,Incorrect edit URL produced by bbp_get_reply_edit_url() in WordPress 5.9,danielbachhuber,johnjamesjacoby,API - Rewrite Rules,2.6.9,high,major,2.6.10,defect (bug),assigned,,2022-02-09T16:37:17Z,2023-11-17T20:25:54Z,"In WordPress 5.8, `bbp_get_reply_edit_url()` returns a value like:
{{{
https://www.foodbloggerpro.com/community/general-discussion/fbp-feature-or-content-requests/?reply=112532&edit=1#post-112532
}}}
In WordPress 5.9, the returned value is:
{{{
https://www.foodbloggerpro.com/community/general-discussion/fbp-feature-or-content-requests/#post-112532/edit/
}}}
I'm not sure what changed deeper down. Our short-term fix is to filter `bbp_get_reply_edit_url`",danielbachhuber
Needs Patch,3473,Search displays hidden forums to participants,wpsolr,johnjamesjacoby,Component - Search,2.6.9,high,normal,2.6.10,defect (bug),assigned,,2022-07-14T09:17:37Z,2024-03-16T11:34:08Z,"Hi,
1) I created a hidden forum with topics and replies as a keymaster
2) I logged in as a Participant
3) A search will not display topics and replies as expected, but the forum itself is displayed!
4) Clicking on the forum shows a 404 page, as expected
WordPress 6.0
Plugins active: bbPress, Classic Editor
",wpsolr
Needs Patch,3459,BP Rewrites,shawfactor,johnjamesjacoby,Extend - BuddyPress,,high,normal,2.6.10,task (blessed),assigned,,2022-05-05T06:46:47Z,2022-05-05T07:08:18Z,"Team,
BP Rewrites is a BuddyPress feature as a plugin which end goal is to be merged with BuddyPress Core. It’s being developed and maintained by the official BuddyPress development team. As migrating the BP Legacy URL parser to using the WP Rewrites API is potentially a breaking change for some BuddyPress plugins and themes, the BuddyPress team needs the BuddyPress users, contributors & developers to massively test this feature before safely including it into BuddyPress Core.
Currently the BBpress won't work with bp rewrites, namely the bbpress/includes/extend/buddypress/functions.php section needs rewriting.
I'm testing it and I'm getting the following errors:
{{{
[05-May-2022 06:35:01 UTC] PHP Notice: bp_displayed_user_id() was called incorrectly.
Please wait for the `bp_parse_query` hook to be fired before using it. http:///?redirect_to=https:///2020/03/02/images-of-week-15-2019-20/20200302_161241/ require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('init'), WP_Hook->do_action, WP_Hook->apply_filters, bbp_init, do_action('bbp_init'), WP_Hook->do_action, WP_Hook->apply_filters, bbp_register, do_action('bbp_register'), WP_Hook->do_action, WP_Hook->apply_filters, bbp_register_taxonomies, do_action('bbp_register_taxonomies'), WP_Hook->do_action, WP_Hook->apply_filters, bbPress::register_taxonomies, current_user_can, user_can, WP_User->has_cap, map_meta_cap, apply_filters('map_meta_cap'), WP_Hook->apply_filters, bbp_map_meta_caps, apply_filters('bbp_map_meta_caps'), WP_Hook->apply_filters, bbp_map_topic_tag_meta_caps, user_can, WP_User->has_cap, map_meta_cap, apply_filters('map_meta_cap'), WP_Hook->apply_filters, bbp_map_meta_caps, apply_filters('bbp_map_meta_caps'), WP_Hook->apply_filters, bbp_map_primary_meta_caps, bbp_is_user_inactive, bbp_is_user_active, bbp_get_user_id, apply_filters('bbp_get_user_id'), WP_Hook->apply_filters, bbp_filter_user_id, bp_displayed_user_id, apply_filters('bp_displayed_user_id'), WP_Hook->apply_filters, BP\Rewrites\bp_displayed_user_id, BP\Rewrites\_was_called_too_early Please see Debugging in WordPress for more information. (This message was added in version BP Rewrites.) in /wp-includes/functions.php on line 5775
}}}
As this is going to be merged into buddypress core at some stage I would suggest that getting the vtwo plugins to woirk togther asap would be very benficial as it will allow much more real world testing
",shawfactor
Commit Candidates,3492,"""You may use these HTML tags and attributes:"" not escaped correctly",naxoc,johnjamesjacoby,General - UI/UX,,normal,normal,2.6.10,defect (bug),assigned,commit,2022-10-21T14:16:24Z,2022-10-24T08:52:48Z,"In some places the ""You may use these HTML tags and attributes"" string is not escaped correctly and ends up escaping the `` tag too.
This fixes that.
Before:
After:",naxoc
Needs Dev / Bug Wrangler Feedback,3493,"Default arg to ""bbp_add_forums_roles()"" can cause errors",naxoc,johnjamesjacoby,API - Roles/Capabilities,2.2,normal,normal,2.6.10,defect (bug),assigned,dev-feedback,2022-10-21T14:30:52Z,2022-10-24T08:52:13Z,"The `bbp_add_forums_roles()` function has a default arg of `null` for `$wp_roles`. That causes problems when we try to use it in the loop in the function. This patch adds a check and initializes the `$wp_roles` var if necessary.
",naxoc
Has Patch / Needs Testing,3486,The content-archive-forum.php template does not filter if the search form should be displayed,naxoc,johnjamesjacoby,Component - Search,trunk,normal,normal,2.6.10,defect (bug),assigned,has-patch,2022-10-04T19:53:54Z,2023-10-25T13:03:55Z,"Other templates wrap outputting the search from in a conditional using `bbp_allow_search()`. The attached patch wraps the search form in a conditional.
I copied over the div wrapper with the `bbp-search-form` class that the search form is wrapped in from `content-archive-topic.php` too.
",naxoc
Needs Reporter Feedback / Steps To Reproduce,3503,bbp_get_reply_url() generates incorrect paginated urls for topics with hidden replies,dd32,,General,2.0,normal,normal,2.6.10,defect (bug),new,reporter-feedback,2022-12-02T00:07:31Z,2022-12-05T01:08:13Z,"bbp_get_reply_url() is used within emails to link to a paged topic URL for a reply within a topic.
However, this function can generate the incorrect pagination URL for replies when a topic has hidden replies - because they're spammed, or in the case of WordPress.org/support 'archived'.
Take this example, where there's 2 replies per page displayed:
{{{
1. Thread post
2. Reply 1
3. Reply 2 <-- Spammed.
4. Reply 3
}}}
When a non-moderator views the above thread, they'll see a single-page of replies. Reply 1 and Reply 3. When a moderator views it, they'll see two-pages of replies with all three replies.
However, in both cases, `bbp_get_reply_url( $reply_3 )` will return `topic/page/2` and for the non-moderator following that link, will land on a page with no replies, as the ""correct"" link was `topic/`.
This leads to a lot of confusion.
I see several options:
- Have `bbp_get_reply_url()` actually count the replies visible, rather than using the cached reply_position value.
- Have `bbp_get_reply_url()` never return a pretty-url, and instead use a url such as `topic/?reply=123` and redirect to the appropriate paged url upon request
- Have `bbp_get_reply_position_raw()` not give a reply_position to hidden replies.
All of those have one thing in common: The URL to individual replies will constantly change, as the pagination location of the reply is never truely known.
Another option is that when displaying threads, hidden replies should be taken into account, so in the above example, with 2 replies per page, everyone would only see 1 reply on Page 1, and 1 reply on Page 2. Arguably a worse-experience.
This was reported as #meta6443",dd32