Software Engineering in WordPress, PHP, and Backend Development

Author: Tom (Page 199 of 428)

Ajax in WordPress: A Strategy For Error Codes

If you're reading this post in an RSS reader, don't forget to click on the "gist" link to see the code for the post.

In the previous post, I talked through the basics of setting of Ajax in WordPress on both the server-side and the client-side and how we can echo statements back to the client-side and why this is useful.

Ajax in WordPress: Error Codes

What I didn’t cover, though, was why this is important and how we can take advantage of it for gracefully handling any errors that occur throughout our code.

Whenever you’re dealing with a number of different variables such as user input, values of input fields, talking to the database, and network connections, there are a number of places in which the request and/or the response can fail.

And in those cases, we need to be able to make sure our project handles the situation well so we’re able to diagnose the problem and so our users aren’t left wondering what went wrong.

Continue reading

Ajax in WordPress: Custom Response Messages

I’ve talked about Ajax in WordPress in previous posts and it’s pretty well-documented in the Codex, so I don’t want to belabor the point on how to actually implement it.

Ajax in WordPress

Instead, the point of this post is to discuss how to implement custom response messages – or custom error messages – so you’re able to try/catch or gracefully handle the case when a request to the server fails.

That is, given the examples in the previous links we know how to implement Ajax in WordPress, but how do we handle the cases when something goes wrong? It’s not enough to simply write something out via console.log – after all, that’s meaningless to the user – but wouldn’t it be nice to actually display some type of message to let the user know what went wrong and how they can address it?

Continue reading

What Is the Assets Directory?

Last week, I wrote a short post asking What Is the Vendor Directory? which yielded a number of great responses, but it also resulted in a number of different questions, all of which were related, but none of which could be covered in that specific post.

For example, the article asked?

  • When do I know when to use a lib directory versus a vendor directory?
  • Should the vendor directory sit in the root of the project or should it exist in the root of, say, the JavaScript directory?
  • What about an assets directory?
  • Can lib and vendor co-exist?

And though some of these were answered in the comments and some of these answers can be found elsewhere, it did result in another question about the assets directory.

Continue reading

Get Values of Multiple Elements in jQuery

There are a number of JavaScript libraries and frameworks available right now – more than there have ever been before – and I think that’s a great thing.

If you’re a WordPress developer, odds are you’ve worked with at least one of three variations of JavaScript:

  1. jQuery since its included as part of core as is the choice library for the front-end
  2. Backbone since its also included as part of core and is used in features like the Media Uploader
  3. Vanilla JavaScript because sometimes the rest is overkill

And if you’re building advanced themes, plugins, or even web applications with WordPress, then odds are you’ve had to do some fancy stuff with JavaScript (using one or none of the aforementioned libraries). One of the challenges we face, though, is there’s no formal documentation of how to use jQuery within the context of WordPress core.

Should there be, though? I mean the jQuery Documentation is solid.

jQuery API

Anyway, one of the things I’ve stumbled across when writing my own code or in performing code audits is the way in which some developers attempt to get values of multiple elements in jQuery. Though there are some ways that work, there are always some options better than others.

Continue reading

Drafting Pseudocode Before Building Anything

The longer we work with a given library, framework, set of APIs, or whatever, the more comfortable we get with solving problems using them.

It’s a natural by product of experience, isn’t it?

But that doesn’t mean we’re solving the same problems over and over again. Sometimes, sure, we might be solving a problem like we’ve done previously. And really, in those instances, we should have libraries ready to plug into our work, but that’s content for another post.

Other times though, we may be working with the same foundation to solve new problems.

And that’s where it gets to be a little more touchy:

Because of our familiarity with the tools with which we’re working, we think we’re ready to jump in and solve the problem.

That’s not really the case though, is it? I mean, we might be working with the usual toolset, but we’re still solving a unique problem.

And in that case, shouldn’t we be taking a few steps prior before jumping into our IDE?

Continue reading

« Older posts Newer posts »

© 2025 Tom McFarlin

Theme by Anders NorenUp ↑