do not have sufficient permissions to modify unregistered settings – MultiSite

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');

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.

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!

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.

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….

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

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:
https://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

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.

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.]

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.

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.

Glad to help! Thanks for your attention.

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?

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

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.