csmicfool

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.

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

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 pleasure ??

Thanks for the plugin!

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.

I just answered my own question.

Our designers had left some extra line breaks at the end of their functions.php file which got pre-pended on every page within the site.

Here is a good reference explaining the problem (for non-developers):
https://feedvalidator.org/docs/error/WPBlankLine.html

I tried this:

/**
 * Rewriter of URLs, used as replace-callback.
 *
 * Called by #scossdl_off_filter.
 */
function scossdl_off_rewriter($match) {
	global $ossdl_off_blog_url, $ossdl_off_cdn_url, $arr_of_excludes, $arr_of_cnames, $ossdl_https;

	if ( $ossdl_off_cdn_url == '' )
		return $match[0];

	if ( $ossdl_https && substr( $match[0], 0, 5 ) == 'https' )
		return $match[0];

	if ( false == in_array( $ossdl_off_cdn_url, $arr_of_cnames ) )
		$arr_of_cnames[] = $ossdl_off_cdn_url;

	if ( scossdl_off_exclude_match( $match[0], $arr_of_excludes ) ) {
		return $match[0];
	} else {
		$include_dirs = scossdl_off_additional_directories();

		//Removed condition to test case Ben described
		$offset = scossdl_string_mod($match[1], count($arr_of_cnames));
		return str_replace($ossdl_off_blog_url, $arr_of_cnames[$offset], $match[0]);

		/*if ( preg_match( '/' . $include_dirs . '/', $match[0] ) ) {
			$offset = scossdl_string_mod($match[1], count($arr_of_cnames));
			return str_replace($ossdl_off_blog_url, $arr_of_cnames[$offset], $match[0]);
		} else {
			return $match[0];
		}*/
	}
}

However, this did not affect links generated by the home_url() function.