@hotforwords, auto-upload already exists in W3TC, you need to add the path to the avatars to the custom file list and enable the option. Or better still, use an origin pull CDN so no uploading is necessary.
Frederick I would like to revisit this with BuddyPress as most of the CDN issues have been resolved with your latest updates….
One of the best uses of a CDN for BuddyPress would be to have the Avatars uploaded to the CDN…
When a user uploads an avatar, and the avatar upload path is set to the include path i.e. xxx/wp-content/uploads/avatars, the avatar will appear as a broken link because the file has not been uploaded to the CDN yet…and is pointed to the CDN… so the user cannot edit or see the uploaded picture because BuddyPress is now immediately looking for it on the CDN…and it’s not there yet…
So if the CDN is auto-upload is checked and set to 3600 seconds the avatar will not appear for 1 hour… in the meantime if they go to edit their avatar it will not allow them because it is looking for the graphic on the CDN…
In addition, the graphic will appear as broken until that time…
Am I missing something? This is the way it appears to be working… I just confirmed this again and it is working as I stated above…
I will add this path to the default settings for now you should add wp-content/uploads/avatars to the custom file paths field. And re-export. And also enable auto upload at some reasonable interval.
frederick …. does this mean if i add wp-content/uploads/avatars to custom file paths that i can use w3tc with buddypress and CDN?
and what would be a reasonable interval for the auto upload to change from 3600 seconds?
thanks!
this is very strange why such a popular plugin and NOBODY just says listen w3 cache is NOT compatible with buddypress ….. you can’t use avatars with it because of exactly @pisanojm says above
Frederick for myself and all the other people struggling with implementing your plugin to work with buddypress will you please confirm and let us know when it might be compatible ?
What is not compatible, be specific? Not everything will magically work for the 12000 factorial permutations of plugins that exist and unlimited ways they can be used.
Avatars can work with the CDN as i said above. The default auto-upload interval is fine. Page caching doesn’t work depending on your settings and what it is you want to cache.
I will add this path to the default settings, especifically in the Rejected files textarea:
wp-content/uploads/avatars/*
wp-content/uploads/group-avatars/*
Specify the path of files that should not use the CDN.
This is the way it appears to be working.
On our site, we’re having some difficulty with W3TC and users’ avatars. I effected a hack which seems to have worked, here are the details of the problem and my temporary solution:
The “/files” directory in WP(MU) seems to actually be a rewrite to /wp-content/blogs.dir/[blog-number]/files/. This prevents W3TC from correctly rewriting uploaded files, as it appears to only look for URLs that point to this directory.
My solution was to create a symlink in the root wordpress directory called “files” which links to this folder. Here was the command issued: ln -s ./wp-content/blogs.dir/1/files files
This works, but when new avatars are uploaded, they don’t appear for 60 minutes or until we do a manual refresh. Any suggestions, Frederick?
W3TC supports regular expressions, so things like this will work for that case @mralexweber:
/wp-content/blogs.dir/*/files/
^^^ was really useful once I thought things through.
I made a full post here:
http://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/wp-minify-and-new-version-of-buddypress/#post-90616
but the gist is that if you set your custom file list to contain:
wp-content/uploads/avatars/*bpfull.*
wp-content/uploads/avatars/*bpthumb.*
and you exclude:
/wp-content/uploads/avatars/signups/*
/wp-content/uploads/avatars/*/*x*.*
then you can still use a CDN for your users’ avatars and allow them to use the buddypress cropping tool.
edit: of course you also need to set the autoupload to something sensible – that is just a tradeoff between the time your users will have to wait and the number of times a day you want to run the autoupload script.
edit2: Frederick when you say that w3tc supports regular expressions do you mean that it would be possible to match a filename that ends in dimensions, e.g.:
somefile200x300.jpg
another100x300.jpg
– as you can see I am only matching the x and the . in the filename which isn’t really ideal.
This apparently only works when the uploaded file is too large and needs to be resized.
Is there any way I can add a rule to auto-reject any file in the avatars folder that does not end in either bpfull. or bpthumb. ?
I don’t care if I have to edit the core plugin code – where are these rejections processed and how can I get at it? I’m guessing it isn’t possible to set up the rule via the CDN admin page, and the config file only lets me set up strings as part of cdn.reject.url – I don’t think that a negative lookaround in regex
e.g. ^((?!bpfull).)*$
but I figure if I can get to the part of the code where this happens I’d be able to implement it myself?
Frederick,
Avatars in BuddyPress are saved in one folder that then includes additional folders, marked numerically, for the avatars as they are generated…
Is there a way for me to cache (include) folders named 1-1500 within a single directory and not cache (exclude) 1500 and above OR 1500 to 3000 using regular expressions? This would effectively solve the BuddyPress Avatar/Group-Avatar problem by adding a couple of lines and adjusting them every week or month as needed…
When I say CACHE above… I really meant to use the word CACHE in terms of uploading the avatars to a CDN…
Specify the path in the custom files field on the CDN settings tab and put an asterisk at the end, then export them to the media library
