Get Notified WordPress Plugin

Get Notified is a simple to use notification plugin that notifies you of certain WordPress events.  It helps users know when certain events happen on their site. For now, the plugin simply sends a notification via email or a message to a Slack channel when a post changes status (i.e. publish, pending, draft, trash).  I hope that others help contribute to this project to expand it and grow the number of integrations and WordPress events. Continue reading “Get Notified WordPress Plugin”

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.

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()”

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.

Script Localization with JQuery in WordPress

Today, most plugin developers use JQuery to perform client-side tasks.  This adds a lot of functionality to your WordPress plugin, but what if you want to pass server-side data to these client-side files?

After your JQuery files have been included to a page, then you can use the wp_localize_script() function to pass your server-side data to these files.  All data is passed as a string, but you can convert it to a number if needed.  If you don’t know how to include files to a WordPress page, then check out this post, Include Javascript and CSS files through your WordPress Plugin.

<?php
     wp_enqueue_script( 'some_handle' );
     $passed_data = array( ’name' =>  ‘Kyle Benk' , ‘job_status' => ‘Wordpress Developer' );
     wp_localize_script( 'some_handle', ‘passed_data', $passed_data );
?>

You can then use this data in your JQuery script file like so:

$(document).ready(function(){
     console.log(“Name: “ + passed_data.name + “ Job Status: “ + passed_data.job_status);
});

How else can you use script localization with JQuery to your advantage? Here is an example of passing a translated string:

<?php
     wp_enqueue_script( 'some_handle' );
     $passed_data = array( ’string' => __( 'Some string to translate' ));
     wp_localize_script( 'some_handle', ’passed_data', $passed_data );
?>
$(document).ready(function(){
     console.log(“Translated String: “ + passed_data.string);
});

If your console outputs an undefined variable error for your passed data, then it means your wp_localize_script() function did not send the data properly. Most commonly this is because you are calling the wp_localize_script() function before the script has been included. So, make sure you enqueue the script before trying to localize it. To check for this error use this JQuery code:

if (typeof(passed_data) != "undefined" && passed_data !== null) {
     console.log(“Variable is set");
} else {
     console.log(“Undefined or null variable");
}

Include Javascript and CSS files through your WordPress Plugin

So, you are writing your plugin and realize that you need to include a Javascript or CSS file on a page. You think back to your HTML days and use:

<link rel="stylesheet" type="text/css" href="<?php echo $your_plugins_url; ?>css/your_css_file.css" />

or

<script type="text/javascript" src="<?php echo $your_plugins_url; ?>js/your_js_file.js"></script>

While technically it is possible to include files using HTML script and link tags on a standalone site, they are not best practice on a WordPress site. The main benefits of using WordPress’s core functions instead of generic HTML are:

  • Files are included to the generated page at the right time according to the script dependencies.
  • Files will only be included if it has not been already included and if all the dependencies have been registered.
  • Script localization is very easy, just call wp_localize_script() on your included files.  Check out Script Localization with JQuery in WordPress for more information.

Continue reading “Include Javascript and CSS files through your WordPress Plugin”

uninstall.php for WordPress Plugins

Every WordPress plugin you develop should always have an uninstall.php.  The purpose of this file is to erase all your plugin’s data when the user deletes it.  You don’t want to be the developer of a plugin that never deletes any of its data. So, start by adding an uninstall.php to your top directory and add this code to it.

<?php

/* if uninstall not called from WordPress exit */

if ( !defined( 'WP_UNINSTALL_PLUGIN' ) )
    exit ();

/* Delete all existence of this plugin */

global $wpdb;

/*
Drop Table if you created one

$table_name = 'your_table_name';

$wpdb->query('DROP TABLE `' . $table_name . '`');
*/

$blog_option_name = 'your_blog_option_name';
$site_option_name = 'your_site_option_name';
$post_meta_data_name = 'your_post_meta_data_name';
$user_meta_data_name = 'your_user_meta_data_name';

if ( !is_multisite() ) {

    /* Delete blog option */

    delete_option($blog_option_name);

    /* Delete post meta data */

    $posts = get_posts(array('posts_per_page' => -1));

    foreach ($posts as $post) {
        $post_meta = get_post_meta($post->ID);
        delete_post_meta($post->ID, $post_meta_data_name);
    }

    /* Delete user meta data */

    $users = get_users();

    foreach ($users as $user) {
        delete_user_meta($user->ID, $user_meta_data_name);
    }
}

else {

    /* Delete site option */

    delete_site_option($site_option_name);

    /* Used to delete each option from each blog */

    $blog_ids = $wpdb->get_col( "SELECT blog_id FROM $wpdb->blogs" );

    foreach ( $blog_ids as $blog_id ) {

        switch_to_blog( $blog_id );

        /* Delete blog option */

        delete_option($blog_option_name);

        /* Delete post meta data */

        $posts = get_posts(array('posts_per_page' => -1));

        foreach ($posts as $post) {
            $post_meta = get_post_meta($post->ID);
            delete_post_meta($post->ID, $post_meta_data_name);
        }

        /* Delete user meta data */

        $users = get_users();

        foreach ($users as $user) {
            delete_user_meta($user->ID, $user_meta_data_name);
        }

    restore_current_blog();
    }
}
?>

Continue reading “uninstall.php for WordPress Plugins”

Great File Structure for your WordPress Plugin

After you get your developing environment setup and you are ready to start coding, consider what type of file structure you should use for your plugin.  This could be a difficult task so I have decided to share with you my preferred file structure.

File_structure

Continue reading “Great File Structure for your WordPress Plugin”