Complete Guide to integration with the graphical environment of WordPress (Part IV )

This article is the fourth part of the series on plugins development and themes with the focus on integration with the native environment of the WordPress administration, the use of graphical components such as broken parts, tables, frames and other native CSS, including API settings, among other tools that Word Press already offers. Review Part I, Part II and Part III of this series.
After discussed how to use different types of UI elements on our website, we will learn in this part using the WordPress options API to write our drivers in the pages of the Word Press options, from simply creating a new driver on a page existing to the creation of new sections to accommodate our controllers in new custom pages.

In the last article we created several elements within our options page. Let us first learn how to create and add a controller with the API to one of the options WordPress pages taking that file and creating new functions. Already then we will modify the content of our website to also use the API options. Let’s start by picking up this file, we start then?
An API is an interface that can communicate with particular application in the case of WordPress there are several API to access or write content, assign new tasks and functions, etc. The options API is an interface that allows a developer to create more inputs within the pages of options for controlling the application of new features that certain plugins can make to WordPress.
This API is a combination of features that simplifies the process of creating, sanitation, cleanliness, rescue and control of new data by the users, making it safe for the system.
Before we start to use we have to understand why it is important to use this API options. Here are some suggestions:
Communicates directly with the core of WordPress and allows you to quickly have access to data without much effort. The options created through the API will not break in future versions, objecting to the fact that if we create the options on our website without the API cannot guarantee that   When data rescue run multiple processes and sanitation and data verification functions that are not stored malicious data in the database. It is faster to create and modify options
There are many benefits in using the API options, just do a Google search and look at several articles on the subject. Unfortunately, as almost always, some developers, especially the plugins or paid themes your settings pages do not use this API, but this trend is changing and begins to emerge the general idea that actually the WordPress API is much more reliable than otherwise that programmers can get outside the “official” WordPress, created by the developers.


As explained at the beginning, let’s first see how simple it is to create a field on the general WordPress options. To do this we open our file and at the top enter the following code:
// Create a field in general WordPress options page
add_action ( ‘admin_init’ ‘test_ui_general_options_input’);
test_ui_general_options_input function () {
    // For convenience store some values in this array
    // To be only need to change the data in one place
    $ Args = array (
        ‘Id’ => ‘id-of-option’
        ‘Name’ => our_opaque’
    // We note the option so that WordPress can automatically store it in wp_options table
    // The first parameter must be equal to the settings_field () function used on the page where
    // If you want the option to appear. The second parameter is the name we want to save the option and
    // The third is the function name to be called to test our values: it can be any function
    // That returns a value, for example intval () to validate only integers.
    register_setting ( ‘general’, args $ [ ‘name’], ‘test_ui_validates_opaque);
    // Tells WordPress where to get the option, which show where.
    add_settings_field ( ‘id-of-option’, ‘This is the title of option’, ‘test_ui_content_Gives_opaque’, ‘general’, ‘default’, args $);
test_ui_content_da_opaque function ($ args) {
    // Search the saved option in wp_options table and print our first input
    Data_do_bd get_Option $ = ( “our_opaque ‘);
    <Input id = “<? Php echo $ args [ ‘id’];?>” Name = “<? Php echo $ args [ ‘name’];?>” Type = “text” value = “<? Php echo? $ data_do_bd?> “class =” regular-text “/>
    <? Php
function test_ui_validates_opaque ($ value) {
    // Let’s remove all HTML characters
    // Script, etc., so that we can keep
    // This data certainly in the database.
    return strip_tags ($ value);
If you put this code in our plug-in ‘ll see an option on the General Options WordPress equal to that found in the image. You can test to see if the option is saved or not, and if the function returns a correct value. You can (and should ) implement a Unit test for each of the verification functions if they are complex . I will talk in the next article, out of this series on how to implement Unit testing our plugins and themes in WordPress by PHP Unit framework and some plugins that help in the process.
integration with the graphical environment of WordPress (Part IV )
This code is very simple and essentially presents two new functions that belong to the WordPress options API: register_setting and add_settings_field . These functions do just that , ask the WordPress ( gently ) to save the new custom option whenever requested and show the interface for this . It’s simple is not it?
For reference , here are the values that can be used in the first parameter of the function register_setting according to pages where options is expected that the option is saved :
    General Options , ” General “
    Writing : “writing”
    Reading: ” reading”
    Media : “media “
    Discussion ” discussion”
    Privacy : “privacy “
    Permanent link : ” permalink “
In add_settings_field function, the penultimate parameter is usually “default” , and corresponds to the page where we want to put our field, however there are some pages that have more than one section . As a reference I leave here a few more combinations that can be used :
    “Writing” , “default”
    “Writing” , ” post_via_email “
    “Writing” , ” remote_publishing “
    “Media” , “default”
    “Media” , ” embeds “
    “Media” , ” uploads “
    “Discussion ” , “default”
    “Discussion ” , ” avatar”
permalinks :
    ” Permalink ” , ” optional “

Note: Permanent Links page only has a section for you to use what is called “optional”.

These are two fundamental functions in this field of construction process for WordPress. Our code is much cleaner, and if one day the WordPress change the implementation strategy of option fields, there will be problems to be some breaks in the code.
Imagine you want to create multiple fields within a page but want to group them in order not to mix with each other. As we saw earlier, this is possible through sections, but are not restricted only to the sections that WordPress gives us, we can also create our sections very simply, just by making some changes and include add_settings_section function in our code. We will then include the following line in test_ui_general_options_input function after register_setting and before add_settings_field:
// Tells WordPress to register a new section on page
add_settings_section ( ‘ our – section’ , ‘ New custom section ‘, ‘ test_ui_content_section ‘, ‘ general’ ) ;
This function accepts an ID in the first parameter to be used in add_settings_field function, a title , the function name that will put content to add the section header and the page ID where the section should appear. Then we should change the ID section of the add_settings_section function to the new section ID , then passing to our default – section:
// Tells WordPress where to get the option , which show where.
add_settings_field ( ‘id – of – option ‘, ‘This is the title of option ‘, ‘ test_ui_content_gives_opaque ‘, ‘ general’ , ‘ our – section’ , $ args) ;
And the result recharge WordPress will be :

Info about integration with the graphical environment of WordPress (Part IV )
You can create more fields replicating register_setting functions and add_settings_filed changing the variable values obviously. There is no theoretical limit to this process, which should always be the same.
Now coming to the final stretch of our article today , we will implement the solution options API on our website we had created earlier. To do this we keep our code we just create and expand to adapt our website. It is quite simple to just use two functions : settings_fields and do_settings_sections .
// This function is the display of the page content
// We have changed this to use the API WordPress Options
test_ui_submenu_page_callback function () {
<Div class = “wrap”>
    <? Php screen_icon (); ?>
        UI Test Plugin
    </ H2>
    <! – The body of the page is here ->
    <! – We have created a form pointing to the options.php page ->
    <Form id = “form” action = “options.php” method = “post”>
        // Entire interior of the form has been deleted so
        // That we can process each field through the Options API.
        // This function builds an array with the fields that will be
        // Displayed here.
        // The argument is any ID you can choose to
        // Use the register_setting functions, and add_settings_field
        // Do_settings_sections.
        <? Php settings_fields ( ‘our-fields’); ?>
        // This function renders the table sections and each field.
        // Does all the work for us without having to use HTML
        // Beyond the input fields.
        <? Php do_settings_sections ( ‘our-fields’); ?>
        <? Php submit_button (); ?>
    </ Form>
</ Div>
    <? Php

Here is the code of our new page that will use the API WordPress options. Note that the ID placed within settings_fields and do_settings_sections functions and see that indeed these functions share the same ID. This will also be used in register_setting functions and add_settings_page in place of the page parameter (currently general) .
For this we have to eliminate the line:
// Create a field in general WordPress options page
add_action ( ‘ admin_init ‘ ‘ test_ui_general_options_input ‘);
and modify as follows , so that the function that records our fields and sections is only called during the loading of our page :
test_ui_submenu_page function () {
    // Add a submenu to the page of the plugin where we make drivers
    $ Page = add_submenu_page ( ‘ options- general.php ‘ , __ ( ‘ Test UI ‘, ‘ plug -test- ui ‘ ) , __ ( ‘ UI Test ‘ plugin -test- ui ‘ ) , ‘ manage_options ‘ ‘ plugin -test- ui ‘,’ test_ui_submenu_page_callback ‘);
    // Let’s move to call the function that records the fields and sections of our
    // Page only when it is loaded or when we keep the data through
    // Options.php the page instead of using the call to admin_init
    add_action ( “load – options.php ” ‘ test_ui_general_options_input ‘);
    add_action ( “load – { $ page} ” ‘ test_ui_general_options_input ‘);
Also continue to be possible we use the call admin_init , however good practice recommends us not to carry unnecessary code . In this way we can get a much more reliable source and that does not compromise other plugins.
Finally you need to change the ID of register_setting functions add_settings_section and add_settings_field (remember the ID that we put up on our website ? ) Within the test_ui_general_options_input function:
register_setting ( ‘ our – fields’ , $ args [ ‘ name’] , ‘ test_ui_validates_opaque ‘);
// Tells WordPress to register a new section on page
add_settings_section ( ‘ our – section’ , ‘ New custom section ‘, ‘ test_ui_content_section ‘, ‘ our – field <strong > s < / strong >’);
// Tells WordPress where to get the option , which show where.
add_settings_field ( ‘id – of – option ‘, ‘This is the title of option ‘, ‘ test_ui_content_gives_opaque ‘, ‘ our – fields ‘, ‘ our – section’ , $ args) ;
Notice that only changed the general page for our ID – fields. Remember that this ID can be anything (provided it does not conflict with existing IDs and mansion data above) but has to be the same ID in all the functions.
Now to address the options page that implemented, the result will look like this :
integration with the graphical environment of WordPress (Part IV )
It is also very simple to add error messages on the pages of the WordPress options , including our own, just for this we use the add_settings_error function during the validation function of each field. To see this in action , let’s give some context to our form, changing the label of our field to prompt the user to input an email:
add_settings_field ( ‘id – of – option ‘, ‘ Enter an email ‘, ‘ test_ui_content_gives_opaque ‘, ‘ our – fields ‘, ‘ our – section’ , $ args) ;
Now let’s change the validation function to check include the following :
function test_ui_validates_opaque ( $ value ) {
    // Let’s analyze if the user introduces a valid email.
    // To use this function WordPress is_email ( )
    // If no email we return an empty value and switch- error
    if (! is_email ( $ value ) )
        add_settings_error return ( ‘ erro_1 ‘, ‘ id- of – error ‘, ‘ This is not an email! ‘ , ‘error’ ) ;
    return $ value ;
By adding add_settings_error function is necessary to pass as a parameter a name and arbitrary ID to associate this error, as well as a message to show in the third parameter and finally if it is an error or an update message , and the possible error values and updated .
Complete Guide to integration with the graphical environment of WordPress (Part IV )
I hope this article has simplified the idea of using the WordPress API options to include both existing pages in camps as well as to create new pages options for your plugins. This is the basic API and there will be much to add beyond techniques and ways to organize data .
Download the code for this article !
Do not forget to follow this series to the next article , the last , where I will show how to use the WordPress tables API for we render a table with connection to external data.


Please enter your comment!
Please enter your name here