Updating other user's photos

judgej

Should it be possible for an administrator to update the pictures attached to other users accounts? I cannot get it working in 2.0.9 (page not found errors, links to the action not appearing in the menu, files appearing to upload but not actually updating etc.)

Before I raise a bug against this functionality not working, can anyone tell me whether this functionality is supposed to be there? e.g. can an administrator update any user's pictures through the /profile/picture/N page?

ithcy

As admin I can change other users' pictures. There is a problem with the redirect (page not found) after the picture uploads, but when I reload the user's profile page I can see that their picture has been changed.

The problem seems to be in applications/dashboard/controllers/class.profilecontroller.php. It's hard coded to redirect to 'dashboard/profile/XXX' where XXX is the ID of the user you just edited. Of course this page doesn't exist. If it sees that you're coming in from a profile page other than your own it should redirect instead to /(your base url)/profile/XXX/(username).

judgej

I've added some bug information here:

http://github.com/vanillaforums/Garden/issues/issue/520/#comment_417804

It looks to me like this is work-in-progress area, with perhaps minds changed on the URL scheme that is supported. Without knowing how this area is supposed to work, it is very difficult to offer any technical solutions.

judgej

Hehe - just posted the same stuff as you were writing that. In my 2.0.9 install, the UserID is not included in the redirect URL at all. Are you looking at later code than 2.0.9?

As an aside, you say "of course" that page does not exist. Is the only way to find this out, looking at the code in detail? Or is there some way to get a list of all supported URL structures from the application?

ithcy

This is 2.0.9. But I'm probably hitting a different code path than you. I'm exiting that class at line 309 which says Redirect('dashboard/profile/'.$UserReference); But there are other exit points which have slightly different redirects. The code in that file just needs to be cleaned up.

ithcy

I really meant "of course you get a 404".

There's no easy way to tell what URLs will be valid or invalid. This is one of the drawbacks (or sticky parts at least) of MVC architecture, in my opinion. You can't just look at the file structure to guess where to edit. You have to know which methods exist in what controllers, and how the app is glued together. It can be a pain to step into MVC code for the first time.

judgej

Yes, that like works for me if I removed "dashboard/" from it and I am editing my own picture. When updating to someone else's image, the UserReference is added to the URL. However, the page needs the UserReference *and* a name.

Editing user 10's image will redirect to:

http://www.example.com/profile/10

This is a page-not-found. Redirecting to this works:

http://www.example.com/profile/10/foobar-whatever-you-like

That is an error in the receiving controller, I think, because it should not require an optional parameter.

So yeah, a general cleanup is needed in there, because many of the redirect URLs do not match what the controller is expecting.

judgej

Yes, line 309 gets me too. I have changed it to this, which works nicely:

Redirect('profile/'.$UserReference .'/'.Gdn_Format::Url($this->User->Name));

Note the formatted user name is not actually used by the receiving controller, but it does simply need to be there. That is probably more a fault of those controllers than of the format of the URL on line 309.

I think the shear number of these redirects shows that perhaps a single point to create URLs is needed in that controller, a single method that is intelligent enough to go searching for the information it needs to construct the URL and fill in any gaps automatically.

I've worked on other projects where you *never* generate a URL on-the-fly like this. Instead you would pass parameters (including the controller and method names and any additional parameters) to the URL generator, and it would be constructed there. The URL generator would know which parameters go into the path and which are added as GET parameters. If the rules for how that URL was constructed changed, then it would only need to be updated in one place and everywhere that the URL is displayed (which could be in dozens of places in dozens of controllers) would automatically be generating the correct URLs.

judgej

I have fixed most of these problems with a one-liner, ensuring usernames are properly URL-encoded. See bug for details:

https://github.com/vanillaforums/Garden/issues/issue/644

It should also be noted that Gdn_Format::Url() does not "url encode" a string, but rather creates a slug for it. It's okay if the slug is stored and used for future reference, or if it is tagged on the end of a URL for SEO purposes, but it will not never match a valid username if that user contains spaces. So just avoid Gdn_Format::Url() on any part of a URL that is used as a key (e.g. the redirect after a thumbnail has been created), try applying the fix in bug 644, and all the "page not found" errors on the profile page simply disappear!

TiGR

BTW, users can crop image, admin can't.

Linc

@TiGR I've patched this in my unstable branch.