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

This article is the first part of the series on the development of plugins 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 , nonces among other tools that WordPress already offers.




In this first part we will talk about some important assumptions in creating interfaces and creating basic administration pages , integrating just with CSS that promotes UI WordPress . For this we will begin to create a new plugin that will be our way to test the code we will develop .
INTRODUCTION
Complete Guide to integration with the graphical environment of WordPress (Part I)
The evolution of the WordPress admin interface throughout its development has been fantastic in my opinion is a rare phenomenon on many levels when it comes to collaborative development in software. We now have gradually an increasingly clean and accessible interface, and currently WordPress is considered by many as the CMS with the most simple and intuitive administration interface for the user operator, and the tests that have been happening in blog about UI development team demonstrates this idea.
The truth is that this development is continuous and fast evolution has been quite large version to version, it is for this reason and many others it is important to comply with the design standards and intuitiveness already established by the software when you create the interface for your plugin or theme.
In this article we will address a number of reasons for this to happen.
CREATING THE DEVELOPMENT OF PLUGIN
Already here we talked about how to develop a plugin. It’s pretty simple, but I will repeat the steps to the most inattentive readers. 🙂
First, let’s create a new folder inside the wp-content / plugins board / with the name “plugin-test-ui” and then a file within that newly created board with exactly the same name plus the extension php, ie “plugin-test-ui.php.” Then open the file for editing and add the following text, also called plugin header:
<?php
/*
Plugin Name: WP Test UI
Version: 1.0
Author: Online Seva WP
Author URI: http://www.online-seva.com/
*/
At this time already have created your plugin and you can go to the plugin admin area to activate it, however it is still not functional because it has no code inside. We will however leave it enabled as we add gradually the code.
USER EXPERIENCE
This is also known as UX, English user experience, and is one of the features that the development team of the WordPress admin has more concerned: keeping the user experience consistent across the board. It is too dim when a user installs a plugin in WordPress and realizes that its interface has nothing to do with what is used. Maintaining a consistent interface is important to keep users: believe, there are few users who stop using certain plugins because they simply “are not beautiful.”
KEEP UPDATED ALWAYS
The system updates WordPress is quite simple. The largest changes occur in the updates, that is, the increment of the first two digits version, while the smaller versions only fix bugs, and there may be an infinite number of these. For example, the next version change, from 3.4 to 3.5, will bring new APIs and an improved interface, however version 3.4.3 (which can probably leave before 3.5) will only fix bugs found in previous versions of WordPress .
That said, keep the updated plugin and work correctly in all future versions is necessary and important and one way to not to worry about the interface and using the native elements, because as WordPress will update its interface, it It will always be consistent with the versions of our plugin.




REDUCE PLUGIN FOOTPRINT IN INTERFACE
This is a very debatable issue, but too important to be left out. There is the idea of the developers of the plugin we create is more important than the WordPress itself, and this is natural because who does not respect your creations? I also pasei through this phase when only program plugins, however, work and contribute to the core gave me a different perception of what should be a plugin. I list some of my findings:
A plugin should serve only one purpose and not one of them date;
Only serves to extend functionality and not to re-create them (that’s why there are action hooks WordPress, if there is none that can help you, ask for one!);
It should not be difficult installation;
You should not create too many options for the user, especially if they require technical level.
Good example: P2P scribu – is a complex but with only one purpose plugin: allow connecting various posts and users to each other only through certain areavés parameter WP_Query, that is intended for people who know how to program in PHP.
Bad Example: W3 Total Cache – the purpose is to cache, but also serves to integrate the S3 or other CDN, compresses HTML, minifica javascript and CSS, automatically imports attachments of posts for the library and only lacks make coffee to be full … in my view totally unnecessary, and this should have been separated into small plugins each with a purpose only.
Complete Guide to integration with the graphical environment of WordPress (Part I)
This question is very important to answer coherently: “You need my plugin have a menu or a particular submenu?” “I can use one of the existing submenus to put options there?”. As mentioned earlier, it is too important to reduce the “graphical footprint” of your plugin so that you feel comfortable. There are plugins whose need is to have only one or two controllers (checkboxes, input boxes, etc.), you even need to create a new page in the administration to present these two drivers? There can they go to the page of general options?
As examples we can think of two hypothetical plugins: one manages and integrates all your social media accounts and therefore requires at least one input box to identify each account. It makes sense in this case create a new page called, for example, “Social Networks” and then provide your controllers. Another example is a plugin that turns the native WordPress Gallery in a slideshow on jQuery and you need a few drivers to modify the appearance of the slideshow. In this case, it makes sense to put these controllers on page “Media Options”.
An exception may be a plugin that provides a tool to WordPress. Tool here is something that runs in the administration as a SEO analyzer or a regenerator of thumbnails. When we are faced with such a case, this plugin shall create a sub-page on the Tools menu.
Complete Guide to integration with the graphical environment of WordPress (Part I)
A good example of a plugin that does not require settings because it already has a well-defined purpose is my plugin “Hide Comments Feature” which simply removes the WordPress comment system so on. It’s simple, direct, effective and does not require any configuration.
In my view I do not see any reason for a plugin to create a new top menu to accommodate on multiple pages to its functionality. One of the plugins I appreciate most in terms of SEO is WordPress SEO Yoast de Valk, it is useful and its features are miraculous, but he misses throughout the building that makes its interface. The plugin creates a new root structure just to accommodate several subpages with a mountain settings each, many of them repeated and unnecessary. The most interesting was that in the following versions the Yoast must have noticed the difficulty that its members were in setup your plugin and it decided to include a tour guide for the configuration. Unfortunately also sinned by not knowing how to use the right tool, which I think could be something like the wizard BuddyPress.
To end this criticism, which to me is more striking: a promotional page called “About” and a sidebar that accompanies every page that includes several boxes with advertising and links for donations.
This is not to say that the Yoast can not monetize your plugin, but it is not necessary to do this because we can always assume that if a person wants to donate because they like the work, then it does so, looking for a way to do. In my view a small link to request donation on plugin activation page would be enough and would have virtually the same effect. The optimal resolution for this problem could be the choice of the most important settings and create a sub-called “SEO” in the options menu. All other settings should be moved to action hooks.
DECISIONS, OPTIONS NOT!
It is the motto always used in the construction of WordPress. The idea is that you do not waste time in having to configure or make choices. Choices lead to indecisiveness, indecisions lead to applications functionality and the more options there are more prone to error WordPress is. Obviously, a user should not get stuck to the choices of the majority and that is why there are plugins: to extend the features that can help a group of people who use WordPress and better do your job.
Keep the following in mind when building your plugin:
A plugin must have a purpose, and only one well-defined;
You should give the user choose only options that are critical to the proper functioning of the plugin;
Develop a functionality in order to meet most, and provide action hooks to the more jaunty user can modify the functionality to your liking.
CREATING A PAGE IN ADMINISTRATION
We will then initiate the creation of a sub-page in the administration, under the options menu. This sub-menu will be called fantastically “UI testing”! For this open the plugin file we created earlier and we will then place the following code:
<? Php
// Add an action in the menu adminsitração
add_action ( ‘admin_menu’ ‘test_ui_submenu_page’);
test_ui_submenu_page function () {
    // Add a submenu to the page of the plugin where we make drivers
    add_submenu_page ( ‘options-general.php’, __ ( ‘UI Test’ plugin-test-ui ‘), __ (‘ UI Test ‘plugin-test-ui’), ‘manage_options’ plugin-test -ui ” test_ui_submenu_page_callback ‘);
}
// This function is the display of the page content
// In the future we will put all that is visible here
test_ui_submenu_page_callback function () {
    echo ‘<div class = “wrap”>’;
    echo ‘<h3> Test UI </ h3>’;
    echo ‘</ div>’;
}
This submenu entry is already created . Save the file and again to refresh the browser , you will find a submenu entry “UI Test ” under the options menu. This is the page where we will put our controllers. Any user can find this submenu , but it will be easy? It may be a difficult task if you do not provide instructions for your users seek the settings page . For this there is a fairly easy way to contronar this problem .
With this we will try to ensure that any option of the plugin is not lost, and so our users easily discover what to do after activating the plugin. Add a link to the configuration page next to the link to disable and edit is a good way to ensure this :
< ? Php
add_filter ( ‘ plugin_action_links ‘ ‘ my_plugin_settings_link ‘ , 10, 2 ) ;
function my_plugin_settings_link ( $ links , $ file ) {
    if ( $ file == plugin -test- ui / plugin -test- ui.php ‘ ) {
        / * Insert the link at the end * /
        $ Links [ ‘ settings’ ] = sprintf ( ‘ % s <a href=”%s”> </a> ‘ ADMIN_URL ( ‘ options- general.php ? Page = plugin -test- ui ‘ ) , __ (‘ Settings ‘, ‘ plug -test- ui ‘));
    }
    return $ links ;
If you go now to the plugins page will find the actions of the plugin a direct link to the configuration page. This way your users will feel more comfortable.
In the next article we will deal with other native elements of management. Let’s start by building the drivers of our page and learn some rules to build plugins for WordPress  with Freelance WordPress Website Designer In Hyderabad.




LEAVE A REPLY

Please enter your comment!
Please enter your name here