From a developer’s standpoint, I have mixed feelings about having a built-in editor for editing custom CSS in WordPress. On one hand…

• It’s a really easy way to make quick changes to the theme you have installed so you get the changes you want.
• Then again, it also completely bypasses and defeats the entire child theme process.

As I’ve tried to think this through, I realize each serves a different purpose I’ll try to explain in a moment, but sometimes I can’t help but wonder if it makes things for difficult for users or more difficult for other developers than necessary.

Sounds weird, I know. But hear me out.

Continue reading

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.

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