Skip to:
Content
Pages
Categories
Search
Top
Bottom

Setting Edit page as default for Profile

  • Avatar of Andrew Tibbetts
    Andrew Tibbetts
    Participant

    @andrewgtibbetts

    I’m hiding the public profile tab and having the edit page be default for the logged in user’s profile. Here’s what was working a few months ago—I assume something changed in an update:

    `
    function init_profile_tab() {
    global $bp;

    bp_core_remove_subnav_item( ‘profile’, ‘public’ );

    }
    add_action( ‘bp_setup_nav’, ‘init_profile_tab’, 999 );

    // change sub tab default on profile
    function init_priority_profile_tabs() {
    global $bp;

    if (bp_is_my_profile()) {

    bp_core_new_nav_default(array(
    ‘parent_slug’ => $bp->profile->slug,
    ‘screen_function’ => ‘bp_profile_screen_edit’,
    ‘subnav_slug’ => ‘edit’
    ));

    }

    }
    add_action( ‘bp_setup_nav’, ‘init_priority_profile_tabs’, 5 );
    `

    I suspect that screen_function is no longer supported? Maybe the subnav_slug?

Viewing 2 replies - 1 through 2 (of 2 total)
  • Avatar of artifex223
    artifex223
    Participant

    @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.

    Avatar of artifex223
    artifex223
    Participant

    @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.

Viewing 2 replies - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.