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

[boonebgorges]

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 example.com/folks. But what about example.com/folks/boonebgorges? 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.

3)

[DJPaul]

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

[boonebgorges]

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.

[DJPaul]

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() ) 
 ...
else 
 ...

vs.

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

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

[boonebgorges]

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.

[boonebgorges]

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

[boonebgorges]

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.