About a month ago, I wrote a post about single page tabbed navigation in WordPress. In the post, I made the following statement:

In some cases, it may be best to load pages via Ajax, in some cases, it’s better to load things up all in the first page load. This particular post is about the best strategies for that (that’s a debate for another post).

And I then I received the following comment:

I am also very interested and awaiting post regarding your take on when to use ajax and when to load it all.

Without context, this is a really broad question and it’s that I don’t think can be answered in a prescriptive way. When you’re trying to paint a solution for web development with broad strokes when each problem is a bit more unique, it’s not easy to provide advice that’s applicable across the board.

But this comment was about a very specific example and a very specific use case.

Continue reading

In the past, I’ve talked quite a bit about the WordPress Customizer. I think it’s one of the best features for both developers, designers, and users because of how quickly it shows the user the result of changes s/he is making to their site by changing a few options.

On top of that, the Customizer has two ways in which the preview pane can load the content:

1. Ajax
2. Refresh

That is to say that once the user changes an option, the entire preview pane can be refreshed (or reloaded), or the changes can be performed via Ajax and the page never refreshes.

Generally speaking, I think Ajax is preferable to performing a refresh, but I’ve recently found myself working on a project where I’ve had to mix the two, and I’m not really liking it. Chalk it up to a personality quirk, but I have this “all or nothing” mentality when it comes to how the preview pane displays its changes.

Either all of the options should work via Ajax, or all of the options should trigger a refresh but mixing the two feels off.

Continue reading

Whenever I’m in the process of working on something for a client, my usual setup is something like this:

• Work on the code on my local machine’s development environment
• Keep the code in source control using GitHub
• Use Dploy.io to deploy the latest commit to a staging server
• Repeat until ready to launch

Straightforward enough, right?

But there have been a couple of times when I’m working with designers or front-end developers who need to work on, say, CSS files while I continue to do some of the backend work.

If they’re comfortable working with source control, then granting them access to the repository of the project and having them commit their changes to be part of the deployment process works fine.

But what about the case where the frontend developer is going to be working on various styles that you won’t personally be touching, and they aren’t using source control during the development phase of the project?

Continue reading