Certain Friends-related URLs 404

[boonebgorges]

Certain Friends-related URLs are 404ing. Specifically, URLs of the following form:

example.com/members/boone/friends/my-friends/newest

Part of the problem here is 'newest' is never defined as a subnav anywhere, so the canonical redirect gets botched. In any case, it's unlikely that the /newest/ syntax has *ever* done anything, at least recently.

These links are used in Notifications: ​https://buddypress.trac.wordpress.org/browser/trunk/bp-friends/bp-friends-activity.php#L82, and perhaps elsewhere.

We can probably just remove the offending 'newest' part from the links. If we need the functionality, we should probably do it with a URL parameter - ?type=newest or something like that.

[DJPaul]

Boone, did you ever get together a list of these URLs that don't exist in the subnav? We can verify by checking the URL against a 1.2.10 install, but I agree we should remove these if everything checks out.

[boonebgorges]

Here's a rundown of what's happening.

Before BP 1.2, the My Friends list could be ordered by Recently Active, Alphabetically, or Newest filters. The following functions were related to this functionality:

• bp_friends_header_tabs() - Displayed the order filters
• bp_friends_filter_title() - Set the title of the Friends page conditionally based on the desired order
• friends_get_recently_active(), friends_get_alphabetically(), friends_get_newest() - Formerly used directly from template tags to call up the appropriate list of friends

None of these functions are used anymore in BP, since 1.2. I'm going to deprecate them, and I'm going to remove the problematic URLs from the places they've leaked through to the current BP.

There is a further question as to whether we want to support the filtering/ordering of member lists based on URL parameters ($_GET). Currently, the relevant logic lives in bp_dtheme_ajax_querystring(), which parses certain $_POST parameters (from AJAX requests) with parameters from the $_COOKIE global. The hard part about introducing $_GET into this equation is knowing how the order of precedence should work. It seems to me that $_GET should always *win*, since it doesn't make sense to ever have results that don't match the URL in the address bar, but this will cause all sorts of funny issues with AJAX refreshing. For the moment, I think we can safely just ignore the issue, but at some point in the future we may want to consider rethinking some of this (maybe with a theme rewrite).

[boonebgorges]

On second thought, I'm going to leave the friends_get_*() functions. We don't use them, but they are potentially useful wrappers for the BP_Core_User class that still function fine. So I think it makes sense to leave them as utilities, rather than expecting people to instantiate BP_Core_User directly.

[boonebgorges]

(In [6047]) Cleanup of outdated URL parameters in Friends component.

Before BuddyPress 1.2, it was possible to set the order of a friends list
(alphabetical, newest, recently active) by appending the appropriate action
variable. This changeset cleans up some remaining remnants of this outdated
method of filtering:

• Deprecates functions responsible for rendering related Alphabetical, Newest,

and Recently Active links

• Cleans up Friends notification functions so that the deprecated URLs are not

applied to Friendship Accepted notifications

Fixes #4077