I’m looking for a solution for the following use case:
the user can upload an image which is shown as his avatar
every user has only one image and there is only one image file per user stored on the server
the url of the image is stored in user.profile.avatar_url, no extra query on an image collection should be needed
I think about using the userId as filename. In this case I don’t have to update the user (or any other documents which refers to the user avatar) when the user changes his avatar.
I tried with meteor-uploads and cfs, but I couldn’t force them to use a specific filename and overwrite an existing file.
I’m sure this has been mentioned before in this forum, but you should be aware that there is a proposal to deprecate user.profile. Opinion seems divided, but it does look possible that the behaviour will change, even if it’s not removed entirely.
There are other documents also refering to the user avatar so I can’t store the image data avatar in profile.
In my app I have to publish a lot of ‘posts’ and ‘comments’. To speed this up I decided to put the user name and user avatar urls as nested objects inside the posts and comments.
Thanks for the answers. Gravatar could be an additional possibility but I want to provide a file upload as well.
I finally implemented an upload method which saves the images to the filesystem and validates the image with graphicsmagick after uploading.
Note that if the user registers with a sub-address (e.g. firstname.lastname@example.org), Gravatar isn’t smart enough to find the picture of email@example.com.
I’ve just released a package to correct for that, idorecall:email-normalize. I can proudly say that it’s the best solution I’ve seen so far for this problem, as it supports not just Gmail, but any domain hosted with Google Apps for Work, plus FastMail, Microsoft, Yahoo! and others.
The Meteor Guide’s view on profile is that it shouldn’t be used - and the reasons are clearly given. However, it hasn’t been officially deprecated as of now, so you could use it.
I would argue that it’s probably best to use a separate collection for profile stuff, which at least means that you are completely in control of it.
If you really want to use the profile field, you can still use it - at the end of the day it’s an arbitrary MongoDB property on a user document - even if the nature of this field changes in the future (for example no longer used by Meteor, or not automatically published). However, you will have to be prepared to specifically publish profile if MDG do drop autopublishing it.