@hnla yes, for accessibility reasons it makes sense… re: ie6, i agree. which is why i favor the simplest structure… everything inline and relative. Makes for more consistency cross-browsers and less ie hacks required.
@jmbullis You added add_theme_support( ‘nav-menus’ ); to your theme’s functions.php and wp_nav_menu( ‘sort_column=menu_order&container_class=navigation’ ); to your theme’s header.php?
Actually just saw this: seems pretty easy to implement WP3.0 menus into current WP… well, at least part of WP3.0 menu functionality perhaps. Am testing it now. Will update…
@Paul_Gibbs By the way – since you mentioned that function: Newbie here. Googling now. Is the wp_nav_menu() function something I can simply add to a script/template file and it will display submenus? Thanks much…
Yeah, my sense is that it isn’t calling anything sql/db intensive: just a handful of static links. But because it is a plugin (originally, yes?) maybe there are some performance issues? And/or:
Here is what I think: admin-bar was originally a plug-n-play plugin that didn’t require all the thousands of themes to be reconfigured just to use it so it was decided to make it something that sits on top via absolute positioning — and for fun: can scroll with the page via position:fixed. And so, for proper placement letting most of the page load first before positioning the div offered the best performance?
I agree with you both: my goal was to make it relative and inline for simplicity’s sake — but the opposite is probably true because of this architecture: would be further from default structure and could have some performance issues.
Thanks much hnla. I’ll look into your suggestions in more detail. For the time being I think I may keep edits simple and just change #wp-admin-bar .padder css from position: fixed to position: relative and style accordingly. (#wp-admin-bar would stil be absolutely positioned). I don’t want to add up a can of worms by editing too much. Was wondering if it was more modular than editing functions etc — ie, just dropping in a hook into the header — but perhaps not…
@Arturo Thanks! Blog tracking? Meaning how posts can show up in BP’s activity streams and on profiles etc? And is blog creation in MU = to “network” in WP3.0?
First q: BP on WPMU — the BP member functionality is site-wide and not local to each individual blog?
If so, q 2: would you say that BP on WPMU is much like BP on WP except that members can have their own blog with its own subdomain and other WPMU-specific features like optionally setting their own blog plugins etc?
Q3: BP + WP + “community blogs” plugin (I think it is) is = to or is NOT = to BP on WPMU? I assume not?
Do any of you have more detail about the differences in how BuddyPress works on WP vs on WPMU? (And maybe differences in how BP might work on WP3.0 since that sounds like it will have WPMU-like functionality)?
First q: BP on WPMU — the BP member functionality is site-wide and not local to each individual blog?
If so, q 2: would you say that BP on WPMU is much like BP on WP except that members can have their own blog with its own subdomain and other WPMU-specific features like optionally setting their own blog plugins etc?
If yes, is that kind of functionality not possible with BP-on-WP via it’s own plugins?
Do any of you have more detail about the differences in how BuddyPress works on WP vs WPMU? (And maybe differences in how BP will work with WP3.0 since that sounds like it will have WPMU-like functionality)? Thanks!
