Hey there,
since working with authors (= users) often requires to include an image, is there an easy way to configure / add metadata / file blueprint to it?
Adding a files field and setting query: user.images seems doable, even filtering for template profile and forcing this upon upload … but I’d have to rename it inside a hook, right? This would be so much more convenient if the avatar field would link to the avatar’s file blueprint.
I went with adding a files field after all, adjusting options/metadata through it with multiple: false and it’s alright for now.
But … it would be great to habe a hook like 'user.changeAvatar:before/after', maybe that’s something for GitHub / Notion?
It would make more sense if there was a file view for the avatar where this information could be added.
@texnixe
Another thing:
When creating virtual pages via children() method in a model, I want to pass the avatar as cover image for each virtual page. Passing it as Yaml::encode($user->avatar()) does not seem to be working - calling the virtual page‘s $page->cover()->toFile()->url() gives nothing …
… or maybe there‘s a way to pipe user fields through? Like passing the user as content object 
Hm, the question is rather what we have to store to be able to fetch this image. Encoding the complete user avatar is certainly not the way to go and will throw an error, at least when used separately.
I tried with the id:
Data::encode($user->avatar()->id(), 'yaml')
But it doesn’t work if you try to convert that back into a file object.
If you don’t need this to work in the Panel, then storing the URL to the avatar would probably be your better bet.
Or you store the id, but then fetch the file from the user account folder via a custom method.
I went with saving the user ID, then retrieving the $page->user->toUser() and from there it’s easy. It just seems duplicate work mapping all fields manually in the model, and then going all the way for the avatar anyway. I could just as well just add the user and then put its fields in variables inside controller or whatever …
That would make sense, why store redundant information. This would really only make sense if you wanted to update that information also from the virtual pages.
Right, but I allow authors to update their user page, which is their user page
It’s all a consequence of the hybrid nature of user behaving like page but being not
In the frontend or in the Panel? If in the Panel, you might as well just give them access to their user profile instead of updating a virtual page.
I meant their profile …
But if they can update their profile in the Panel, i.e. this thingy here:
Then why the need for the virtual page to update the stuff? I feel I’m missing something here or are a bit slow on the uptake…
I don’t need the virtual page to update anything. The virtual pages are created as children of page authors so people can check out their information …
Second user page means user profile. By updating their profile, the Frontensegeln pages are „updated“ because they are virtual
