Make WordPress AJAX Calls Cacheable and Improve WordPress Performance

WordPress Developers frequently make a very tiny but critical mistake when implementing wp_ajax calls that degrades WordPress performance and the scalability of  their website in cloud environments.

For instance, Daniel Pataki at WPMU offers a very clear and easy to follow tutorial on using the wp_ajax hook to make your web pages more dynamic. His example loads additional posts via an ajax-based pagination script. Very cool and very handy. Not only will it make you site more fun to use but also reduce overall server usage because the ajax call will be lighter weight than a full page view.

But once your site is on a modern cloud hosting infrastructure like WP Engine or Pantheon or Pagely, Daniel’s implementation will actually impede the performance benefits offered by these higher end hosts.

POST Requests Degrade WordPress Performance

Cloud hosts are usually running some sort of caching or “proxy”, usually Varnish, which dramatically speeds up your site load time. But POST requests are not going to get cached because it’s assumed that when POST’ing to a site your are performing a critical action like saving/submitting data.

But in the pagination example you’re just looking up what should be cacheable data. A GET request would allow the Varnish layer to serve that from cache much faster than would otherwise be possible. This also preserves your php resources for requests that actually need them and improves overall WordPress Performance.

Making this change is super simple (

 			url: ajaxpagination.ajaxurl,
-			type: 'post',
+			type: 'get',
 			data: {
 				action: 'ajax_pagination',
 				query_vars: ajaxpagination.query_vars,

Some links and stuff

Moving sucks. We moved to a new apartment over the weekend and there’s just so many ways in which moving sucks. The mess, the disruption, the cleaning, discovering how dirty you really are after all your crap is removed, the cleaning, the mess, the lifting, the dusting, the cost, the cleaning. You get the idea. So I’ve nothing of worth to tell you this morning.

But Brian Gardner does, he’s thinking a lot about minimalism … which rocks. But the whole “no-sidebar” makes me nervous. What if I want to sell ads? what if … what if? Come to think about it my sidebar has been a big pain in my ass from day one. Hmm. Let’s see.

Also this is really cool if you like SVG stuff.

Finally, I was reminded how awful the 80s were this morning:

Getting rid of .git untracked file errors with git clean

The following untracked working tree files would be overwritten by checkout:

Nothing drives me crazier than trying checkout a git branch and getting this error.

$ git checkout develop
error: The following untracked working tree files would be overwritten by checkout:
Please move or remove them before you can switch branches.

This usually happens to me when something in my application creates cache files and the git ignore wasn’t configured. So there are several different ways to solve this depending on what you want to do.

If you want to keep the files just commit them like the warning prompts you to. In this case:

git add tests/fixtures/
git commit -m "Adding fixture files" tests/fixtures/

But sometimes you don’t want to keep them so you delete the file with:

rm -rf tests/fixtures/5e1c60f7048c2630c76c7e268ed7ad55

But then you just get the same error for another file in the same directory. You can’t delete the whole directory because there are some files in it that ARE committed and need to be kept.

What I learned today is that you can use git’s ‘clean’ function to remove these.

git clean -f tests/fixtures/

The -f flag here will force delete all of the untracked files in that directory. Alternatively if you want to be more careful you can use -i for an interactive prompt:

$ git clean -i tests/
Would remove the following items:
  tests/test-input-helper.php   tests/test-site-workflow.php
*** Commands ***
    1: clean                2: filter by pattern    3: select by numbers    4: ask each             5: quit
    6: help
What now> 5

How to Be a Good WordPress Developer?

Pippin has some thoughts. I concur with most of them, especially the one about challenging yourself. The best self-taught developers are those who become obsessed with solving problems. They can’t stop themselves. They might get discouraged and walk away from the computer in disgust. But a few minutes later they’ll think “but I haven’t try this” and be right back at it.

Good developers surround themselves with people who know more than they do. They have no real desire to show how smart they are but would rather learn something smart from others. If you can let your pride go and be ok being the dumbest person in a room full of the smartest people ( as opposed to being the smartest in the room ) you’ll be better than you’d ever imagined otherwise. Plus people will like working with you which helps .

If your looking for a more “skill” based assessment of what it takes to be a developer, this is a pretty good article. Specifically, I like the notion of “problem decomposition,” which is a fancy way to say troubleshooting.

A key aspect of solving a problem ( and thus being a good developer ) is not getting handcuffed by what you don’t know. Obviously, if you knew you wouldn’t have a problem. But just because you don’t know what is causing a specific issue doesn’t mean you know nothing. I often start troubleshooting by clarifying and confirming what I do know.

For instance,  if WordPress gives me an “Error establishing a database connection” screen: What do I know? Do I know my username and password are correct? Can I confirm that by connecting to mysql via the command line or PhpMyAdmin? Do I know that mysql is running on the server?  Again does phpmyadmin work? Does my hosting dashboard have a mysql “status” icon”? Or does <code>service mysql status</code> return something? So on and so forth.

Confirming what you know sometimes exposes that what you think you know may not actually be true. And if it is true, it helps you focus your theories of the problem on areas that really are unknown. Like anything else, the more you decompose problems the better you’ll be at it.

WordPress Signal/Noise Ratio

I’ve decided to air some grievances about trends in the WordPress community that have me annoyed. Yesterday, I raised the issue of “freemium” plugins in the WordPress Repository. Today I want to bitch about the #wordpress twitter stream. There was a time when you could follow #wordpress and find real people exchanging ideas or asking questions or linking tutorials. It seems now though the community is a victim of it’s own success. To demonstrate my point yesterday I went through the first 50 tweets and broke them down by function:

34 tweets were directly selling something. And example might be

Visual Themify #Builder #WordPress #Plugin True #Drag #Drop #ThemeBuilder Design. Front- and Backend Design https://link/link

The link in the tweet above actually takes you to a hosting company website which is a bit misleading.

23 tweets were soft-selling. By this I mean they were tweets by a company to a blog post that was indirectly promoting their business or products. This is obviously preferable to the direct sell, but it still has some issues. For one thing, the quality of the content leaves much to be desired. I don’t find an article on “building an ecommerce site” that just lists a bunch of super-obvious steps, “First you need a domain, here’s a link to the domain affiliate that I profit from,” to be particularly valuable.

Only 3 articles had no obvious sales angle. This is a pathetic number. What’s worse is that many of the direct-sell tweets are just repeats of each other. At least 8 tweets ultimately linked back to one theme on the Envato Marketplace.

To be fair some of the issue here is without a doubt an issue with Twitter, not WordPress. And It’s hardly reasonable to expect WordPress to somehow curate the hashtag.

My concern though is that it is somewhat indicative of a trend in the WordPress ecosystem: it’s getting increasingly difficult to separate the cream from the crap.

Idea’s on this would be welcome.

It’s Time WordPress Establish Some Rules For Freemium Plugins

I’m not against developers providing “freemium” plugins in the official WordPress repository. By freemium, I mean a plugin that has some functionality restricted to entice you to purchase a license or premium version. Heck, I used to sell such a plugin myself.

But I do think it’s time for to enforce some general rules about how it’s handled. Two changes I would like to see that I think would be relatively easy to establish ( if not to enforce ).

  1. Take Apple’s lead in flagging apps that offer “in-app purchases” in the plugin directory. That way it’s immediately and visually discernible which plugins are fully functional and free and which are up-sellers. Ideally this would include the ability to hide freemiums in search results if desired.
  2. Nags to “upgrade” or “join” or respond to a survey–or any other sale related nag–should only appear in certain areas of the site. Obviously the plugin admin page is a reasonable place for the nags to happen. Maybe on the dashboard. But I should not experience nags on every page of the admin area. For example, the Types plugin:
    Screen Shot 2015-01-12 at 9.45.29 AM

What I don’t know

Inspired by Terry Beyak, I thought I’d write my own list of things I don’t know. I should specify this will be an abridged list of “known unknowns” as opposed to “unknown unknows”, of which making a list would be impossible.

  1. Ruby on Rails
  2. Swift / iOS Development
  3. Java / Android Development
  4. The meaning of life
  5. NoSQL Databases like Mongo/Cassandra
  6. system.d
  7. AngularJS
  8. The best places to hike
  9. All the tree species in Sonoma County