New feature - Allow to choose what to display by default on User Profile

businessdad

I've been working on a "Dashboard" plugin that will present User with a summary of their activity at a glance, as well as showing separate lists for Discussions, Questions, Comments and Answers (I attached a screenshot to give an idea of the result).

The issue I'm facing now is that, when the User open his profile, he gets directed straight to the "Notifications" tab, which is not ideal, as I'd like the Summary to be displayed first (it will contain notifications too, eventually).

I did some research, and I found out that this behaviour is hard-coded into the ProfileController, in method Index(). The method description states clearly " If current user's profile, get notifications. Otherwise show their activity (if available) or discussions.", and the code reflects this.

My workaround, right now, is to put Notifications as the first tab, so that it looks like I deliberately chose to sent the User there by default. My client explicitly asked to have the Summary as the default page, therefore I'll have to do some "convincing work" here.

A possible solution
- Add a "User Profile Default Page", as a simple textbox where the Admin can enter the path. The drawback is that it may not work very well with paths such as "/discussions", which require additional parameters at the end.
- In Profile->Index(), check if there's a User Profile Default Page configured. If there is, show it. If not, follow current logic.

The above is still an initial idea and it might require more work than I thought, but I think it could be worth looking at it in more detail.

422

Aww man that is nice !!!!!! , very stackoverflowy !

businessdad

Did I actually attach the screenshot? I can't see it...

422

Shows for me on ipad

businessdad

That's weird, I don't see it in both Chrome and Firefox... Also, I don't seem to be able to add a signature to my profile. I'll have to check if I set something wrong.

422

Ask underdog to join developer group.

UnderDog

sorry, my mistake.

Lincoln

@businessdad You can overwrite the entire method using ProfileController_Index_Create in your theme hooks or a plugin.

businessdad

@Lincoln Really? I thought I can't redeclare a method that already exists. I tried already, but I got an error.

mcu_hq

businessdad said: @Lincoln Really? I thought I can't redeclare a method that already exists. I tried already, but I got an error.

Clear your cache.

Also this looks really interesting. I ditto what 422 said.

peregrine

can you put the line of the function you are using to create. if the cache clearing doesn't work.

e.g. public ....

businessdad

mcu_hq said:

businessdad said: @Lincoln Really? I thought I can't redeclare a method that already exists. I tried already, but I got an error.

Clear your cache.

@mcu_hq Maybe it's another of silly questions, but what cache are you talking about? I don't see a cache setting in Vanilla.

Sheila

I think he means /cache/ -folder and .ini -files within.

businessdad

Sheila said: I think he means /cache/ -folder and .ini -files within.

@sheila Ok, got it. Anyway, nothing changes. As I was told, I can't simply redeclare an existing Controller method, the error is still the same: New object methods must be unique. The new "profilecontroller_discussions_create" method has already been assigned by the "VanillaHooks.profilecontroller_discussions_create" plugin. It cannot also be assigned by the "UserStatsPlugin" plugin.

@peregrine Here's how I declared the "override" that generates the error above:
public function ProfileController_Discussions_Create(&$Sender) {...}

Todd already gave an answer to this issue, in the thread I linked to in my previous post:

We don't really allow redeclares like that right now. Doing what you did is a good idea and you could complete the whole thing by also adding a route that maps /profile/discussions to your new method.

Therefore, I think I can't do what Lincoln suggested, unless I use the Routes (which could also be a solution, although not optimal).

Lincoln

You can't do ProfileController_Discussions_Create because it's already declared in Vanilla's hooks file, as the error notes. Vanilla app is already overloading the Dashboard app's ProfileController class, and you can't overwrite an overloaded method, that's true.

ProfileController_Index_Create isn't declared anywhere because ProfileController->Index() is a native method in the class. You may overwrite a native method in any class that inherits from Gdn_Pluggable. All controllers and models do so.

businessdad

@Lincoln If I understood correctly, then, it means that native methods can be overridden only once, correct? That is, if I override it in my plugin, no other plugin will be able to do the same.

Lincoln

@businessdad That is correct. Vanilla doesn't prioritize or order things like overwrites or hook calls, so 2 overwrites would leave it confounded with how to resolve it.

Because of that, it's not a strategy I'd employ for plugins I'm planning to open source, but in a special needs case for an internal project, overwrite away.

businessdad

@Lincoln That's for the clarification. I actually would like to make my plugin available publicly, that's why I'm not sure overriding a method the way you described would be the best way. After all, if anyone else would do the same, there would be a crash or, worse, unpredictable behaviour. If there was an "unlimited" override/hook system, that could (almost) do the trick, but, for now, I'd say I can stick to what I have and avoid hacking more than needed.

Besides, my plugin already requires some manual modifications to the configuration file, I don't want to make installation any more complicated. :)

Thanks for your help.

Lincoln

There's no reason to manually alter the configuration file. Use SaveToConfig('Three.Part.Name', $Value);

businessdad

Lincoln said: There's no reason to manually alter the configuration file. Use SaveToConfig('Three.Part.Name', $Value);

That's funny. I know about SaveToConfig, and I use it all the time. However, when I tried the first time to save an array as the value of a parameter, it wasn't interpreted properly and it didn't work as I expected. Before replying to your post, I decided to try again, and, in fact, it works.

The "manual change" was a temporary solution because SaveToConfig didn't seem to work properly in such case, but, as it seems, I might have done it wrong the first time. Even better, no more manual modifications required. :)