Request method of wp setting and option api - wordpress

Question

I am building a plugin. For rendering the menu page both Option API & Setting API are used. Below is my callback function for add_menu_page()
<?php
//Calback function for add menu page
function render_newsletter_admin() {
if(!current_user_can( 'manage_options' )){
return;
}
if($_SERVER["REQUEST_METHOD"]=="GET"){
add_settings_error( 'newsletter', 'newsletter', __( 'Settings Saved', 'victory' ), 'success' );
settings_errors( );
}
?>
<div class="wrap">
<form action="options.php" method="post">
<?php
// output security fields for the registered setting "wporg"
settings_fields( 'newsletter' );
// output setting sections and their fields
// (sections are registered for "wporg", each field is registered to a specific section)
do_settings_sections( 'newsletter' );
// output save settings button
submit_button( 'Save Settings' );
?>
</form>
</div>
<?php
}
Notice that method attribute of the form set to POST but to add setting error $_SERVER["REQUEST_METHOD"]=="GET" is being checked and it is working. Shouldn't it be checked against POST?

Answer 1

Shouldn't it be checked against POST?
It's checked against GET instead of POST because the form is being submitted to and handled by options.php (or more precisely, wp-admin/options.php), and after the submission is processed, WordPress will redirect the user back to the origin of the submission which is the menu page having that form. Therefore the request method would then be GET.
Illustration of how the request method changed (from GET to POST then back to GET)
User landed on the menu page (the request method is GET).
Then he/she submitted the form.
The browser submits the form to options.php, using the POST method.
Now on the options.php page, the request method is POST.
And after the form submission is processed, WordPress sends the user back to the menu/form page.
Now on the menu page, the request method is GET because the above redirect uses that method.
Relevant code in wp-admin/options.php
So at the top in wp-admin/options.php, it says...
/**
* Options Management Administration Screen.
*
* If accessed directly in a browser this page shows a list of all saved options
* along with editable fields for their values. Serialized data is not supported
* and there is no way to remove options via this page. It is not linked to from
* anywhere else in the admin.
*
* This file is also the target of the forms in core and custom options pages
* that use the Settings API. In this case it saves the new option values
* and returns the user to their page of origin.
*
* #package WordPress
* #subpackage Administration
*/
And on lines 339-341 (https://core.trac.wordpress.org/browser/tags/5.8/src/wp-admin/options.php#L339):
// Redirect back to the settings page that was submitted.
$goback = add_query_arg( 'settings-updated', 'true', wp_get_referer() );
wp_redirect( $goback );
And if you look at the "complete example" in the plugin developer handbook, it's actually also checking against GET whereby add_settings_error() is called only if $_GET['settings-updated'] is set:
// add error/update messages
// check if the user have submitted the settings
// WordPress will add the "settings-updated" $_GET parameter to the url
if ( isset( $_GET['settings-updated'] ) ) {
// add settings saved message with the class of "updated"
add_settings_error( 'wporg_messages', 'wporg_message', __( 'Settings Saved', 'wporg' ), 'updated' );
}
// show error/update messages
settings_errors( 'wporg_messages' );
Also, you might want to call settings_errors() outside the if (like above), and pass newsletter as the first parameter for the function, i.e. do settings_errors( 'newsletter' ).