Support » Developing with WordPress » Can setting API be used with the Editor Role?

  • Resolved PeoplesGeek

    (@peoplesgeek)


    Hi Team,

    I have developed a plugin for a client and used the Settings API successfully to save some options related to the plugin. Unfortunately, when I developed I did so as an Admin and the user has the role of Editor. Now when the editor attempts to save the settings they get the error:”Cheatin’ uh?
    Sorry, you are not allowed to manage these options.”

    I know the documentation says

    NOTE: When using the Settings API, the form posts to wp-admin/options.php which provides fairly strict capabilities checking. Users will need ‘manage_options’ capability (and in MultiSite will have to be a Super Admin) to submit the form.

    So I suppose this is expected and it is resolved by temporarily giving the editor role the ‘manage_options’ capability but that has other undesired implications as they now see and access more than they should as an editor.

    I have googled and researched but can’t find if there is a way of still using the Settings API and all its goodness – but allow my settings page to be used by a non-admin role.
    I can go and recode the form the ‘old fashioned’ way with NOONCE and all the other steps that the settings API takes care of but I really hope there is a more elegant and future-proof way.

    What I am looking for (if it exists) is pointers to using the Settings API with a standard Editor role. I know how to do it without the Settings API if that is the only option.

    Many thanks and fingers crossed,

    Brian (PeoplesGeek)

    The page I need help with: [log in to see the link]

Viewing 3 replies - 1 through 3 (of 3 total)
  • Moderator bcworkz

    (@bcworkz)

    It’s possible! Use the dynamic filter “option_page_capability_{$option_page}” and return a capability the Editor has. The $option_page portion of the dynamic hook is the same as the option group argument you pass in settings_fields() and do_settings_sections().

    That is brilliant @bcworkz !

    Thank you for the suggestion – It is a matter of knowing where to look and once you see it then it is obvious.

    This has worked perfectly and the client is happy (and just as important – so am I)
    The only thing I had to change was that the {$option_page} part of the filter I had to use was the one from the register_setting() rather than settings_fields() but this may just be my setup and I will review it again (the option_group, option_name, id, page, and section interactions can do your head in a bit!).

    I really appreciate you pointing me in the right direction with the exact reference in the core code via trac,

    Brian (@PeoplesGeek)

    Moderator bcworkz

    (@bcworkz)

    Yeah, the various IDs in the settings API are confusing. I’m not sure where the dynamic variable actually comes from, I only noticed that it matched the one used in settings_fields() call in the example I used in my investigation. It seems anything else would be a mere coincidence as all other IDs on the form could have multiple values to choose from. The settings fields call is the only thing that always occurs only once. But where the settings fields argument should come from is where things get murky.

    Anyway, I’m glad you found an ID that works!

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.