One of the things that’s often brought to my attention is that people see the ERR_SPDY_PROTOCOL_ERROR whenever they try to access this site.
I’ve had people respond to links from my newsletter, from links on Twitter, from links from third-party sites, and sharing their experiences when trying to access other sites, too.
The thing is, few people – myself included – seemed to be able to diagnose the problem. (And believe me when I say that I’ve tried a ton of different things to fix it on my end.)
So to the best my ability, I researched the problem, all possible fixes, and thought I’d share what I found here along with the fixes.
Often, there are little idiosyncrasies that come with learning anything new. Thus, an IDE is no different.
And when it comes to learning a new IDE and how to use a debugger with it, there can often be small things that need to be adjusted or configured so that they help streamline your development.
For me, it comes with some of the default behavior of Xdebug. That is, if you’ve ever installed a new IDE and set it up to use Xdebug, you’ve likely experienced the behavior of having it start on the very first line of your web server or your application.
And this can be an annoying albeit preventable setting. If you’re using PhpStorm, here’s an easy way to fix it.
If you’ve worked with Ajax in any capacity, then you’ve likely tried to send response data using various formats. Obviously, the original format of the response data is XML but JSON is a second, [and arguably] more popular format.
When working with WordPress’ Ajax API, arguably, the most important things to remember are:
- Make sure the function is using the proper hook (should it be available for the public, for users who are logged into their account, or both?),
- Terminate the function using wp_die unless you want an incorrect or malformed response sent to the client.
In addition to that, if you’re sending your response data to the client in the form of JSON then you have several options on how to return the data:
- Structure the JSON data yourself (which I think would be an overly complicated feat 🙂),
- Use PHP’s json_encode function,
- Or use WordPress’ wp_json_encode function.
You can see there this is going, right? So I’ll make it quick.
One thing about the output the PHP CodeSniffer is it tells you the line number where your problem exists. This feature has obvious benefits – it lets you know exactly where you need to jump to fix the problem.
Our projects, though, are usually a wide set of files with a lot of functions and thus a lot of lines of code. If you’re proficient with your IDE, then it’s a trivial task to hop to the file and the line number.
But what if you’ve migrated to a new IDE or you’re not sure of the shortcuts that exist in your current IDE? That is, maybe you know how to click to find the feature, but using shortcuts is so much faster, isn’t it?
Most developers in the WordPress space have their favorite IDE of choice. Ask around and you’re likely to hear people share their favorite editors being:
And these are all great options. For what it’s worth, I dig the fact that we have choices when it comes to the tools with which we work.
But I’ve been a fan of Coda ever since I moved to Mac. This doesn’t mean it’s not without its shortcomings. For example, I use a third-party application to do debugging but it’s not that big of a deal.
Anyway, one of the things that I’ve noticed with people who opt to use Coda don’t use it to its fullest extent. That is, there are a lot of features I see other developers opt not to use (like the database front-end).
I don’t know if it’s because they don’t know it exists or because old habits die hard. Either way, another example that I rarely see is the terminal in Coda 2.