What version are you using and what’s the error message you’re seeing?
1.6.3, “Cannot load wp-rest-api-log-settings.”
Was there a specific tab you saved that broke the navigation? I’m not able to replicate the issue so far.
The error message is being generated by WordPress itself vs the plugin, inside the admin.php file.
if ( !( file_exists(WP_PLUGIN_DIR . "/$plugin_page") && is_file(WP_PLUGIN_DIR . "/$plugin_page") ) && !( file_exists(WPMU_PLUGIN_DIR . "/$plugin_page") && is_file(WPMU_PLUGIN_DIR . "/$plugin_page") ) )
wp_die(sprintf(__('Cannot load %s.'), htmlentities($plugin_page)));
It’s almost as if the plugin file is no longer there, but that doesn’t seem correct.
It’s because after saving, the browser is then on options.php, not options-general.php as before. Does that not happen for you?
I saved on the default tab, then tried to navigate to the next tab.
Not happening here (nginx, single vanilla WordPress site). The settings form does a POST to options.php, then it should to a 302 redirect back to /wp-admin/options-general.php?page=wp-rest-api-log-settings&settings-updated=true
I should be able to fix this however. The code that generates the href for the tabs outputs something like this:
href="?page=wp-rest-api-log-settings&tab=wp-rest-api-log-settings-general"
I can update this to use admin_url() with options-general.php instead of just the query string. Should have an update sent out shortly.
then it should to a 302 redirect back to /wp-admin/options-general.php?page=wp-rest-api-log-settings&settings-updated=true
According to the quote of the relevant RFC in https://core.trac.wordpress.org/ticket/14062 (“some Location headers are using relative url’s [sic]”), outputing Location: headers with relative URLs, instead of absolute ones, is a bug.
Yes, it seems that if you use a full URL than that’ll work around the bug (which is in WP core??).
1.6.4 has been pushed out to the repo and should resolve the issue you’re seeing.
