(WordPress design tips and tricks)-WordPress plugins are available to add just about any type of enhanced functionality to the platform. In fact, plug-ins are a major reason why WordPress is such a popular content management system and versatile platform that now extends far beyond blogging sites. Many PHP developers are getting in on the action by developing WordPress plug-ins, either for their own enjoyment or for paying clients.
However, there are a few things any developer should remember when developing plug-ins for the WordPress platform. These things include coding and security best practices, version updates and support, how-to tips and methods of standardizing the resulting Plugin Developer.
10 Useful for WordPress Plugin Developers
1. Always enable debugging when developing plug-ins for WordPress
Enabling debugging requires a little tweaking of code in the “wp-config.php” file. Of course, any good PHP developer knows to make a backup copy of any PHP code page prior to making any changes to the code. Though many tools are available to edit PHP code, most PHP developers prefer a simple text editor, such as Notepad. Some use text editors with line numbering and color coding features, such as Textpad. However, no matter the tool you prefer to use to edit the code page, make sure you create a backup copy of the page before you change one single character of code.
After you have created the backup copy, you will need to replace a single line of code with a few lines of edited code to enable the debugging feature.
You replace the following line of code in the wp-config.php file:
|
1
|
define('WP_DEBUG', false); |
Locate this line in the config file and replace the line with the following series of lines:
|
1
2
3
4
|
define('WP_DEBUG', true);define('WP_DEBUG_LOG', true);define('WP_DEBUG_DISPLAY', false);@ini_set('display_errors', 0); |
The first line turns on the debugging feature. The second line instructs WordPress to log debugging results to the /wp-content/debug.log text file. The third line ensures that the display errors variable does not need to be on. The final line hides the errors from displaying on the screen. If you prefer, comment each line with its description.
With debugging enabled, you will not only see coding errors in the log file, but you will also receive warnings. One type of warning that may be displayed is an indication that the function you are using will soon be deprecated. You should heed these deprecation warnings and find another way to accomplish the task, which will save you from the trouble of rewriting code once newer versions of WordPress are released.
A useful plug-in for debugging WordPress plug-in code is the Blackbox Debug Bar plug-in . The Blackbox Debug Bar installs into the WordPress platform and displays errors, queries and profile data, as well as global variables, at the top of each WordPress post or page.
A useful plug-in for debugging WordPress plug-in code is the Blackbox Debug Bar plug-in . The Blackbox Debug Bar installs into the WordPress platform and displays errors, queries and profile data, as well as global variables, at the top of each WordPress post or page.
Another debugging WordPress plug-in is Debug Bar. It adds a debug menu to the admin bar that shows query, cache, and other helpful debugging information.
Debug Bar WordPress Plugin
2. Prefix functions with a unique tag
Because many WordPress developers do not prefix their functions, it is easy to get confused between your code and code written by others. Additionally, each function must have a unique identifier. Create a good habit of prefixing your code with an identifier that you will quickly recognize as your own and each function you write will automatically have a unique name.
3. Use global paths, where applicable
Chances are, you will write some CSS and JavaScript to accompany your plug-in for the look and feel. Create global paths to your “js” and “css” folders, as well as your “images” folder. Not only is this action recommended as a best practice task, but once you get used to using global variables, writing code becomes so much more efficient and your code is easier to read by others.
Consider creating global paths to:
- The Theme directory
- The name of the plug-in
- The plug-in directory
Also, create a global variable for the URL to the plug-in.
4. Record version numbers for your plug-ins for future upgrades
Record a function that will display the version numbers for the plug-ins at the top of your code pages. Inevitably, you will create future versions. Even if you believe that you are coding the be-all-and-end-all of plug-ins and you think you will never need to edit the code or create an updated version, you will.
You will find parts of the code that need to be rewritten for a variety of reasons. If the database changes, you will need to accommodate the change in the code. If a function is buggy, you will need to update the function with a fix in a future version. In any case, get in the habit of assigning version numbers to your plug-ins. You will be glad you took this step when the time for updates rolls around.
A Best Practice is to store your plug-in version number in the WordPress database. To do this, define a plug-in version key variable and a version number global variable. Add the add_option() function and code the update to execute with the function. If you use the add option() function instead of the update option() function, the function will not change data if the update already exists.
5. Use the ‘dbDelta()’ Function to Create and Update Database Tables
If the plug-in you are coding requires the use of its own database tables, these tables will likely need to be updated with future versions. WordPress, however, provides the dbDelta() for this very reason.
Using the dbDelta() requires a few tricks, however:
- In your SQL statement, each field must be written on its own line.
- Two spaces must follow the
PRIMARY KEYstatement and the declaration of the primary key. - The keyword “KEY” must be used instead of
INDEX. You must define at least one KEY.
Even though the dbDelta() function is included in the wp-admin/includes/upgrade.php page, you must manually include it because it does not load by default.
6. Understand the difference between include and include_once. Similarly, understand the difference between require and require_once
The difference between these statements is rather apparent. However, even though many developers use the include and require statements interchangeably, the purpose for each of them differs from the others.
include will include a page that is specified in a functions.php statement. However, if the page is already included, this code will include the page again. If the page is not found, a warning will display.
include_oncewill include the page, but only one time.requirewill include a page multiple times, if specified. If the page is not found, a fatal error will be thrown.require_oncewill include the page once and throw the fatal error if the page is not found.
Most developers prefer the include_once option. However, you may find reasons why you would need to use the other three options.
7. Use the bloginfo(‘wpurl’) syntax instead of bloginfo(‘url’)
Because WordPress is generally installed in the root folder of a website, the difference in the syntax is usually not obvious. However, you will occasionally run across a WordPress deployment that is not installed in the root folder. This wpurl syntax specifies the WordPress default URL in these cases. The url syntax specifies the root folder of the site.
Because the root site and WordPress root may be different, this practice standardizes your code to indicate the WordPress default folder, just in case.
8. Know when to use Actions and Filters hooks.
WordPress allows coders to use Actions and Filters in the execution of code. Actions will enable WordPress to invoke an action at certain points during the execution of code or as the result of certain events. Filters allow WordPress to modify text before the text is inserted into the database and/or before the text is displayed on the screen.
The use of Actions and Filters is quite broad. Research and examine the possibilities for using these hooks.
9. Create your own Admin menu or Settings page
As you create your plug-in, you will likely need to offer the user choices and configurations in a settings page. The way most developers accomplish this feat is to create a stand-alone settings page for the plug-in, or to add custom options to the existing top-level admin menu.
10. Use action links as shortcuts to functions in your settings page
You can add a “Settings” shortcut, or any other functions that you find users will regularly perform, to your plug-in listing and description. The “Settings” action link will appear next to the default action links of “Deactivate” and “Edit”. This will allow the user to quickly access the settings page from the plug-in listing.