WordPress Coding Standards

Coding standards are extremely important to me and how I do my work. I believe that writing code with a high level of readability is sometimes better than writing the fewest lines of code. Having a consistent ruleset for indentation, tabbing, spacing and commenting is fundamental to creating quality software that is maintainable and extensible with larger development teams. Continue reading “WordPress Coding Standards”

WordPress Application Passwords

Ever since the 4.4 WordPress release laid down the scaffolding for the REST API there has been a need for easy user authentication.  Users needed to access the REST API without having to use their own admin login passwords as well as the ability to stop access with a specific password if it became compromised.  One such solution is the WordPress Application Passwords plugin. Continue reading “WordPress Application Passwords”

Headless CMS and the WordPress API

The WordPress 4.4 release is the beginning of the WordPress API and from there developers have been determining how to best use this new API that is being inserted into core over the coming releases after 4.4. A Headless CMS using the WordPress API was one of first applications of this new API and probably the best one. Continue reading “Headless CMS and the WordPress API”

How To get a WordPress Widget ID for Multiple Instances

Supporting Multiple Widget Instances

Just recently I was developing a WordPress widget, and as I began coding of all my use cases I realized that I needed to be able to support multiple widget instances.  Supporting multiple widget instances is not a big deal, unless you plugin depends on knowing the widget id from the front-end.  By this I mean after your page has loaded, you need to perform client-side scripting that depends on knowing the id of each widget instance.

Where is the Widget’s Instance ID stored?

/** @see WP_Widget::widget */
function widget($args, $instance) {
    echo $this->id;
}

Continue reading “How To get a WordPress Widget ID for Multiple Instances”

WordPress General Plugin that is Open Source on GitHub

Open Source WordPress Plugin for the Community

As a WordPress plugin developer I understand the struggles that all developers face.  Whether you are a beginner or advanced WordPress plugin developer I hope that this general plugin will help you start your project.  The main reason I have created this WordPress general plugin repository is to give you, the developer, a base to work off of.

Get it on Github

I am constantly improving this general plugin, but please send me pull requests or fork it as you want to help create a great base plugin for everyone to work from.  So check it out on Github!

Comment below with input on how to improve this general plugin.

Include Builtin scripts from WordPress using wp_enqueue_script()

Since we already showed you how to Include Javascript and CSS files through your WordPress Plugin, this post will be about how to include builtin scripts from WordPress. Why would we use these pre-registered scripts?

Two Reasons Why to use Builtin scripts from WordPress

There are two main reasons why using the pre-registered scripts is beneficial. First, this method will help to prevent jQuery conflicts. Second, it is a lot easier to use dependencies. Here is a list of all default scripts included and registered by WordPress. First lets look at an example to help prevent jQuery conflicts: if your plugin uses jQuery 1.9.2 and WordPress uses jQuery 1.11 then some features, like the drag and drop, might not work. So instead of doing this: Continue reading “Include Builtin scripts from WordPress using wp_enqueue_script()”

Create Local Version Control in your WordPress Plugin

We think its best to start this post of with an example. Lets say you develop and publish version 1 of a plugin, and within this first version you create a custom table in the WordPress database. Your plugin becomes successful and you release version 2 with changes to the table schema. Finally you release version 3 with more changes to the table schema and add a new table that relates to the first table.

What is the Problem and How can we solve it?

If you don’t have local version control, then you cant know what version of your plugin the client currently has installed on their site. This is a problem because you have to make different changes in your plugin depending on which version the client currently has and which one they are updating to.  Look at the follow table schemas below for each hypothetical version of your plugin. Continue reading “Create Local Version Control in your WordPress Plugin”

Make Sure Your Plugin Protects Against SQL Injections with $wpdb->prepare()

What are SQL Injection attacks?

SQL injection attacks are things that every web developer should know about and should learn how to prevent.  Simply, a SQL injection attack is when a user inputs executable SQL code into an entry field that queries the database.  For example: instead of the user entering their username, they enter some executable SQL code that is most likely malicious.  Below is a generic example from Wikipedia:

What a normal user will enter:

"SELECT * FROM users WHERE name =‘username’;"

What is entered in an SQL injection attack:

"SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't’;”

So, as you can see, the second statement will drop the “users” table and then will display all the data in the “userinfo” table.  This is not good! Continue reading “Make Sure Your Plugin Protects Against SQL Injections with $wpdb->prepare()”

How to Change the Title of your First Submenu Page

There is a little thing you should know about WordPress’s add_submenu_page() function.  After creating your menu page using the add_menu_page(), you decide you would like a submenu page as well. So you use the add_menu_page() and add_submenu_page() functions, as below.

add_menu_page(
     __('My Plugin', 'text-domain'),
     __('My Plugin', 'text-domain'),
     'manage_options',
     'plugin-menu-page',
     'plugin_menu_page_callback'
);

add_submenu_page(
     'plugin-menu-page',
     __('Settings', 'text-domain'),
     __('Settings', 'text-domain'),
     'manage_options',
     'plugin-submenu-page',
     'plugin_submenu_page_callback'
);

As you look at your screen, you notice that the menu page and first submenu page have the same title. Why is this?

Menu_Page_Same_Title

Basically, when you use the add_menu_page() function to create a custom menu page and then use the add_submenu_page() function, WordPress casts the first submenu page to the top menu page. So, in order to get rid of this, just cast your first submenu page to the top menu. I know this sounds confusing at first, but look at the code below to see what I mean.

add_menu_page(
     __('My Plugin', 'text-domain'),
     __('My Plugin', 'text-domain'),
     'manage_options',
     'plugin-menu-page',
     'plugin_menu_page_callback'
);

add_submenu_page(
     'plugin-menu-page',
     __('General', 'text-domain'),
     __('General', 'text-domain'),
     'manage_options',
     'plugin-menu-page',
     'plugin_menu_page_callback'
);

add_submenu_page(
     'plugin-menu-page',
     __('Settings', 'text-domain'),
     __('Settings', 'text-domain'),
     'manage_options',
     'plugin-submenu-page',
     'plugin_submenu_page_callback'
);

As you can see, there are three function calls instead of the two used before. The first one is used to create the top menu. The second one, or the first add_submenu_page() function call, tells WordPress that the first submenu page will be a duplicate of the menu page but with a different title in the menu bar (i.e. “General”). The reason why the titles are different while the content remains the same, is because the menu slug (i.e. “plugin-menu-page”) and the callback function (i.e. “plugin_menu_page_callback”) in the first add_submenu_page() function call are the same as the add_menu_page() function call. Finally, the third function is technically the first real sub menu page that has its own content.

By following these steps, your plugins menu page will end up looking like the image below.

Menu_Page_Different_Title

Always use Object-Oriented Programming in WordPress Plugins

As most of you know, WordPress is open-source and free to the public to use and build upon. This is great because its a platform that will constantly be updated by people that truly care about it, and it is also extremely easy to obtain and use as a website platform. Although having an open-source platform is great in many ways, it also means that anyone can publish free plugins that conflict with WordPress features. So how do we, the developers, create plugins that have the least probability of conflicting with WordPress? One simple and very effective way is to use Object-Oriented programming.

What is Object-Oriented Programming?

It is a programming style that aims at creating modular and reusable objects that interact with each other. This is basically just a logical programming technique that incorporates best practices of coding.

What’s the difference between Object-Oriented and Procedural code?

Procedural programming refers to the step by step way this programming style executes code. This is most commonly found in small easy plugins that only rely on functions to modularize the plugin. This means that all code is usually written into functions that call upon each other based off of events or triggers. On the other hand, Object-Oriented programming refers to structured objects that are instantiated and then used to perform tasks. This is very useful because code is now modular and easy to build upon and use.

Why you should always use Object-Oriented Programming in WordPress?

By using an Object-Oriented Programming style, you are insuring that all your functions will never conflict with WordPress or other plugins. Also, using this programming style makes your plugin modular and very easy to upgrade or reuse elsewhere. Finally, it makes your code look very neat and it is easily readable by other developers.

Overall, Object-Oriented Programming refers to structured objects that are instantiated and then used to perform tasks. It is the only type of programming style you should use while developing WordPress plugins since it makes your plugin modular, easy to read, and non-conflicting with other plugins.