[buddypress-dev] Profile Data Missing

[Jerome]

Andy, may I have a request for the charset of the DB? you said you will use
the constant "utf-8" in the DB scheme to resolve the problem, could you
include this fix in the next version 0.1.x? since it is a kind of "preview
release" for xprofile and private messaging components, it is intended to be
used and tested by the people around the world, thanks!


On Thu, May 15, 2008 at 11:01 PM, Jerome <jeromebeta at gmail.com> wrote:

> thanks! Andy, hope the next build would come out soon.
>
> I changed my wpmu from subdirectories to subdomain mode from now on, I can
> not provide the test information for subdirecotries wpmu anymore.
>
> btw, the links are still messed up on my sudomain wpmu site,
>
>   On Thu, May 15, 2008 at 10:45 PM, Andy Peatling <
> andypeatling at automattic.com> wrote:
>
>> On 15-May-08, at 9:46 AM, Beau Lebens wrote:
>>
>> Isn't one of the restrictions in BP one user = one blog? (if not, it
>>> should be :)
>>>
>>
>> It was, but now it isn't, simply because we want to support existing
>> WordPress MU installations. Here's how it works now:
>>
>> "Multiple blog support: members of your network can now sign up and run
>> more than one blog. Their primary blog is used as their 'home' where they
>> can manage their friends/groups/messages etc (and their profile can be
>> viewed). Other blogs just contain the normal WordPress blogging features.
>> Their home account stays as the first tab in their admin interface and is
>> marked with a user icon."
>>
>>
>> But what you're saying sounds right Jerome. Let's follow it through...
>>>
>>> It looks like the profile page (index.php) uses the_profile_field_value()
>>> to output a value.
>>>
>>> That uses the data stored in a global called $field, which I think is
>>> populated somewhere along the line during a call like this:
>>>
>>> $this->group->fields[$i] = new BP_XProfile_Field(
>>> $this->group->fields[$i]->id, $this->user_id );
>>>
>>> $this->user_id at that point appears to have been populated during the
>>> creation of that object, using a global called $authordata. That appears to
>>> be set via WPMU (not BP), and only ever uses $post->post_author (probably in
>>> this case via setup_postdata() ?).
>>>
>>
>> I believe this needs to be changed for two reasons...
>>
>>  - This method is causing issues with links for categories etc etc as
>> mentioned is some previous messages
>>  - If a blog has other authors, the author of the latest posts on the blog
>> will define which ID is used. That's obviously not going to work.
>>
>> Instead, it needs to fetch and use the user ID for the 'primary_blog' meta
>> setting in the wp_usermeta table for the current blog.
>>
>> There doesn't need to be any major architectural changes to make this
>> happen, it's simply a matter of fetching the user ID and passing it to the
>> right place.
>>
>>
>> It looks like all of this triggered via a single-post query/loop in
>>> bp-xprofile.php::xprofile_profile_template() which theoretically should
>>> allocate the $authordata over to the author of any posts on that blog...
>>>
>>> Which leads me to a question - are there *any* posts on those blogs that
>>> are not showing their profile properly? I haven't done a lick of testing or
>>> even run BP to see this problem in action, but following this thread it
>>> would seem like if there were no posts in a blog yet, then the author would
>>> never get allocated properly (and thus their profile data would not be
>>> loadable).
>>>
>>
>> That's a third reason why the current way isn't going to work. :)
>>
>> Cheers
>> Andy
>>
>> _______________________________________________
>> buddypress-dev mailing list
>> buddypress-dev at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/buddypress-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://comox.textdrive.com/pipermail/buddypress-dev/attachments/20080516/46e21d53/attachment-0001.htm