Author: Tom (Page 126 of 427)

A Bit About Micro.blog (And Why I Backed It)

January 25, 2017 / Tom

In a deviation from the typical type of content I write, I want to share a bit about Micro.blog in case others have yet to hear of it, why I backed it, and what I hope it aims to do for the web.

About Micro.blog: The Kickstarter Page

In short, the whole purpose of Micro.blog is to provide an easy place for people to both write and own their short form content.

From the Kickstarter page shown above:

Today, most writing instead goes into a small number of centralized social networking sites, where you can’t move your content, advertisements and fake news are everywhere, and if one of these sites fails, your content disappears from the internet. Too many sites have gone away and taken our posts and photos with them.

And the service is targeting services Twitter, Facebook, and other similar sites. Don’t get me wrong: I like and use Twitter, but I also know that whatever it is I post there is up to the discretion of the service on if the content persists.

But there’s more to it than that. At the time of this writing, there’s a week to go in the Kickstarter, though it’s far surprised its goal, there are some things about the service I’m excited about and want to share.

Temporary Options in WordPress: Our Best Option?

January 24, 2017 / Tom / 0 Comments

When it comes to programming, the idea of temporary values or temporary variables or any way of storing data temporarily in memory isn’t anything new.

But when working with WordPress – which is stateless – we don’t always have that luxury. That is, it’s not simply a matter of, say, throwing something into the current session, reading it, and then removing it when we’re done with it.

And that’s when I’ve been giving more and more thought to the idea of temporary options, for lack of a better term of course. That is, whenever I need to store a value from a single page load, or request, to read in another page load, or another request, I’ll temporarily throw the value into the options table.

Temporary Options: An Exercise and Representation via Rudimentary Sketching

Is that sloppy? Maybe. Do we have a lot of other choices? It depends on how much of modern browser technology we want to use. That’s not the point of this post, though.

The point is that because of the way WordPress works, I wonder if our current, best strategy for maintaining temporary values that is most widely supported across installations is to temporarily add a value into the options table, read it, and then delete it once it’s been retrieved?

When To Use WordPress Subactions (And What Are They?)

January 23, 2017 / Tom

I recently walked through the process of using a class’ constructor to prevent a plugin from working if it an expected dependency isn’t loaded.

Though I don’t consider this particular strategy a problem for a one-off dependency or in certain situations, there are ways this can lead to code smells.

It also prevents us from using a native feature of Core called WordPress subactions:

https://twitter.com/JJJ/status/822265137935646720

But before looking at subactions, I want to make sure I’m clear around the problems using the conditional approach (versus subactions) can breed with code smells.

Adding Visual Studio Code Debug Configuration

January 20, 2017 / Tom

In earlier posts, I’ve talked a bit about Visual Studio Code the least of which not being the importance of debugging your code with Xdebug.

One of the questions I’ve received (and seen elsewhere around the web) is how to actually setup Visual Studio Code debug configuration. That is, you have Xdebug installed, you have the module specific in your PHP configuration file, but there’s no way to actually activate the debugger within the IDE.

Instead, you see something like this:

Visual Studio Code Debug Configuration

This is an easy fix.

Stop Plugin Execution Without a Dependency

January 19, 2017 / Tom / 0 Comments

If you approach a lot of WordPress plugin development from an object-oriented perspective, then you’re eventually going to hit a point where you’re not doing a lot of interaction directly with WordPress core itself.

And, in my mind, that’s a good thing. It’s a sign of an architecture that you’re properly structuring your code. That is:

You have WordPress sitting at the foundational level,
You have a set of classes that are sitting just above WordPress responsible for sending information to and from WordPress between the plugin,
And you have the rest of your code that comprises the rest of the functionality.

How this is implemented can vary, but the general way I picture this is the same way I tend to think of the standard N-tier application where you have the data layer, application layer, and front-end.

Except for this time, you have the WordPress, a layer for communicating with WordPress and the rest of your code, and, you know, the rest of your code.

How a plugin may be organized.

So what happens when you want to stop plugin execution when it has to interact with a third-party dependency and should only execute if that dependency is present?