Skip to:
Content

BuddyPress.org

Opened 4 months ago

Closed 4 months ago

#9108 closed defect (bug) (fixed)

BuddyPress Classic Plugin Issue: Incorrect Profile Linking in Custom Sub-Navigation

Reported by: vapvarun's profile vapvarun Owned by: imath's profile imath
Milestone: 12.4.0 Priority: normal
Severity: normal Version: 12.0.0
Component: Navigation Keywords: has-patch
Cc:

Description

The issue described involves a WordPress site with BuddyPress plugin and a custom sub-navigation created within the BuddyPress member section. When the BP Classic plugin is activated, navigation links that are supposed to point to the currently logged-in user's profile are incorrectly pointing to the profiles of other displayed users. This issue persists across different profile links, such as friends and groups. However, after deactivating the BP Classic plugin, adjusting settings, and refreshing permalinks, the links correctly point to the logged-in user's profile. The problem appears to be specifically related to the BP Classic plugin affecting the dynamic linking of user profiles within the site's navigation system.

https://www.loom.com/share/27a30306f0f6439bab5374559db55b3a

Change History (7)

#1 @imath
4 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to reported-upstream
  • Status changed from new to closed

Thanks for your report, as it’s about BP Classic I’ll deal with it form there

I must say I have difficulties to understand what you mean by sub nav as only the main nav can be used as WP navigation links…

Last edited 4 months ago by imath (previous) (diff)

#2 @imath
4 months ago

  • Keywords needs-patch added
  • Milestone set to 12.4.0
  • Resolution reported-upstream deleted
  • Status changed from closed to reopened

I've replied too quickly, it's actually something we need to fix here.

#3 @vapvarun
4 months ago

seems $bp_menu_items = $bp->members->nav->get_primary();
https://github.com/buddypress/buddypress/blob/16d64d547c2ee45b913469b55cecb5e49b05b129/src/bp-core/bp-core-functions.php#L2794

is creating issue

<?php
        if ('rewrites' !== bp_core_get_query_parser()) {
                error_log('Using non-rewrite query parser');
                $bp_menu_items_x = $bp->members->nav->get_primary();

                // Prepare the array to hold updated menu items.
                $updated_menu_items = [];

                // Base URL for the logged-in user's profile.
                $loggedin_user_url = bp_loggedin_user_domain();

                foreach ($bp_menu_items_x as $item) {
                        // Clone the item to avoid modifying the original directly.
                        $new_item = clone $item;

                        // Update the link to point to the logged-in user's profile section.
                        // This assumes that the slug is a valid and unique identifier for the profile section.
                        $new_item->link = trailingslashit($loggedin_user_url . $new_item->slug);

                        // Add the updated item to the array.
                        $bp_menu_items[] = $new_item;
                }
                
                error_log(print_r($bp_menu_items, true)); // Log the output of $bp_menu_items
        }

by default, we are getting URLs for displayed user-id
I tried to pass values to bp_loggedin_user_domain during debugging to make it work.

This information is only being added to the log for the purpose of documentation and is not a solution to the problem

This ticket was mentioned in PR #237 on buddypress/buddypress by imath.


4 months ago
#4

  • Keywords has-patch added; needs-patch removed

The BP Core Nav has always stored items using the displayed user ID.

Before 12.0.0, the bp_core_create_nav_link() was forcing the link attribute of items to be a logged in user link and a replacement was performed during displayed member navigation generation so that this link became the displayed user link.

Starting in 12.0.0, this link attribute is no more used by default when creating these nav links, instead, we are generating this link attribute using a function to check whether primary slug items has been customized or not.

Links for the bp_nav_menu_get_loggedin_pages() are built using the bp_get_component_navigations() when the BP URL parser is set to rewrites while it keeps on using the BP Core Nav items when it is set to legacy. This is necessary because plugins not ready yet for BuddyPress 12.0 are not registering their nav items but just setting them. For this particular case: we need to reset the primary item link to the logged in user one when viewing a member (as nav items are now using the displayed user link by default).

This will fix the issue for users that are forced to use BP Classic by plugins not updating their code for the Modern BuddyPress 😫.

Trac ticket: https://buddypress.trac.wordpress.org/ticket/9108

#5 @imath
4 months ago

  • Version set to 12.0.0

Thanks @vapvarun for your complementary debug info, I'm explaining in my PR ^^ why we get this bug with the legacy BP URL Parser.

#6 @imath
4 months ago

In 13744:

BP Member’s nav: reset primary nav item links when a user is displayed

Since 12.0, the member’s nav item links are no more initialized with the logged-in user links but are left empty and built using the BP Rewrites API. It generated a compatibility issue when the BP Legacy URL parser is in use (eg: when the BP Classic Add-on is active): the BP Member’s nav used to populate a custom WP Nav Menu was wrongly using the displayed member’s links instead of the logged-in user ones.

Making sure to reset these links in favor of the logged-in user ones in such a case is now necessary during the custom WP Nav Menu generation process.

Props vapvarun espellcaste

See #9108 (trunk)
Closes https://github.com/buddypress/buddypress/pull/237

#7 @imath
4 months ago

  • Owner set to imath
  • Resolution set to fixed
  • Status changed from reopened to closed

In 13745:

BP Member’s nav: reset primary nav item links when a user is displayed

Since 12.0, the member’s nav item links are no more initialized with the logged-in user links but are left empty and built using the BP Rewrites API. It generated a compatibility issue when the BP Legacy URL parser is in use (eg: when the BP Classic Add-on is active): the BP Member’s nav used to populate a custom WP Nav Menu was wrongly using the displayed member’s links instead of the logged-in user ones.

Making sure to reset these links in favor of the logged-in user ones in such a case is now necessary during the custom WP Nav Menu generation process.

Props vapvarun espellcaste

Fixes #9108 (branch 12.0)

Note: See TracTickets for help on using tickets.