settings-api

the function do_settings_section($page) generate error “Allowed memory size of … bytes exhausted”

You seem to be creating a recursive loop. In stm_addmenu_auto_delete_event(), you register an admin page via add_menu_page() that has a callback of auto_delete_settings_callback: function stm_addmenu_auto_delete_event() { add_menu_page( ‘Automatic deletion’, ‘Automatic <br/> deletion’, ‘manage_options’, ‘manage-auto-delete-page’, ‘auto_delete_settings_callback’, In new_settings_auto_delete you register a settings field with a callback of auto_delete_settings_callback: function new_settings_auto_delete() { // … add_settings_field( ‘default_auto_delete_field’, ‘By … Read more

How to use register_setting()

The function register one option or a settings group. So yes, you register the group of a section and use all fields inside this group because the group store all settings fields as array in one item. register_setting( ‘_example_plugin_settings’, ‘_example_object_settings’, array( ‘type’ => ‘object’, ‘default’ => array( ‘some_str’ => ‘A’, ‘some_int’ => 3, ), ) … Read more

Settings API not Saving to Database or Display

The issue with the data saving lies in this area of the code (all three similar functions). printf( ‘<textarea name=”%1$s[$2$s]” id=”%3$s” rows=”1″ cols=”30″ class=”code”>%4$s</textarea>’, $args[‘option_name’], $args[‘name’], $args[‘label_for’], $args[‘value’] ); Or more specifically it’s, this part [$2$s], which should be, [%2$s]. I totally get it though, these specifiers can be fiddly and easy to make typos … Read more

Update custom settings field in plugin

Your code is saving the option, but your input field is not actually displaying the option’s value because you’ve used the wrong option name, which is url_field_name and should instead be webhook_url_field_name (the second parameter value for register_setting()). So the correct HTML would be: <!– I wrapped the value attribute for brevity –> <input type=”url” … Read more

+ More