[artifex223]

Thanks for the response Paul! Although, I think we’ve just figured out an alternative solution.

In my original post, I wrote that the member area URL uses user_login, which in our case is the user’s email. But that isn’t entirely true; the URL uses the user’s nicename.

So our new workaround will be to simply reconfigure the user’s nicename, which will then be used in the member area URL without any further changes, and without any modifications to core files. In order to avoid exposing database information like user_id, we are actually planning on using a hashed version, but the concept remains the same.

Do you foresee any complications in this plan of action?

[artifex223]

I was able to get this issue resolved.

After applying bp_core_new_nav_default(), I wrote a function to append ‘public’ to the [‘link’] item in the bp_options_nav array for the public profile page, and hooked it into ‘bp_before_member_header’.

Unfortunately, even with the link changed, clicking the Public tab still took me to the new default, the Edit tab. After a bit of searching, I found bp_redirect_canonical(), which was chopping off the ‘public’ I had added to the link. So I wrote another function to filter into ‘bp_do_redirect_canonical’ that returns false if the current component is profile and the current action is public.

Having finally produced the result I was aiming for, I still needed to make sure this change was only applied when the logged in user was viewing their own profile. Since bp_core_new_nav_default() needs to be hooked onto ‘bp_setup_nav’, I was not able to use the regular BP functions for current_user and displayed_user, since $bp is not fully setup by that point. So I wrote a function to determine if the profile being viewed belongs to the logged in user by comparing the third chunk of the URL with the user’s login, and used the result as a condition for applying the other hooks and filters.

My code is built into a class structure, which is why I did not simply paste it here. If anyone needs more help with this, though, let me know and I will see about refactoring the code for you into something that can just be dropped into functions.php.

[artifex223]

Yeah, Favorites is more of a personal bookmarking sort of feature. I believe there are plugins available that will replicate the Facebook “Like” functionality, although I haven’t used any of them myself.

[artifex223]

@kizzywizzy – The function get_user_meta() just returns the data; it does not display it. So if that is the only line of code you’ve added, you won’t see any output. You’ll want to assign the output of the function to a variable and echo that, or just echo the output directly.

Here is the example from the Codex:

<?php 
  $user_id = 9;
  $key = 'last_name';
  $single = true;
  $user_last = get_user_meta( $user_id, $key, $single ); 
  echo '<p>The '. $key . ' value for user id ' . $user_id . ' is: ' . $user_last . '</p>'; 
?>

[artifex223]

In case anyone comes across this with a similar issue…

I was able to resolve many of my BP AJAX related issues (this one, comments appearing blank, Join Group buttons missing).

Two things were messed up with my custom theme:

My activity stream was not inside a <div> with id=”content”, and bp_tpack_theme_setup() (from the Buddypress Template Pack) was not running, for some reason. I simply added the div id and copied the template pack setup function into my theme and all is well.

[artifex223]

@andrewgtibbetts I’m having a lot of trouble with a similar issue. Were you able to get this figured out?

In my case, I’m not even trying to do away with the Public subnav; I just want Edit to be the default subnav when a user clicks their Profile nav. I’ve tried bp_core_new_nav_default(), which successfully sets the Edit subnav as default when clicking the Profile nav, but it breaks the Public subnav link, since clicking that subnav still directs the user to /members/{username}/profile, which is the new home of the Edit page, and not to /members/{username}/profile/public where you’d want it.

On top of that, changing the default subnav to Edit now allows any user, logged in or not, to edit any other user’s profile simply by going to /members/{username}/profile… this is certainly not ideal. I have a feeling that this might be a problem related to my theme, but it does raise a good point: that I’ll need some logic to determine if the logged in user is the displayed user, and to only change the default in this case. This would be simple enough if bp_core_new_nav_default() functioned as it should…

When bp_core_new_nav_default() proved that it would not be useful here, I decided to go the route of removing the Profile nav and its subnavs altogether and rebuilding them with the intended defaults built-in… this caused more problems than I care to type out, likely due to my inability to determine the best action to hook into.

@boonebgorges I believe I saw that you wrote bp_core_new_nav_default(), or at least worked on a ticket trying to iron out some of its bugs. Can you shed any light on the issue with this function not updating the subnav hyperlinks? Or possibly suggest an alternative path forward to allow us to default to the Edit subnav for logged in users?

Thanks very much.

[artifex223]

@tsuperstar20 , Did you find a solution to this problem? I’m having the same issue with my own theme. I’m sure it’s something I’ve done, but I have no idea what. Perhaps the cause is the same in both cases?

[artifex223]

@ubernaut I know this thread is a few months old, but I thought I’d mention that yes, it is possible to modify your files to include the changes in the patch. Hacking core files is, of course, never recommended, since the changes will likely be paved over on the next update… but I really needed to get this change implemented, and only one of the functions had a hook built in. The way I see it, if I make these exact same changes, hopefully I won’t even notice a difference when the update comes out. Even so, I’ve made a note to review these two files when the update comes around.