Skip to:

Opened 14 years ago

Closed 14 years ago

#2518 closed defect (bug) (fixed)

[patch] At setup: Selecting existing WP pages to serve as BP pages doesn't work

Reported by: boonebgorges's profile boonebgorges Owned by:
Milestone: 1.5 Priority: critical
Severity: Version:
Component: Core Keywords: has-patch needs-testing developer-feedback


In trunk (3130), there are a couple of things broken with the way that WP pages and BP pages are linked:

1) Choosing an existing page doesn't work quite right. The hrefs for the main navigation tabs (under the blog title) are created using $bp->[component]->name. There is no reference to the bp-pages sitemeta where the information created during this setup step is stored.

2) The way that the items are being stored (as sitemeta) is messing up some permalinks when BP_ROOT_BLOG is defined in wp-config.php. See #2456. Plus there are references to get_blog_option and other MS-only functions.

3) This is a question more than a statement: Are the choices that people make for BP pages supposed to reflect slugs throughout the site? Eg if I choose an existing page called "Folks" to be the Members page for my installation, that means that the members directory will be at But what about That'll only work if the admin has defined a different members slug. This seems like a redundant step - IMO it would be nice if the slug were created based on the page name (though this would require some finagling, I'm sure).

I'm gonna take a swing at a few patches to clean up the WP page linking to see if I can make sense of it, especially with issues (1) and (2) listed above.


Attachments (1)

save_pages_to_blog_meta.patch (4.2 KB) - added by boonebgorges 14 years ago.

Download all attachments as: .zip

Change History (9)

#1 @DJPaul
14 years ago

FYI Trunk hasn't been merged with the 1.2 branch in a looong time. Come on jjj! ;)

#2 @boonebgorges
14 years ago

  • Keywords has-patch needs-testing developer-feedback added

OK, I'm attaching the first of what will probably be several patches to address the larger issues with $bp_pages. This one (save_pages_to_blog_meta) finishes the work that Andy started in [2978], namely saving WP page info in the blog meta tables rather than sitemeta. I also slipped in a few fixes regarding automatic page creation: in some instances, the pages were being created on the incorrect blog.

It's working as expected on both single WP and MS with BP on blog 1. I've tried to test against BP_ROOT_BLOG != 1, but secondary BP blogs appear to be altogether broken on the trunk at the moment. Still, this patch does fix the problem described in #2456 (ie it makes sure that $bp->members->slug gets activated when BP exists on a secondary blog).

Please test away and help me think through how this WP page business should be handled.

#3 @paulhastings0
14 years ago

  • Summary changed from At setup: Selecting existing WP pages to serve as BP pages doesn't work to [patch] At setup: Selecting existing WP pages to serve as BP pages doesn't work

#4 @DJPaul
14 years ago

This is a super patch and initial testing shows it removes some of the most immediate problems that trunk currently has on multisite. Before we commit, with regards to the IF statements:

if ( defined( 'BP_ENABLE_MULTIBLOG' ) && is_multisite() ) 
else if ( is_multisite() ) 


if ( defined( 'BP_ENABLE_MULTIBLOG' ) )
else if ( BP_ROOT_BLOG != $current_blog->blog_id )

It is possible I am misreading, but I think these can be the same. I believe the first style to be more appropriate?

#5 @boonebgorges
14 years ago

My initial logic is actually wrong here; generally you want to save those options to the current blog. Please see the patch to #2732, which combines this patch with another related fix. It might be the case that I have oversimplified the logic a bit, as I'm not certain what will happen in the rare case where you try to install BP from the dashboard of a blog other than BP_ROOT_BLOG.

#6 @boonebgorges
14 years ago

(In [3463]) Adds Upgrade routine for WP MS activation. Fixes #2732. Moves site options loading functions to ensure that they're loaded at activation. Fixes #2717, props DJPaul. Modifies the way that bp-pages data is stored in and fetched from options tables on multisite. References #2518. The only thing this patch does not do is bake pie.

#7 @boonebgorges
14 years ago

I just ran some tests on the latest trunk and it appears that everything mentioned in this ticket (in particular step 1, which was the outstanding issue) seems to be working properly. Selecting existing pages at setup time does indeed work correctly, and render properly in the navigation tabs.

#8 @boonebgorges
14 years ago

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.