Per-user menu customising

[lumpysimon]

It would be great if each user could set their preferred order, rather than it being done by the administrator which affects all users.

For example, I have just built a site for a client with ten custom post types and an editorial team of eight users. A couple of the editors mainly work on 2-3 post types, while others work more often on others, so it would be very useful if each user could move their frequently used post types up to the top of the menu.

I realise this is a fundamental change to how the plugin works (storing the menu order as usermeta rather than in the options table) and it would mean opening up the customisation to lower user levels.

What do you think?

[swissspidy]

Hey Simon

I have been thinking about this for quite a bit. At the beginning using an option seemed the right way to go because you can change the menu for all your users at once.

On the other hand, the benefits of using usermeta far outweigh the downsides:

• No problems with different languages
• Tailored to each user's capabilities and workflow
• Better multisite compatibility (using get_user_option)
• We could fall back to the original site option if there's no userneta yet

Downside:

• You can't edit the menu settings for all users. You would have to clone the user options or something like that.

I'll try to come up with something when I get back to my computer.

[swissspidy]

What needs to happen for this to work:

• [x] Change required capability from manage_options to read or similar.
• [x] Change get_option/update_option calls to get_user_option/update_user_option
• [x] Add a DB upgrade option to remove the old options and move them to the user options.
• [x] Delete all blog and user options on uninstall
• [ ] Admins need an easy way to set the menu globally for all users (clients) (see #26)

[swissspidy]

The DB upgrade is currently only run for admins, and only once (first come, first served). Probably not that big a deal. Adding the user option to every user would be silly, too.

[nineplanets]

I actually like that it changes the menu for everyone at once for what I'm doing right now. I think the ultimate flexibility would be to be able to change it for everyone and then let people check a box on their user profile to customize it for just their login. This way you get the best of both worlds.

Great plugin. Thanks!

[swissspidy]

@nineplanets I try to avoid adding options if possible. Could you tell me more about what you are doing / how you are using the plugin?

[fgilio]

I think there could also be a way for Admins to customize the menus for each user, individually, and then freezing that config for the user. Maybe adding a temporarily edit mode, in which the Admin chooses a profile, edits the menu, saves that config (to that users meta) and then come back to normal mode.

This may be asking for a lot of work, but are just ideas of what it could be made to further improve the plugin.

I understand you're trying to avoid options. But it may be necessary if moving to a more complex and feature loaded plugin is what you want. The focus should be in keeping it low in number, and as clean and unobtrusive as possible, but you are already doing a great job regarding this and in standing against it as much as possible.

[swissspidy]

I think there could also be a way for Admins to customize the menus for each user, individually, and then freezing that config for the user. Maybe adding a temporarily edit mode, in which the Admin chooses a profile, edits the menu, saves that config (to that users meta) and then come back to normal mode.

That sounds like an ideal use case for the User Switching plugin. You could simply switch to a user to change the menu from his point of view. For multiple users you could use the import/export functionality for quick customization.

[fgilio]

I've not tested that plugin yet, I was afraid it could behave weirdly in some scenarios... I should do it. But still think it might be a little bit overkill, is there a reason you need a entire user switch and not just switch the menu?

[swissspidy]

@fgilio There are plenty of reasons, like small usage, unnecessary complexity, plugin compatibility issues and not reinventing the wheel. WordPress checks the menu item capabilities for the logged in user automatically. I would need to copy the complete logic for this to the plugin. That would be overkill.

[lumpysimon]

I agree with not adding options if at all possible. I'm a big fan of providing filters to allow site owners to customise functionality, so in this case you could put a filter on the capability required to manage the menu.

So if I only want editors and above to be able to manage their menu, I'd add a function hooking into that filter that returned edit_others_posts. If I wanted no one but administrators, I would return activate_plugins. The default value would be read, thereby allowing all users to manage their menu.

[swissspidy]

@lumpysimon You're right, such a filter is currently missing. It will be added as soon as I've rewritten some internal JavaScript (again).

[swissspidy]

As 2.0 is getting closer, it's time to think about this again. The current implementation isn't ideal.

I still don't want to add 4 new options to every user on update, so there must be a better way. Current idea:

1. Load menu from old option if available
2. Display warning in the admin menu to say "hey, please re-save your menu just once"

[swissspidy]

Per @nineplanets' comment, maybe we could still add a filter to enable global modification if wanted. Together with the amm_user_can_change_menu filter, you could then globally change the menu for users. This is a different use case than users editing the menu to suit their needs. Should we support both?

[swissspidy]

As per 039e13983b825c1c3b334d0b08d45ce68eaf76d8 it now is as follows:

Menu settings are saved per user and can be exported/imported for others. By using the amm_user_can_change_menu filter one can "lock" the current settings and disallow further edits.

If you don't want per-user menu settings, you can hook into these actions/filters to manually handle saving/retrieving the settings (e.g. by using get_site_option):

• amm_before_menu_update
• amm_before_menu_reset
• amm_menu_data

This may get easier in the future or I may write a little add-on for this, but for now I'll keep it this way.