Legacy avatars sometimes shown after upgrade

[swinton]

After an upgrade (from 1.0.3 to 1.1.1), legacy avatars are sometimes shown for users even after they have uploaded a new avatar.

The order in which avatars are read from the filesystem is unpredictable, since readdir returns files in the order in which they are stored by the filesystem, not necessarily in reverse chronological order, which is the desired functionality.

A cross-platform fix, which still uses readdir, is attached.

Basically we use an array to define the relative priorities of the avatars we wish to fetch:

1. -bpfull / -bpthumb
2. -avatar2 / -avatar1
3. -groupavatar-full / -groupavatar-thumb

We loop over the array of 'avatar suffixes' and break as soon as one is found.

One drawback of this approach is that we may open a dir handle and read from the filesystem up to 3 times, which isn't great.

It would probably be better if the latest avatar was stored as meta data in wp_usermeta, but this fix is provided as a workaround in the meantime...

[DJPaul]

I'm not sure why we even want to be storing old avatar images. There is 'bp_core_avatar_' fields on the usermeta table but I'm not sure if these are old or current. Certainly a usermeta record is the way to go; maybe make this a Wordpress transient?

[apeatling]

Database usage for avatars is deprecated, there is no need to touch the database to fetch an image.

[apeatling]

Fixed in trunk.

[r-a-y]

Just experienced this on a BP setup after upgrading from BP 1.0.3 to BP 1.1.3 to BP 1.2.1.

Swinton is right, the order in which bp_core_fetch_avatar() is unpredictable.

I believe either using Swinton's patch or updating bp_core_delete_existing_avatar() to remove legacy avatars after uploading a new one is the way to go.

[r-a-y]

The other option is to rename all avatar files that have "-avatar1" and "-avatar2" to "-bpthumb" and "-bpfull" respectively.

[johnjamesjacoby]

Fixed in 1.2 branch.