WordPress.org

Ready to get started?Download WordPress

Forums

Google Language Translator
[resolved] do not have sufficient permissions to modify unregistered settings - MultiSite (20 posts)

  1. csmicfool
    Member
    Posted 1 year ago #

    We are running a MultiSite installation where we have SuperAdmin access and our clients have only Administrator permissions.

    Administrators are able to open the settings page and make edits, but when they click the "Update Option" button they receive the error message "You do not have sufficient permissions to modify unregistered settings for this site."

    I've tried to modify the plugin by switching add_option to register_setting, plus added register_setting for every option name I see applied during a save to no avail.

    Some advice would be most appreciated.

    http://wordpress.org/plugins/google-language-translator/

  2. Rob Myrick
    Member
    Plugin Author

    Posted 1 year ago #

    Hi csmicfool,

    This could be a user capability issue, considering that you are using Multisite. The capabilities of Administrators differ between single site and Multisite WordPress installations.

    In the plugin, around line 91, please find this:

    $my_settings_page = add_options_page('Google Language Translator', 'Google Language Translator', 'manage_options', 'googlelanguagetranslator-menu-options', 'googlelanguagetranslator_menu');

    The 3rd argument (i.e. manage_options), is the minimum requirement needed to access that page, which in Multisite, is likely too low of a capability. So I'm thinking we need to reduce this requirement so that your "Admin" roles are able to access the page.

    Change the "manage_options" argument to "edit_pages" and see if that helps, like this:

    $my_settings_page = add_options_page('Google Language Translator', 'Google Language Translator', 'edit_pages', 'googlelanguagetranslator-menu-options', 'googlelanguagetranslator_menu');

  3. csmicfool
    Member
    Posted 1 year ago #

    rm-

    Thanks for the comments. That would be accurate except that 'manage_options' is the correct role to use in a multisite environment, plus this would result in a different error if that were the problem.

    There are two errors which are relevant in this case:
    1) "You do not have sufficient permissions to access this page"
    2) "You do not have sufficient permissions to modify unregistered settings for this site."

    The second one is what I'm getting. What it means is that the Options API is not being used 100% correctly. I've traced through the code execution when a save is being made and found that the process is not failing when saving using the update_option() calls within the plugin. WordPress actually saves your changes without the need for a save/update handler - anything you post in a registered field will get saved. The problem in the case of this plugin is that none of the settings are registered and they are all being updated outside of the save routine in wp-admin/options.php. All of the update_option calls execute without error (changes are actually saved before the error occurs). The error gets triggered AFTER the plugin has updated the options.

    I was able to make my own workaround by hacking wp-admin/options.php to allow the unregistered settings to be saved specifically when they belong to this plugin. It's not the most complete solution, but it is working for now.

    I had started to completely rewrite the options page for this plugin to make it work well with WPMU but decided it was easier to just add a small hack to the wp-admin/options code.

  4. Rob Myrick
    Member
    Plugin Author

    Posted 1 year ago #

    Thanks csmicfool, it seems we have a registered settings issue. I agree 100% now that I know your error was not a roles/capability issue.

    I would love to use the traditional Settings API to design the plugin, but I didn't think it was possible to design with metaboxes when using the Settings API. If you have a suggestion as to how to design the settings page with a nice, table layout I will re-write the settings to register correctly. There is not much good data on adding metaboxes when being combined with Settings API, because most tutorials are showing a white screen without custom layouts.

    I am also aware there are tons of other themes/plugins out there who do not adhere to settings API. It looks like those days might come to an end soon!

    Thanks for your help here. Please let me know on the above question and I will re-design to make this more flawless.....I have motivation to do this, since I want to release a paid version here in the near future.

    Thanks!

  5. csmicfool
    Member
    Posted 1 year ago #

    rm-

    One of the methods we've had fairly good success with is registering a hidden text input which gets updated on-the-fly via javascript. Basically we take the data from your tabular input and format it as JSON which gets udated in the hidden field. Upon saving, your data is saved in the expected format and you can serialize<->deserialize fairly easily w/ PHP or JS.

  6. Rob Myrick
    Member
    Plugin Author

    Posted 1 year ago #

    My programmer is telling me that we can use add_meta_box with Settings API....what are your thoughts on this? I think it makes sense....

  7. csmicfool
    Member
    Posted 1 year ago #

    I think add_meta_box is more appropriate for custom posts/pages. I've never used it for administrative options.

  8. Rob Myrick
    Member
    Plugin Author

    Posted 1 year ago #

    Hi csmicfool,

    It appears that this github might be a solution to using the Settings API with metaboxes. I'm going to look more into this....maybe it will open up some ideas for you too.

    Stack Exchange link article:
    http://wordpress.stackexchange.com/questions/57092/creating-custom-meta-boxes-on-plugin-option-page

    Github link found in the answer to the above:
    https://github.com/chrisguitarguy/WPSE-Plugins/blob/master/custom-page-meta-box.php

  9. csmicfool
    Member
    Posted 1 year ago #

    I think add_settings_section, add_settings_field, and register_setting are the best route for your plugin. Just my 2 cents - there's more than one way to skin this cat I'm sure.

  10. Rob Myrick
    Member
    Plugin Author

    Posted 1 year ago #

    Hi csmicfool....part of the answer above does have that.....am I right on this? Part of that code is shown below....please correct me if this is something different.

    public static function settings()
        {
            register_setting(
                self::PAGE,
                self::SETTING,
                array(__CLASS__, 'validate')
            );
    
            add_settings_section(
                'default',
                __('A Settings Section', 'wpse57092'),
                '__return_false',
                self::PAGE
            );
    
            add_settings_field(
                'wpse57092-text',
                __('Some Field', 'wpse57092'),
                array(__CLASS__, 'field_cb'),
                self::PAGE,
                'default',
                array('label_for' => self::SETTING)
            );
        }

    [Please post code & markup between backticks or use the code button. Your posted code may now have been permanently damaged by the forum's parser.]

  11. csmicfool
    Member
    Posted 1 year ago #

    Yes, that looks about right - I don't think it needs to be abstracted exactly the same as the example you provided but that function does invoke the correct functions to achieve this.

  12. Rob Myrick
    Member
    Plugin Author

    Posted 1 year ago #

    Ok, sounds great - I will start there....

    I will also attempt to do this in a more textbook Settings API style.
    But either way, I will consider this a much more compliant way of doing things versus the custom coding in the plugin as of now. Thanks for bringing this to my attention.

  13. csmicfool
    Member
    Posted 1 year ago #

    Glad to help! Thanks for your attention.

  14. Rob Myrick
    Member
    Plugin Author

    Posted 11 months ago #

    Hi csmicfool, I just released version 2.4 of the plugin, and I included your nice widget code in it. Thank you for your contribution.

    I also re-built the plugin using registered settings, which I think might solve your issue with error notices in Multisite.

    Can you share your experience with the plugin at this point?

  15. csmicfool
    Member
    Posted 11 months ago #

    Thanks for the update! I should have time to review the changes later this week.

  16. Rob Myrick
    Member
    Plugin Author

    Posted 11 months ago #

    Hi csmicfool, version 2.6 is the most current version at this point. Hopefully you are able to check out the most current version, and it doesn't leave you with an error message.

  17. Rob Myrick
    Member
    Plugin Author

    Posted 11 months ago #

    I'm closing this as resolved...

  18. csmicfool
    Member
    Posted 11 months ago #

    Sorry it took me this long to review the updates, I finally got a few free moments and ran some quick tests. Everything appears to be working as expected.

    Thanks once again!

  19. Rob Myrick
    Member
    Plugin Author

    Posted 11 months ago #

    Hi csmicfool, that's awesome and music to my ears, friend! Thanks! If you have time to go and rate the plugin, please do. Also, more updates to come here soon.

    And big thanks for the widget suggestion - it's now in the plugin in case you didn't notice.

    Thanks!

  20. csmicfool
    Member
    Posted 11 months ago #

    I did notice - You even used the same class name I did ;)

    Ratings coming your way...

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic