The simple webComments

Jack links to a piece on Wired by Clive Thompson called "It's time to make code more tinker friendly." He's absolutely right.

The article argues in favour of maintaining "a simple on-ramp" for the web so that those with little experience can jump in and not be put off by overly complex languages and frameworks.

I was immediately reminded of "Resilient Web Design" by Jeremy Keith in which he discusses different types of language. He states that HTML and CSS are declarative languages in which the author "describes a desired outcome without providing step‐by‐step instructions." This is in contrast to imperative languages (like Perl or C++) where precise instructions must be given or nothing works.

But we can go further than that.

In an episode of The Run Loop podcast Laura Savino talks about the difference between human language versus computer languages:

"with natural languages you can get by with a lot of hand waving"

Even if you aren't fluent in a foreign human language you can get by knowing some words, even if your grammar is bad, because the person you are talking to is able to interpret sufficiently to grasp what you are saying.

Coding, however, is exacting in its requirements. If something isn't absolutely correct then you won't get a result.

While browsers can be pretty forgiving in the way they render HTML you still have to be quite clear in what you write. Tags must be correctly closed and nested and you can't forget angle brackets or whole sections of content can be mistaken for malformed attributes and not displayed.

I think about how kids are introduced to programming: getting basic robots to achieve goals by giving them very simple commands - turn left, go forward, if you hit something go the other way.

From here consider how functionality within certain apps works where you don't have to be precise, but work within a set of parameters. Rather than giving an exact date you can say "next Wednesday" or "the second Saturday of the month" and the app will interpret this.

Thompson talks about taking existing, well commented code and remixing it, tinkering, to get a grasp on how things work but, what if web development could be simpler?

What if we had engines and parsers (AI?) that could interpret imprecise commands and still return a pretty good approximation of what you intended without even having to write a single HTML tag?

What if we could remove the need to learn by tinkering because the AI took care of all that for us? There's no easier on ramp than your own natural language.

The simple web

Getting plugged in – epilogue

Since raising the version of the 'Likes and Replies' plugin to 0.9.0 and calling it a release candidate I don't think I've come across any problems. It's hard to believe that the last commit logged on GitHub was 17 days ago.

Where does the time go?

There might be some tidying up I could do to the code but, on the whole, I think it's achieved exactly what I was after and reached its natural conclusion.

That's not to say there won't be future updates if I think of new functionality, find problems or want to do things differently. But, for now, I think it's safe to put down a marker and bump it to a 1.0 release.

Although the plugin is reasonably simple I've learnt some good techniques which can be applied again and again while also learning from mistakes that, hopefully, won't be repeated.

It's been fun to go through the process of documenting this publicly, with nowhere to hide, and am glad I could contribute something to those who may use it.

Getting plugged in – epilogue

Getting plugged in – part two: securityComments

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.

Getting plugged in – part two: security

Getting plugged in – part oneComments

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.

Getting plugged in – part one