[buddypress-dev] Profile Data Missing

[Jerome]

Sorry, I realized the Charset is utf-8 already on V0.1.1, sorry for the
incovenience, thanks for the great job!

On Fri, May 16, 2008 at 10:41 AM, Jerome <jeromebeta at gmail.com> wrote:

> 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/20080519/e1c477c0/attachment.htm