Author: Tom (Page 89 of 427)

Uploading Files in WordPress Revisited, Part 2 – The Server Side

January 16, 2018 / Tom

Before jumping right into the code for this, I wanted to mention two things:

Yes, I’ve covered this in some detail a while back,
And this is the second part of a two-part series.

If you’ve not read the first part, do it first. The idea is that the code will work in conjunction with what I’m going to cover in this post to make sure that both the client-side and the server-side are covered.

Ultimately, the reason for breaking it down like this is not just to make sure that things are done correctly, but also to make sure that the user has the most positive experience possible.

With that said, here’s how to go about uploading files in WordPress on the server-side.

Uploading Files in WordPress, Revisited: Part 1 – The Client Side

January 15, 2018 / Tom

Years ago, I wrote about how to upload files in WordPress from the administrative area. This post is practically an update to that post, but it covers new considerations that I make and some other processes that I think are necessary.

For this post, I’m going to work off the example of uploading a PDF file and how also to make it available in the Media Library.

In doing so, I’m also planning to cover some considerations that should be made on the client-side and the server-side as well as things for which to look for whenever someone is transferring information across the wire.

Abstract Classes, Part 1 – Abstracting Behavior

January 10, 2018 / Tom

About a month ago, I wrote about one of the pillars of object-oriented programming (specifically being Abstraction). In the post, I defined abstraction as the following:

Instead, we’re going to be abstracting ideas into their classes. And there’s a key idea here: A class should represent a noun.

And though that’s still true, the idea of abstract classes is something that’s different in object-oriented programming.

It sounds confusing, right? That is:

on one level, we have abstraction being defined as the idea that we take an idea and represent it in a class,
on another level, we have abstract classes which are used to help define functions that subclasses must implement.

And if that isn’t confusing enough, we mix this in with interfaces which provide a contract implementing classes must follow, and then we mix it with abstract classes which define methods that also must be implemented but can also implement methods of their own.

Confused yet? No worries. The whole point of the next three posts is to do the following:

Define what abstract classes are,
Describe the different in abstract classes and interfaces,
Help decide when you want to use one over the other.

With that said, here’s the whole idea behind abstract classes.

Iterating on WordPress Administration Screen Design

January 9, 2018 / Tom

The idea of an “iterative process” is nothing new in software development. It’s present in a number of different methodologies and likely because it works well especially when getting customer feedback.

One of the places that I also find it useful is when building administration interfaces for WordPress plugins.

To be clear, I’m not a designer, so when it comes to front-end work, I always refer to the style guide and the mockups the designer provides to me from the outset of the project. (I only mention this because I think it’s a practice anyone who’s not a designer should follow, but I digress).

But when it comes to working on administration screens or back-end screens for WordPress, I tend to follow a strict rule: Make sure it looks as natural as possible.

How, then, do iterative development and the interface of WordPress administration screens have anything to do with each other?

It’s Easier to Find a Solution (With Someone Else)

January 5, 2018 / Tom

One of the most frustrating aspects of programming is working on a solution to a problem and bumping up against something that we should know how to do or be able to figure out how to do, but we’re unable to do so.

There’s probably a proper psychological term for this or an acronym given that I’m talking about programmers. 🤷🏻‍♂️

Case in point:

Let’s say that I’m working on a project and it has to make an Ajax request. I get the response, I display it, and I also cache the response for 24 hours.

If the user requests the information again, I pull it from the cache, and it looks fine. But what about whenever you’re the first person to hit it in the next 24 hours?

That is, you get a cache-miss, and then you get not only a longer-than-normal request, but you also get a response that needs some additional processing before rendering it to the user?

Easier to Find a Solution

Reading this, you’ve likely got a laundry list of things you’d try to do. And I’d venture to say that everything you’re thinking is likely worth trying if not right.

Ultimately, that’s proving my point. And that’s this: When you’re not as close to the problem, it’s easier to find a solution.