Tag: debug

Fetch As Google Failed
Once upon a time, I got an email from Google recently saying that Fetch as Google was failing for ipstenu.org.

I eyed them like they had a fifth eye. I was on ipstenu.org. I was on halfelf.org. They were clearly wrong. So I went to Google Webmasters Tools and checked out what was going on. I had a whole page that said “Temporarily unreachable.” I gave it a day. Sometimes that’s just Google being weird. But no.

After cursing a little while, I turned off all the plugins on the site and switched to the default theme. And the fetch worked. So I turned them on one at a time until it stopped.

And the moral, ladies and gentlemen, is that even though it’s been ten years of WordPress, when someone asks you to make sure you go through the normal debugging steps, you do it.
- flushing any caching plugins you might be running, as well as server and/or browser caches.
- deactivating all plugins (yes, all) to see if this resolves the problem. If this works, re-activate the plugins one by one until you find the problematic plugin(s). If you can’t get into your admin dashboard, try resetting the plugins folder by FTP or PhpMyAdmin (read “How to deactivate all plugins when you can’t log in to wp-admin” if you need help). Sometimes, an apparently inactive plugin can still cause problems. Also remember to deactivate any plugins in the mu-plugins folder. The easiest way is to rename that folder to mu-plugins-old
- switching to the Twenty Fourteen theme to rule out any theme-specific problems. If you can’t log in to change themes, you can remove the theme folders via FTP so the only one is `twentyfifteen`. That will force your site to use it.
- manually upgrading. When all else fails, download a fresh copy of the latest.zip file of WP (top right on this page) to your computer, and use that to copy up. You may need to delete the wp-admin and wp-includes folders on your server. Read the Manual Update directions first.
So yes. Do try it.
7 October, 2015
Mailbag: Finding A Rogue WordPress Setting
After helping someone track down a weird WordPress setting, he asked the logical question:

How did you even find that!?

The issue was that a person was missing the menu option to edit their themes. I asked if they were also missing the menu option for editing plugins. As soon as he said yes, I knew it had to be the define to disable the plugin and theme editor:

define( 'DISALLOW_FILE_EDIT', true );

That literally says “No editing files!” So we looked first in the wp-config.php file for it and came up empty. Now as much as we yell at people for editing functions.php or at themes for creating a mess of settings that aren’t needed, I knew the fastest way to find it was this:
```
$ grep -R 'DISALLOW_FILE_EDIT' ./wp-content/
```
And as expected, that gave me a file: ./wp-content/plugins/ninjafirewall/lib/firewall.php

Since we had wp-cli, I opened that file and looked for the term:
```
// Disable the plugin and theme editor ?
if (! empty($nfw_['nfw_options']['disallow_edit']) ) {
       define('DISALLOW_FILE_EDIT', true);
}
```
Then I ran this: wp option get nfw_options

If you don’t have wp-cli, just pop into the database and look at the option value for nfw_options — either way you’ll see this:
```
array (
  'logo' => 'https://www.example.com/wp-content/plugins/ninjafirewall/images/ninjafirewall_75.png',
  'enabled' => 1,
  [...]
  'disallow_edit' => 1,
  [...]
)
```
I’ve snipped out a lot of the data, but you can see that disallow_edit is set to 1.

We had the user change that setting. Imagine that. It worked!

The moral of the story? Don’t make settings changes without reading what they do!
4 September, 2015
Mailbag: Headers Already Sent
Yasha from Russia asks for guidance!

Hi I was searching on ways to resolve get header error in WP and saw your posts, which helped a chap with his website. I am a total beginner and having a nightmare with a divi template I am trying to upload. I have tried a ton of solutions on line and nothing worked. I would be grateful if you could provide me with some guidance. Unfortunately I am not in a position to pay you, but should our path cross I would be happy to offer you a few fine Belgian beers. Thank you in advance

I don’t drink beer (I can’t stand fizzy drinks, I know, it’s tragic).

I have to preface this with the honest truth. I hate Divi Templates. I’ve reached out to them under my company hat a couple times, never heard back, but I cannot stand their theme because of the first line in header.php for every single theme I’ve ever seen from them.
```
<?php if ( ! isset( $_SESSION ) ) session_start(); ?>
```
Pardon me while I rage flip a table.

Why do I hate this? Sessions aren’t friends with caching. A session is used to store information for a user and have it accessible across all the pages of your website. Cool, right? The problem is a session is also saying “This user gets unique content and should have a unique experience.”

Which kinda tells caching, and specifically Varnish caching, to take a long walk. WPEngine doesn’t allow you to use them because of that.

But all that aside, how do you debug that Headers Already Sent?
1. Turn on wp_debug
2. Read the error
3. Kill the plugin (or theme) causing it
I hate to say it’s that simple, but it usually is.
```
Warning: Cannot modify header information - headers already sent by (output started at /example.com/wp-content/themes/applesororanges/functions.php:60) in /example.com/wp-includes/pluggable.php on line 962
```
That error means the problem is in the theme applesororanges and you check by swapping themes.

When you get around to these, it’s a bit messier:
```
Warning: Cannot modify header information - headers already sent by (output started at /example.com/wp-includes/functions.php:3560) in /example.com/wp-includes/pluggable.php on line 962
```
The bit in ‘output started at…’ is a wp-includes folder! It’s unlikely core has bad code, so here you have to turn off all the plugins and switch to a default theme. There’s a reason that’s the way we debug, by the way. It’s hands down the fastest way to see if it’s you or not.

If turning off all the plugins fixed it, great. Now turn them back on, one at a time, until you break it again.

Remember! Sometimes it’s the combination of the plugins and theme that caused the problem, so be ready to pick a second best theme or plugin.
28 August, 2015
Mailbag: Ghost Image Errors
Once I got Ghost up and running, I got some errors and there was venting around the usual places. Image uploads were failing. I cried. Then I solved it. Then someone asked a logical question.

How did you fix the image upload issue?

What happened was that I found I was getting a Wiggly Cat whenever I uploaded an image. Eventually the upload failed.

The cat bounced up and down. My wife eyed it and said “That’s not much of a chuffing SOS now, is it?” (no, she’s not British, but what else can you say about that?). Thankfully, after years of WordPress support I went right into the file system and checked if the images were being uploaded at all. Answer? Sort of.
```
$ ls -lah
total 0
drwxr-xr-x 2 elfghost elfgroup 131 Apr 15 17:22 .
drwxr-xr-x 3 elfghost elfgroup  23 Apr 15 17:12 ..
-rw-r--r-- 1 elfghost elfgroup   0 Apr 15 17:13 f4c134eb021e026414a1bd23d3c5c927-1.jpeg
-rw-r--r-- 1 elfghost elfgroup   0 Apr 15 17:12 f4c134eb021e026414a1bd23d3c5c927.jpeg
-rw-r--r-- 1 elfghost elfgroup   0 Apr 15 17:22 unicorn.jpeg
```
0 bytes isn’t right. But again, WordPress support history to the rescue. I checked my /tmp folder, saw it was full, turfed the entire thing, and the upload worked. Rather fast, too, since it’s not making an image resizes. I will note, had that fix failed, I’d have started playing with folder permissions, but since I got the 0-byte version, I was reasonably sure that wasn’t my issue.

Two humor tidbits for you.

Bing thinks I write in Turkish:

Here’s a cute bouncing cat:

Pusheen The Cat
8 May, 2015
Beta Testers
There’s a weird aspect to open source that can be hard to explain, and that is the ethos and practicality of Beta Testing. Beta Testing is one of the most important aspects of open source, because it’s only with the beta that we’re able to real-world test products. No matter how much planning and testing and automated tests you write, there is nothing quite as powerful as the real-world. We just can’t reproduce it well enough because, among other things, we can’t yet predict humans very well. Sure, cold reading is a thing because humans can be predictable, but that doesn’t mean we know how a tool will be used 100% of the time.

And being a beta tester is hard work. You have to be both a user and a developer, which are really two totally divergent mindsets. Testing as a user versus testing as a developer is as different as how you and a formula one racer drives a car. Input from both the users and the developers is critical to the growth of a project and the end results. But before we get into how one really betas, we have to ask a very important set of questions.

Should I be a Beta Tester?
- Are you brand new to the project?
- Do you use the products daily (or close enough)?
- Do you know how to manually clean up a bad install without losing your data?
- Do you make regular backups?
- Do you know the basic troubleshooting steps for the product like the back of your hand?
- Are you willing to test on your live site?
If you answered ‘no’ or ‘maybe’ to any of those questions, then you’re not yet ready to be an effective beta tester.

That last one may catch people by surprise. Testing on your live site is something we actually tell people not to do, but I’m here to tell you that the best beta testers are either testing on their live site or on a site they use every single day. Since I have multiple site I use daily, I picked the one I can live with if it dies and I use that for my live-beta.

Guess what? You’re on it right now. It’s a hallmark of how much trust I have in WordPress. I can count the issues I’ve had on one hand since I started this a few years ago. I make a backup every day, twice a day, and I have it in three locations. If my site goes down, I lose at most 12 hours of content, and for what I’m doing here, that’s okay. My other sites, I could not deal with that loss and thus I use stable. But I test with live because… well let me explain.

How do I test?

If you’re going to be a beta tester, then the you install the beta and you use the product.

You were expecting rocket science?

Most projects have a lot of automated tests and they’ll test what they know about and what they can. But absolutely nothing replicates real world use. The whole reason I test with a live site, and why I feel it’s important, is that this is as real as it gets. This site is updated regularly with plugins and theme changes. I add new content five times a week on the same Multisite installation. I add new content multiple times a day on another site. One is on trunk, one is not. This lets me constantly compare the experience between the two and makes me immediately aware that something is different. If it gets my attention, that’s important.

What I do with my site is equally important. I’m writing content, constantly, which means I’m using some of the fundamental, day to day features that WordPress absolutely must have. That kind of user testing cannot be scripted. There is no AI yet that can reproduce what machinations a human gets up to.

I like to tell a story about the time my coworker John and I were testing some tax software for the bank. We ran it through it’s paces, putting in data, and every time we tries to save at a certain point, the software crashed. It crashed hard. We called the vendor and talked to them about it, walking them through what we did, and lo, it crashed again. They couldn’t reproduce it, so we screen-recorded it and sent it over. They were astounded and sent out a tech from New York to Chicago to work on this. He couldn’t solve it, but he did see how we crashed it. Then they sent in their big guns, their lead developer, and he sat down and watched us. As soon as it crashed he said he knew what the problem was.

We were doing it wrong. We were entering bad data in a way no tax professional ever would, the system was trying to process the math and, because the logic was bad, it crashed. I pointed out that people would make mistakes and he agreed, saying it should have alerted us to an error in the form, not try to process anyway. A few days later, he sent us a new version which properly trapped the error.

While a scripted test might have caught that by looking for bad values before mathing, they were doing the obvious check. They checked if it was a number. They neglected to check if it was a permitted number. If you’ve ever heard me nag someone about proper data sanitization and validation, this is why. They made a code change, added it into their scripted tests, and learned and grew. But they couldn’t have done that without a real human thinking in a different, and unexpected way.

We can, and will, improve scripted tests, but they will never improve to perfection because humans are pretty crazy. Which leads us to the next step.

How to I report a bug?

This is generic for a reason.

First, make sure you can reproduce the bug. Get a clean build to test on and go through the steps again. If you’re not sure about the steps, make a note to yourself about generally what you remember and try it again. If you can’t reproduce it, call it a one-off and let it go (and debug for yourself, but that’s different). Once you can reproduce it on a clean build, document those steps.

You’re going to want to answer these questions:
- What were you doing?
- What did you expect to happen?
- What happened?
- What research did you do into the error?
- How do you reproduce it reliably?
Include any error messages. Explain what you did. Don’t say “It didn’t upload.” Instead, say “The upload hung, making no further changes on the page. I waited 15 minutes before hitting refresh. When I checked the media library, I saw the image was uploaded however when I looked at the file server, none of the thumbnails were there.”

This is why you need to know what you’re testing. With a failed image upload on WordPress, you should know that the image uploads and then it makes the resized images. Even if you don’t know that, you should know your images are in wp-content/uploads/2015/02/ and you should look there to see if you can find them. If you have a failed post, you should know to look at the post list page in WP Admin and see if the post is listed there.

You’ll get extra bonus points if you can find your PHP error logs and share pertinent information, but that isn’t always easy. When you reproduce the error, make sure you specify if anything special has to happen. Like if the image upload only fails if you’re uploading a PNG, note that. Or maybe it only fails on pages, but not posts. How weird is that, right? Note it.

Don’t worry about being technical here. Be accurate, be clear spoken, and assume the other person is relatively new at whatever you’ve broken. Don’t assume they know exactly what you mean when you said “Upload an image…” Be specific and say “Create a new post and press the ‘Upload’ button…” If you know there are multiple ways to upload an image, test those other ways. It’s a due diligence thing.

After you’ve reported the issue, keep informed. Make sure you get email alerts for it, make sure you reply to those emails for it. You can’t just report it and walk away, you have to keep tabs and pay attention. People may need you to clarify information and explain problems in different ways. Remember people can’t actually read your mind. What’s clear to you, because you did it, may confuse them.

And finally … be prepared to hear that it’s just not that big of a deal. Sometimes a bug isn’t a bug, but an intended change. You may not like it. Heck, you may despise it, but that doesn’t make it wrong.

What else?

What are your takeaways from beta testing? How do you do it?
28 January, 2015
Single Site Login Loop

Have you ever tried to log in to WordPress and have the login page just refresh with no errors?

No, I don’t mean that Multisite Login Loop.

After upgrading a bajillion people to WordPress 4.0 on DreamHost, I noticed something a little weird. People couldn’t login and they didn’t get an error. They would put in their ID and password and the screen just refreshed. So I took a look and decided to start with the obvious tests.

Assuming that the username and password were correct, I checked what happened with a fake account and password. I put in ‘admin’ with a password of ‘areyouduckingme?’ (which no one but me would use) and expected to see a nice login error like this:

I did not. Right away I knew what was wrong. There was a miss-match with the home and site URLs!

At DreamHost, we allow you to pick if you want to force www or non-www or not at all for your domains, and I always go to check what the customer did there, just to see. If they picked ‘neither,’ then I’ll usually flip it to non-www because I hate www in your domain and I’m fixing things. Of course, if they have set it to www or no-www, I make a note and honor that.

Then I go check the home and site URL and make sure they’re both the same in so far as the domain does. If one is www.domain.com and the other is just domain.com, and 50% of the time, it was this all along. The other 50% is that WordPress thinks it should have www and the domain settings think it should not. The point here is that everything needs to match up nicely when it comes to your domains.

It’s also a good idea to check the .htaccess to see if they’re forcing it one way or the other in there (I do).

And you’re done. Refresh the page, see if you can login. Should be magic.

Of course the question is then why did this happen, and the answer is that WordPress is trying to make it harder for people to break into your site. Part of these means making sure that cookies match domains properly, and when you have an inconsistency like www.domain.com and domain.com, the cookie is invalid and WordPress doesn’t know where to go. It wants to go to one but gets tossed to the other.

29 September, 2014