Forum Replies Created
-
I actually don’t see a home option in my DB, but there IS a siteurl option. Even though get_option(‘siteurl’) didn’t work for me either. I have a feeling it’s got something to do with how the databases in WP MU don’t match with those in WP and the get_option function is structured in a way that makes sense for the WP databased, but not those in WP MU.
A quick fix would be to do an <?php echo site_url();?>
Ah I figured it out! Textbook case of failure to RTFM. I uploaded member-themes into the themes directory instead of the wp-content directory.
Well, at least I learned a little bit more about how buddypress works through the wonderful invention that is var_dump!
Hmm I have that already. I’ve been trying to figure it out and all that’s turned up so far is my firebug is reporting any component page with a 302 header (Moved Temporarily). I didn’t change my .htaccess file prior upgrading to the latest revision (which only involved file movements. Unless there’s some upgrade process that I’m unaware of).
Very weird.
Hey Andy, thanks for the great work, I just checked out r571 and merged the necessary differences. Now it seems that any member page gets rewritten to index.php!
Sorry to hijack this thread, but I’ve been wanting to change the groups URIs, and ok, so I know that groups is hardcoded in.
But I tinkered around with it and basically created a GROUP_SLUG and set that, in my case, to “projects”. Everything works fine (I had to change a few template things but otherwise it’s ok) except I have a teensy weensy problem with the catchuri function
So now all my pages are something like siteurl.com/members/username/projects/action
(siteurl.com/members/username/projects/, siteurl.com/members/username/projects/my-groups, siteurl.com/members/username/projects/group-finder. You get the idea)
And it works fine until I create a wordpress page called projects, then for some reason siteurl.com/members/username/projects rewrites to siteurl.com/projects, which in my case would be the wordpress page instead of the groups memberpage. I’ve tried taking a look at catchuri, and playing around with the is_page function, but even if I try to name the page something else, like say “projects main”, it still ends up trying to add the template into the page, which naturally fails and ends up with the 404 template.
I also don’t know if it’s related, but my wordpress mu is in a subdirectory, which looking at the catchuri code, doesnt seem to deal with subdirectories at the first explosion of the uri to rewrite (but I may be mistaken), so before the explosion of the actual site_uri function, $bp_uri[component_index] ($bp_uri[0]) actually returns me the subdirectory that my wp mu is in. I’m not sure if this is a bug and/or if it affects muy uri rewriting, but I thought I’d mention it.
p.s. when I delete the projects page, members/username/projects rightfully shows me the my-group template.
you can take a look at it here http://donicethings.org/beta
If anyone could help me I’d be most grateful, thanks!
Great! Thanks for the help. In the end I just uploaded a nontranslated english MO file to the languages folder. Though it doesn’t really make sense for me to update both the WP MU and BuddyPress languages together.
I mean I suppose it’s useful for people who actually want to do translations, but shouldn’t there be a separate function for buddypress altogether (that perhaps is linked to WP MU?)
Oops, that’s what I meant. Mistyped sorry.
Still nada: http://donicethings.org/beta/wp-content/mu-plugins/bp-languages/buddypress-en_US.mo
At http://donicethings.org/beta, groups is supposed to translated to “projects”.
Apologies for hijacking the thread, but it seems like even with my file in the wp-content/plugins/bp-languages folder, it still doesn’t seem to work.
My file is called en_US.mo cause I need to change a few words in buddypress (but not in WP Mu), but I didn’t change the WPLANG constant (though I’ve tried, not that it makes any sense changing it). Is that causing the non-translating-dom?
Many thanks!
