User photo controller actions incompatible with front-end forms

[samhernandez]

Description

Regarding these controller actions:

• users/upload-user-photo
• users/delete-user-photo

You can hit them from front-end (non-CP) forms, but they both fail trying to render CP templates.

See:

• https://github.com/craftcms/cms/blob/develop/src/controllers/UsersController.php#L1296
• https://github.com/craftcms/cms/blob/develop/src/controllers/UsersController.php#L1251

This isn't critical because it's possible to save and delete photos with the whole user via the users/save-user controller action.

Additional info

• Craft version: 3.1.15

[brandonkelly]

@andris-sevcenko I’ve added calls to $this->requireCpRequest() for the time being just so it’s clear that the methods are only intended to serve the Control Panel. If you can get those actions to be front-end-friendly, then feel free to remove those lines.

[wouter-vs]

We use these actions in a front-end form. Now it doesn't work anymore because $this->requireCpRequest() was added.
There are workarounds using other actions but I fail to see what the reason was for adding this call? They seem "front-end-friendly" to me.

[samhernandez]

I imagine a front-end-friendly controller would return success or failure in json format. As these controller actions stand at the moment, they throw errors when trying to render a CP template. The image saves before that so it functions, but it's dirty.

[brandonkelly]

@Moskydesign I suppose for this line, you just created your own front-end users/_photo template?

cms/src/controllers/UsersController.php

Line 1253 in 406ad76

$html = $this->getView()->renderTemplate('users/_photo', [

[wouter-vs]

Yes, we do an ajax call and display the returned html after success.

If it would only return success or failure we would have to build the render function our selfs, not that this wouldn't be possible but there happens to be an action specifically for uploading the photo, my understanding was that it was created for this use case.
Other use cases can just use the global 'save' action that doesn't render a template.

[brandonkelly]

@Moskydesign have you customized your copy of the users/_photo template at all, or is it just a direct copy of the built-in one? Thinking one option is we could just force the controller to render the built-in users/_photo template, and remove the requireCpRequest() call.

[wouter-vs]

We have modified it a bit.

Apart from the html we also had to change:
{% set volumeUid = craft.app.projectConfig.get('users.photoVolumeUid') %}
to
{% set volumeUid = craft.app.getSystemSettings.getSetting('users', 'photoVolumeUid') %}

It might not be very front-end friendly but it does provide a lot of flexibility on what you want to display.

[brandonkelly]

Alright, the users/upload-user-photo and users/delete-user-photo actions will once again be accessible from the front end as of the next release. The actions now check if the users/_photo template exists, and if not, defaults to the built-in one.

(By the way, craft.app.getSystemSettings.getSetting() is just a deprecated wrapper for craft.app.projectConfig.get() so I’m guessing you didn’t change that part, but just wrote your template before Craft 3.1 was released. You should update it to use projectConfig.get().)