Archive - May 4, 2017

Getting plugged in - part one

I mentioned recently that I need to learn to code properly but it's more a case of learning the environment in which I'm working.

When I used to do a bit of VBA (Visual Basic for Applications) in a previous role the VB side of it wasn't an issue, the more complicated part was the A, the applications with their object models, and how you get them to do what you need.

It's the same with WordPress.

I can get by with PHP but learning the actions, hooks and filters that make WordPress do what you want takes time.

Saying that, it always amazes me just how easy it is to create a simple WordPress plugin - just add a comment to the start of a PHP file:

/*  
    Plugin Name: My plugin  
*/

You would normally add in more details like Description: and Version: but the only actual requirement for WordPress to recognise it as a valid plugin is a name.

How simple is that?

What's next?

Having moved my code for indieweb 'likes' and 'replies' from functions.php to a plugin I feel this is a perfect opportunity to learn by doing. While the plugin does what it's supposed to I would like to add enhancements to make it a more complete offering.

So, here's a quick 'back of an envelope' list of what I want to do:

add security to plugin to stop direct access (an easy one to start)
add a settings page to save plugin options
use these to determine the text added to a post
maybe add a choice to insert the text at the top or bottom of the post
register the 'Liked' and 'Reply' custom fields so always available in the drop-down
remove those entries when plugin is uninstalled

Getting to grips with each element of this is going to be a journey that I will document, for my own benefit if nothing else but if it helps others then that's great.

I hope you'll join me.

Comments

Srikanth Perinkulam says:

Likes: liked-Getting plugged in – part one Twitter

Related

Chris Aldrich says:

Congratulations on self-dogfooding! Taking the first steps are always the hardest...

Colin Walker says:

The security of any code should be of the utmost importance but, if creating a plugin that might be distributed to other people’s sites, it should be paramount. It’s one thing messing up your own site but another entirely breaking someone else’s when they’ve put their trust in what you’ve written. As we established last time, this series covers the process of improving my “Likes and Replies” WordPress plugin. This is a relatively simple piece of code that doesn’t do much (yet) but it’s still good to ensure it’s as secure as it can be and get into good habits. First steps It is best practice to prevent direct access to plugin files meaning they can only be used within the context of a WordPress installation. This is done by adding the following to the start of any PHP files: if (!defined('ABSPATH')) exit; // Don't run if accessed directly ABSPATH is the absolute path to the WordPress installation directory and is defined by WordPress itself. If this is not available to the plugin it is not being run within the context of an installation. We are relying on user input in the form of a URL to add likes or replies so should take steps to ensure that this is properly encoded and valid. We can use esc_url() to do this which removes invalid or dangerous characters. Getting the address entered into the custom field then becomes: $mentionurl = esc_url(get_post_meta($id, $type, true)); I had already made a change to the code replacing file_get_contents() with wp_remote_get() as the former was considered insecure. A good start With a more complex plugin additional protection may be required, like sanitising inputs which I, no doubt, will have to do later if I am able to meet my goals. This is a good start to the learning process but I now need to work on my priorities for what to tackle next.

04/05/2017

Getting plugged in - part one

What's next?

4 comments: click to read or leave your own Comments

Comments