Software Engineering in WordPress, PHP, and Backend Development

Tag: JavaScript (Page 1 of 12)

Articles, tips, and resources for JavaScript-based development.

Asynchronous Methods and Headers: Just Working Isn’t Good Enough

When sending asynchronous requests to a WordPress back-end, which may be a REST API or an Ajax callback, it’s helpful to know what headers to specify when sending said data.

Since I recently shared another post about idempotency in REST API design and since asynchronous calls are more common than they have been in the past, I thought it useful to share when to use what type of headers when making said requests.

If you’re working with WordPress in some capacity – be it a headless state or working on processing Ajax calls – then it’s useful indicate how your data is being sent and in what format the data is being sent. Ultimately, your asynchronous methods and headers need to do more than just work.

That is, it’s not enough for it to simply be sent and received. Instead, the data should be sent in a format congruent with what the backend service expects. If anything, future you will thank you. To make it even more relevant, this is an opportunity to keep our code as clean as possible.


Asynchronous Methods and Headers

When creating an Ajax request in WordPress using modern, vanilla JavaScript the request will likely look something like this:

fetch(tmAcmePlugin.ajaxurl, {
    method: 'POST',
    body: data,
    credentials: 'same-origin',
    headers: new Headers({
        'Content-Type': 'application/json',
    }),
})

Notice here I’m specifying the headers as part of the request which isn’t something we’ve historically done. In this example, I’m using application/json.

It’s also common to send form data across the wire, too. And if you do that, then your request will look something like this:

fetch(tmAcmePlugin.ajaxurl, {
    method: 'POST',
    body: data,
    credentials: 'same-origin',
    headers: new Headers({
        'Content-Type': 'application/x-www-form-urlencoded',
    }),
})

Obviously, know which type of header to send and when is important. As obvious as it seems, these are the guidelines I recommend when working in the context of WordPress-centric applications.

  • Use application/json whenever you’re sending a payload that’s structured as JSON. Whenever you’re receiving the data on the server, you’ll need to use json_decode or your language’s equivalent to parse the data.
  • Use application/x-www-form-urlencoded whenever you’re sending a payload that comes from data being sent from a form element or in a string of key/value pairs such as key_one=value_one&key_two=value_two. Typically, this will be received in a POST request.

Again, however you specify the method and the header, the data will still be sent but how you manage it on the server may not match up to what’s expected.


If someone else – either someone with whom you work or just future you – reads the client-side code and the server-side code and what’s sent doesn’t match, it’s going to create an entire set of circumstances of detangling what’s been done and something that’s completely unavoidable.

What Are Source Maps (And Are They Needed)?

If you work on the front-end of a site in any capacity – be it for a plugin, a theme, or even something outside of WordPress – you’re likely working with minification tools.

The benefits are obvious, right?

  • it lessens the payload,
  • it allows us to focus on development on our local environments

But one of the features that come with working with these technologies and that’s the ability to generate source maps.

And this raises a question (or maybe two): What are source maps? And are they even needed?

You can claim it’s late to the game to talk about this, but there are always people entering the industry that may not know this material.

So why not cover it?

Continue reading

Triggering Angular Events with jQuery (As Weird As That May Sound)

One of the things that I enjoy about working with WordPress is the ability to bring in third-party libraries and tools with which to work.

This doesn’t mean they don’t come without their learning curve (they all do, right?), but it’s often fun – albeit frustrating, at times – to incorporate and then manipulate what you’re doing.

As far as third-party technologies go, I’ve seen people bring things in such as the Laravel Illuminate package with WordPress.

Triggering Angular Events with jQuery: Illuminate

And I know, especially in recent years, many have brought in components such as React and Vue.

Triggering Angular Events with jQuery: React

In one such instance, I’ve been doing some work with Angular. And if you’re used to ES6, vanilla JavaScript, or using jQuery, then triggering Angular events with jQuery can seem a bit weird at first.

Triggering Angular Events with jQuery: Angular

But once you understand the markup and how Angular handles its events, it’s not so bad.

Continue reading

Is It Really Worth Debating jQuery Versus ES6?

When building WordPress plugins for myself or others, several of the things I take into account – as we all should – is the level of maintainability, scalability, and support for the plugin as WordPress continues to move forward.

Specifically, I’m talking about client-side development (or, more simply, JavaScript).

As the support for ES6 continues to rise, jQuery continues to move forward with development, and the desire to use new APIs to build out our solutions, I believe it’s worth asking the question:

Do we really need to stick with jQuery?

Continue reading

An Object-Oriented Way of Working with Models and Web Applications

When we talk about the concept of Models in object-oriented programming, we’re usually referring to a class that is a representation of the data stored in the database.

That is is, when information is stored in rows and columns, we populate a class, its attributes, and so on with that information so that we’re able to pass it around the application, manipulate it as needed, and then possibly serialize the data back to the database.

But in a web application, it’s fair to assume that the model might need to be possible to the front-end to be used. That is, imagine a front-end request making a call to the server, requesting a model (or a collection of models), and then rendering them on the front-end.

Though this particular post isn’t code-oriented, I still think it’s worth thinking through the process of translating a model from the server and then rendering it on the front-end of the web application.

Continue reading

« Older posts

© 2024 Tom McFarlin

Theme by Anders NorenUp ↑