Upload profile picture/avatar

[alexweissman]

Ref #192.

Right now, V4 supports this on a very basic level with gravatar. Would be good if we could upload an image, perhaps with some client-side sizing/crop tool, as another option.

[abdullahseba]

Definitely. The Default profile picture does injustice to my face.

[lcharette]

I think the avatar system should be organized using "avatar providers". This would allows devs to manage ways an avatar can be defined. For instance a dev could want to remove Gravatar and keep only file upload. So I'm guessing a sub-servicesProvider could work ? Something like $ci->avatar->gravatar ?

We need to take into consideration that a provider should be self contained within a sprinkle, ideally in plug and play fashion. Adding the "Gravatar" sprinkle should automatically add it to the provider list and end user "choose your avatar" form. Some avatar support would still be needed in the Account sprinkle, mainly to call the right avatar provider and to provide a common db column, avatarProvider. Additional info could be managed by a vendor specific table/relation.

To keep existing Gravatar support, a new Gravatar sprinkle should be included in the default UF Install and added to the sprinkle list, to allows a dev to remove such support easily. This would be a new BC.

A default UF install should support:

• Gravatar
• File upload
• Direct link

For file upload, either we store the files in the corresponding sprinkle, or provide a global UF place to store all kind of upload. I think a global storage place would be best for backup purposes. A new default storage manager sprinkle could also be created for that, so the location could be changed to a AWS/GoogleDrive/Dropbox/other vendor if needed.

[abdullahseba]

That sounds good 👍. I think as far as storage goes, it should definitely be outside the sprinkle system with a global directory. There should be a sub directory for each user and maybe move each users temp files over there too. I'm not sure if supporting cloud locations out of the box is a good idea because it could potentially be a high maintenance spot for uf. It would be a nice feature to have in a separate community sprinkle though.

[lcharette]

Cloud storage is supported by Laravel, so if we build it on top of that, we should be fine :D

[abdullahseba]

But we are not using Laravel... Unless it can be broken off like eloquent?

[lcharette]

We are already using Filesystem. See https://laravel.com/docs/5.5/filesystem

And I was thinking about /app/storage or  /app/store as the base location for file storage. Same level as the session, logs and cache (and requires same permissions).

Should it be app/store/{sprinkle}/ to avoid collision? At the same time, Sprinkle A might need to access Sprinkle B files... Note that might seam pointless to do this when we can do  app/sprinkles/{sprinkle}/store, but you have to keep backup in mind

[abdullahseba]

I think we should keep sprinkles out of it and have it based on users. So /app/storage/{user}/

[Silic0nS0ldier]

Should persistent data be kept inside app? The large majority of everything there is application code (fetched and local), cache data, and the odd configuration file. The env file of which isn't even required if environment variables are used.

Or is there some established convention I'm missing here?

[lcharette]

I don't think there's a technical limitation saying we can't put it to the root.

Ping @alexweissman. We need your wisdom

[StrykeSlammerII]

My primary UF project doesn't have inter-user social functions, and in UF4 I simply disabled the Gravatar lookup. Overriding core functions in UF5 isn't quite as easy, so I might be able to put that time into a global solution instead of just fixing my local version. With #869 closed, are there still any design questions that need to be answered here? Are we still looking at one "avatar provider" = one sprinkle?