Skip to:
Content
Pages
Categories
Search
Top
Bottom

Writing a new plugin – get 404 not found when accessing screen


  • farmer paul
    Member

    @vtowel

    Hi there,

    We’re running BuddyPress 1.2.5.2. I’ve just written a new BP component that displays BP groups in a tree format. It’s very simple – all it does is provide one screen, accessible at the slug “groupsdir”, that displays our group directory structure in a custom way. However, no matter how carefully I’ve checked and double-checked my code, trying to access /groupsdir from the WP root gives me a 404 Page Not Found error.

    I’m sure my …_setup_globals() and …_setup_nav() functions are getting called at the right times (I inserted some echo statements to make sure). After those functions are called, shouldn’t BuddyPress call my specified screen function when the corresponding specified slug is called? Or is there more to it than that? I feel like I must be missing something.

    Here are those functions:
    `function bp_gdatree_setup_globals() {
    global $bp;
    $bp->groupsdir->id = ‘groupsdir’;
    $bp->groupsdir->slug = BP_GDATREE_SLUG; // that slug is “groupsdir”
    $bp->active_components[$bp->groupsdir->slug] = $bp->groupsdir->id;
    }
    add_action( ‘wp’, ‘bp_gdatree_setup_globals’, 0 );
    add_action( ‘admin_menu’, ‘bp_gdatree_setup_globals’, 0 );

    function bp_gdatree_setup_nav() {
    global $bp;

    /* Add ‘Conferences Directory’ to the main user profile navigation */
    bp_core_new_nav_item( array(
    ‘name’ => __( ‘Conferences Directory’, ‘bp-gdatree’ ),
    ‘slug’ => $bp->groupsdir->slug,
    ‘screen_function’ => ‘bp_gdatree_screen_directory’,
    ‘show_for_displayed_user’ => false
    ) );
    }
    add_action( ‘wp’, ‘bp_gdatree_setup_nav’, 2 );
    add_action( ‘admin_menu’, ‘bp_gdatree_setup_nav’, 2 );`

    When you navigate to /groupsdir, instead of executing the function `bp_gdatree_screen_directory()`, a 404 Page Not Found screen is displayed.

    Does anyone have any advice for me? Thanks.

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

  • Anonymous User 96400
    Inactive

    @anonymized-96400

    bp_core_new_nav_item adds to a users menu, not to the root. You want to look into the function `bp_core_add_root_component`. The skeleton component is a good place to start. Also, have a look at how the various BP components handle it.


    farmer paul
    Member

    @vtowel

    Wow, well I had no idea. Where in the skeleton component do you see this mentioned? That’s exactly what I’ve been following to build my plugin. Then I started looking into the `messages` component to see if there was something I was missing, but didn’t make any headway. I guess I didn’t look at enough other components.

    Thanks for the tip.


    farmer paul
    Member

    @vtowel

    Well, still no luck. I added this to my code:

    `function bp_gdatree_setup_root_component() {
    /* Register ‘groupsdir’ as a root component */
    bp_core_add_root_component( BP_GDATREE_SLUG );
    }
    add_action( ‘wp’, ‘bp_gdatree_setup_root_component’ );
    add_action( ‘admin_menu’, ‘bp_gdatree_setup_root_component’ );`

    Again, I used an echo statement to verify that this function was in fact getting triggered. Despite this, I still get a 404 error when I visit /groupsdir.

    Just occurred to me to try accessing the page from /members//groupsdir – and at least that works!

    So any idea of what else to try?


    farmer paul
    Member

    @vtowel

    (Oops – make that /members/[my username]/groupsdir)


    farmer paul
    Member

    @vtowel

    Could it have to do with the order that `bp_gdatree_setup_globals`, `bp_gdatree_setup_nav`, and `bp_gdatree_setup_root_component` are run in…? I’m not sure what the correct order is.


    farmer paul
    Member

    @vtowel

    Tried changing the priority of `add_action( ‘wp’, ‘bp_gdatree_setup_root_component’ )` – still no difference. Can’t seem to scrap the 404 no matter what I try. I’m out of ideas.


    farmer paul
    Member

    @vtowel

    Well I couldn’t resist investigating further, and it turns out that the code that BuddyPress runs to compare the URL to the `$bp->root_components` array happens during the `bp_loaded` action, which happens during the WP `plugins_loaded` action, which seems to happen *before* the `bp_init` action – which is the action I’m supposed to use to cause my plugin’s code to be loaded in the first place.

    So basically it seems I’m screwed if I want to cleanly add a root component to BuddyPress from within my plugin. I’ll have to do a bit of fudging in my plugin’s `loader.php` file instead.


    kunalb
    Participant

    @kunalb

    @farmerpaul I’ve added root components starting from bp_loaded, with the component registered at setup_globals (setting up $bp->{component name}, etc.) and bp_setup_root_components and adding the controller for the component at wp,1 and navigation at wp,2 (I needed them to be after init as I was joining custom posts types which become available at init).

    See these files:
    http://code.google.com/p/buddypress-custom-posts/source/browse/trunk/buddypress-custom-posts/controller.php
    http://code.google.com/p/eventpress/source/browse/trunk/eventpress/controllers/main.php


    Paul Wong-Gibbs
    Keymaster

    @djpaul

    In my loader.php, I hook into ‘bp_include’ and include a main file. In that other file, I use ‘bp_setup_globals’ for globals and ‘bp_setup_root_components’ to register the root component. You can view my source at http://code.google.com/p/achievements/source/browse/achievements/trunk/includes/achievements-core.php if it helps.

    Also: https://buddypress.org/community/groups/creating-extending/forum/topic/plugin-authors-important-buddypress-1-2-5-news-you-need-to-know/

    Thanks, you two. This sort of info would be fantastic to include in the Codex and as revisions to the Skeleton Component so more of us don’t spend days scratching our heads. :)


    Jeff Sayre
    Participant

    @jeffsayre

    The way in which you check to make sure BuddyPress is installed and activated has changed over time. As @djpaul indicates, the proper way is to use a mypluginname_loader.php file and hook into the bp_include event: https://codex.buddypress.org/extending-buddypress/checking-buddypress-is-active/

    The BuddyPress Skeleton Component is woefully out of date a this time. So you should use it as a general guide only. To get a clearly understanding of how things are done, I suggest studying a few of the more popular, major custom components that work with the latest version of BP.

    Thanks, @jeffsayre. I must have missed that page when I was browsing the Codex. I was following the Skeleton Component because my coworkers had recommended it to me. However, apparently none of them tried writing a BP plugin that provided a root component!

    Now my problem isn’t that I’m getting a 404 error anymore. Instead, now when I go to “/groupsdir”, BuddyPress is redirecting me to the root “/”, without an explanation. Spent the last hour or so trying to figure out where this is happening. No luck so far, but I’ll keep looking.

    @travel-junkie: You explained how root components were registered, and that `bp_core_new_nav_item` adds to the member’s menu, not to the root. But surely I still need to call `bp_core_new_nav_item` to tell BP which screen function to use when the “groupsdir” component is requested – right? So I’m still using `bp_core_new_nav_item` to provide that information – *in addition* to calling `bp_core_add_root_component` to state that “groupsdir” is also a root component. Is this correct?

    Since I’m trying to meet a deadline I’m just going to leave this for now, and make do with accessing the page from the member domain (i.e., /members/[username]/groupdir).

    But if anyone has any inkling as to why accessing /groupsdir as a root component is redirecting me to the home page, I’d be most appreciative! I find it really tricky trying to follow the exact flow of actions that happen when a BP page is accessed.


    Anonymous User 96400
    Inactive

    @anonymized-96400

    Once you have set your plugin up as a root component, you can write your own screen function, like so:

    `function mapo_directory_setup()
    {
    global $bp;

    if( $bp->current_component == $bp->mapology->slug )
    {
    $bp->is_directory = true;

    do_action( ‘mapo_directory_setup’ );
    bp_core_load_template( apply_filters( ‘mapo_template_directory’, ‘maps/index’ ) );
    }
    }
    add_action( ‘wp’, ‘mapo_directory_setup’, 2 );`

    I use something like the above in one of my plugins. You’ll have to adjust the if statement to your needs.

    So basically you have different screen functions for your members pages and your directory page (as you should :)


    vusis
    Participant

    @vusis

    @vtowel. did you finally get this to work for you? I’m still getting the 404 error. :(


    vusis
    Participant

    @vusis

    finally I figured it out:
    for the benefit of those that are still going into this:

    what I eventually had to do is call the _init function from the loader.php directly without checking if bp is loaded. I think the problem was that i was hooked into a delayed action.

    If anyone can provide an appropriate action for me to hook into it would be great, but for now. No hook and it works.

Viewing 16 replies - 1 through 16 (of 16 total)
  • The topic ‘Writing a new plugin – get 404 not found when accessing screen’ is closed to new replies.
Skip to toolbar