Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: debug

  • C’mon Get Trac’in!

    C’mon Get Trac’in!

    After every major WordPress release I trawl the forums and look for new superstars. I usually find one or two people who, like I did five years ago, catapult themselves into the stratosphere by taking notice of issues of communication and correcting them. That’s how that OMGWTFBBQ post was born! WordPress 3.0 dropped with a lot of changes and people lost their minds. That’s the best part of a complex release.

    Screaming face in a muralThe worst part is people losing their minds in the wrong places.

    Oh there’s nothing wrong with going batty over a change or reporting something is broken. What’s wrong is when you go into a half-dozen similar posts and repeat the exact same rant. Much like the superstars who get noticed because they’re being helpful, when you spam-rant, you become noticed in a bad way.

    No release is perfect, and WordPress’ ideology of ‘Release and iterate!’ means that we know we’ll have missed something, or not totally finished another, and it’s not everything we want yet, but also that the fastest way to get ready is to get more people poking at it and breaking it. This means we know things aren’t perfect, but it doesn’t mean we ship broken code. Still, change breaks things, and some of those things are outside our control (like TinyMCE 4 changed how it implements a lot of things).

    Naturally though, big changes cause loud complaints. For people who shout and demand to know why we had to change, the problem is where they do it, not so much how and with what language. The where problem is that someone will post a rant in a bunch of similar posts, or create a trac ticket when they haven’t done any debugging.

    It’s pretty easy to remember that the support forums are not your personal soapbox to stand on and shout about how much everyone sucks (or is awesome, I know). The forums are a place to describe your problem and get help.

    So … How DO you know when it’s time to get trac-a-lacking and make a ticket, and when it’s not?

    Is it just you?

    A quick search of the forums will tell you if you’re the only one with an issue. If you see one or two other people with similar issues, read deeper. Similar is not the same, so just because you both have a white-screen-of-death on the post editor does not mean it’s the same bug.

    Did you do the needful testing?

    Have you tried:

    • 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 `twenty fourteen`. That will force your site to use it.
    • manually upgrading. When all else fails, download a fresh copy of the latest.zip file of WordPress 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.

    (Can you tell I use that a lot?)

    Follow Trac

    Does it happen on a clean install?

    The best testers test on a test site. Even on my personal, I don’t code on it, laptop, I keep a copy of MAMP handy, as well as a pure test site on a live server. But I’m weird. Still, if you’re even considering making a trac ticket, have a test site and test it there before you click that ‘new ticket’ button. It may feel like an extra hurdle, but having that clean test will make sure you’re not losing your mind sometimes.

    Have you asked anyone else about it?

    I admit, this works better if you know people, but if you do know someone, just ask. I bug my coworkers sometimes “Hey, do you see this? No? Okay…” It helps me sort out if I’m being crazy or not, and sometimes just asking “Anyone know why I might get this error…?” gets amazing results. Again, this works best if you have a network already, so don’t worry about this too much.

    Hope you’re right…

    Even I don’t know if it’s right to make a ticket all the time. I hesitate over those buttons a lot, and often delete the whole thing. It’s not super simple to know, so you have to make your best guess.

  • Resilient Responses in Reviews

    Resilient Responses in Reviews

    I review a lot of code. A lot.

    ALOTOn average, I look at around 100 plugins and themes (combined) per day. If I’m not reviewing code for the WPORG plugin repository, I’m debugging sites for customers, writing my own code to make it better, testing patches for WordPress, and pretty much dancing the dance a lot. I like this sort of thing a lot, since I get to see all sorts of different methods to madness, and it improves my abilities to see people doing it right and wrong.

    That said, I’m not the best coder in the universe. I don’t claim to be, I don’t plan to be, and I don’t worry that I’m not. We all have our skills and mine is not to be a psycho awesome super coder. Mine is debugging, breaking, helping people debug and break, and writing. We call that support, generally, and it’s a noble profession! But more on that another day. The fact is I don’t know all the code in WordPress. I’m guilty of doing_it_wrong() often enough. And yet, I don’t see my ignorance to be a detriment to what I do.

    In an article “Probability and Possibilities”, my father talks about how we react to natural disasters, and how that impacts how we predict them, and their costs. Near the end, he talks about being prepared by having resilient responses, and lists the following traits of those people/groups:

    1. Drawing on experience
    2. Questioning that experience
    3. Intuition
    4. Improvisation, or making the most of materials at hand
    5. Listening and speaking
    6. Examining preconceptions
    7. Ignorance + knowledge = wisdom
    8. Recognizing and taking advantage of luck

    Alot of BugsI didn’t realize it at the time, but my dad raised me to be resilient, because those eight traits are ones I apply constantly to my code reviews. It’s because of those that I’m able to do all those plugin reviews, even when I don’t know all the right moves. As a senator once said, I know it when I see it.

    Many times, I’ll review a plugin and flag it saying “This is not secure” or “This is not done properly” and sometimes I’ll take a moment to explain exactly why, but given the sheer volume of reviews I need to get through to keep up my end of the review process I will often use some standard ‘predefined’ replies. I don’t review all plugins, nor do I reply to all the emails, though sometimes I know it looks like I do. Still, if one person has to review 25 plugins a day, and craft a reply for half of them (yes, about half the plugins we get need some sort of reply that isn’t ‘approved!’), how am I, a non-uber coder, capable of actually knowing that the code is wrong?

    I’m going to tell you the biggest secret of support ever. You ready?

    You don’t have to know how to fix what’s wrong to know that it is, in fact, wrong.

    That’s it. Not knowing how to fix things was, I admit, one of the leading causes as to the impostor syndrome feelings I had when writing my WordPress Plugin Support ebook. But the thing was, I knew that the code was right or wrong most of the time. Oh, sure, I make a couple mistakes, but if I see someone calling wp-load.php directly in their code, I’ll tell them it’s not permitted and then they get a canned reply as to why, with some general suggestions.

    I stopped worrying about not being able to help someone debug their own plugin for a couple reasons, though. It’s (generally) not my job to help you write your own code. If you have a jquery conflict or need help calling WP functions outside of WP (please don’t), I can help you with a search or suggestions where to ask, but just because I don’t know the answer doesn’t make my telling you that you’re not permitted to do something in the WPORG repository invalid.

    Ah, there’s the crux isn’t it? Someone was doing code in a totally janky way. It happens. Most of the time, we end up doing this by accident, not knowing there’s already a WP function or action to use for it. We reinvent the wheel by accident. Let’s pretend this guy was using his own copy of jQuery. Now, as we all know, you don’t need to do that! WordPress comes with jQuery and you can just enqueue it. So there’s a canned email we send, explaining you can’t include your own, nor can you call it remotely, please use ours.

    The reply comes back “My code won’t work without my own.”

    So I reply to the effect of “Please correct your code to work with our version of jQuery. The most common cause of these conflicts is not writing your code to work in no-conflict mode.” And then there was a series of links.

    He replied, “Why don’t you just tell me what I did wrong?”

    Alot of PatchesI explained I would if I could. But I don’t know his code, I’m not awesome at jQuery, I don’t care to reverse engineer everything to figure out exactly what’s broken, and it’s not my plugin anyway. So … no. I don’t know how to fix it, but I do know that, having listened to a lot of smart people and having read a lot of code, that the primary cause is an issue with no-conflict mode. So I can Google that and get wp_enqueue_script() – jQuery noConflict Wrappers as a hit (this is the WordPress Codex) and read that this happens if you use the $ shortcut, so I take a second look at his code, determine this is the case (though perhaps not the cause of all issues), and reply back with that info and a link. I’m helpful.

    He doesn’t agree. “If you know so much, you should fix it.”

    No, sorry. This time I explain I don’t know much more than that as I’m not great with JS yet, and now I expect to get smarmy commentary on how, if I don’t know how to fix it, I don’t have the right to tell him it’s wrong. After all, I’ve heard that a hundred times before. Instead, this guy says “Yeah, I don’t know either, so who am I to judge? Okay, any suggestions where to ask for help?” After picking my jaw off the floor, I sent him to wp-hackers and stack-exchange, after doing a quick search to see what other direct links might help, including one on SE that looked like the absolute answer. He came back, said the SE answer was it, and everyone was happy!

    I solved the issue by being resilient, and giving the ultimate support. Also now the guy has the tools to do it himself next time.

  • Not The Bug I Expected

    Not The Bug I Expected

    “Comments aren’t working,” he said and I winced. I hate when people say ‘broken’ or ‘not working’ because I don’t magically know what they mean by ‘working.’ But this guy was a coworker whom I like and trust so I asked what he meant by not working, and he said “When you enter a comment, the page reloads, but there’s no comment.”

    “Okay,” I muttered to myself. “Touché, Mika.” Because that, indeed, was ‘not working.’ We turned on debugging and got a strange error:

    WordPress database error: [Duplicate entry '0' for key 'PRIMARY']
    INSERT INTO `wp_comments` (`comment_post_ID`,`comment_author`,`comment_author_email`,`comment_author_url`,`comment_author_IP`,`comment_date`,`comment_date_gmt`,`comment_content`,`comment_karma`,`comment_approved`,`comment_agent`,`comment_type`,`comment_parent`,`user_id`) VALUES (507,'lori','admin@example.com','','12.248.40.138','2014-02-07 23:07:08','2014-02-07 23:07:08','test',0,'1','Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Firefox/26.0','',0,1)
    

    And then it was a mess of ‘Trying to get property of a non-object…’ and ‘headers already sent.’

    After some kicking of the usual suspects (reinstall WP, remove plugins, theme, etc) I realized I was stupid and the problem was that the table wasn’t updating the primary entry. It should start at 1 and move up to 2 and so on. Since everything else was working, I compared the table to a working one … and they were not the same. Here’s a good one:

    Example of good wp_comments table

    There’s had comment_id as the name, and the rest of the values were blank. So I restored the values and it worked! Except … I was getting a new error.

    Notice: Undefined property: stdClass::$comment_ID in /home/wp-includes/comment.php on line 155
    
    Warning: Cannot modify header information - headers already sent by (output started at /home/wp-includes/comment.php:155) in /home/wp-includes/pluggable.php on line 896
    

    Ladybug on a leaf

    I stared at that for a moment and after I had given up and proposed we reinstall WP and copy tables over, my brain kicked in and I said “Wait a second, isn’t that comment_ID and not id?” I changed it on a whim and shouted “HOLY **** I AM GOOD!”

    Yes, it was in all caps. Yes, it was said to my coworker, who said I have his vote.

    That was, by far, the weirdest error I’ve seen in months. And the moral of all this? You can’t know everything, but if you read and pay attention and are willing to experiment, you can solve pretty much anything.

  • WordPress and the Erroneous Update Message

    WordPress and the Erroneous Update Message

    DebuggingIt’s time for a little example in debugging!

    This domain is running WordPress trunk.  When I say that, what I mean is I’m running the very latest SVN, no more than four hours behind, thanks to a cron job.  At the moment I’m writing this, I’m on revision 18690.  I did this so that I could get off by butt and actually test thing without having to think about it.  To a degree, it tells you how much trust I have in WordPress and the core commit team.  My whole site runs because they know what they’re doing.

    This doesn’t mean there aren’t errors, though.  So far I’ve been very “helpful” breaking the responsive CSS on the admin dashboard.  I’m sure Helen, Andrew and Andrew just adore me right now.  Yes, that was sarcasm.  My methodology is pretty straight forward.  Just Use WordPress on ipstenu.org.  If I find a problem, make a note and bring up my local install.  I can only do this at home, on my Mac, so usually I come home with three or four notes.  Update SVN manually on ipstenu.loc (yes) and ipstenu.org.  Is the problem still there?

    Most of the time the problem goes away.  When it doesn’t, I take a screenshot and make a trac ticket (though perhaps I should add them all to the one ticket… if any of you core folks wants to tell me, please comment away!).  I’ve also taken to popping onto the IRC channel -ui and chatting with people there before trac’ing.  Last night I found one, told someone working on the project, and she patched it right then and there.  Teamwork!

    Yesterday, I noticed my ipstenu.org site had a weird problem.  I have a subsite on the network called test.ipstenu.org (feel free to check it out).  It’s just there so when someone says “When I use this theme/plugin…” and I can quickly go look.  I make fake posts, etc etc.  It’s quite seriously just for testing.  At one point, I’d spun up bbPress on that site.  I’d since turned it off, but it was on RC4.  RC5 just came out this week, and I had an update message on only that site, telling me to upgrade it.  Instead I deleted it.  That made the update notice go away on my network dashboard, like it should, but not on test.ipstenu.org.

    Say what?

    I tried to reproduce this like mad.  I installed bbPress RC4 on my local box, activated it, left it active, deleted it, and pretty much every which way I could think of to break it.  The error only happened on that site, even though bbPress had been running on another subsite as well!  I checked on multiple browsers, and wiped cache, logged out, nuked cookies, etc. Multiple computers even! Finally I gave up and said “I need help.”

    Weird WordPress MultiSite Question

    I have a multisite and one site on that network is showing that I need to update a plugin. Every other site correctly says “No Updates!” This one doesn’t.

    I’ve poked around, but I had assumed (bad me) that the admin bar would cache that network wide, somehow. But then why is it only on one site? So I wiped and rebuilt the wp_10_options table and it still shows up.

    I haven’t the foggiest idea why it’s happening. Luckily this is only on my test site, test.ipstenu.org, but it’s maddening.

    I don’t find a huge amount of use for Google Plus, but that was great for me.  I posted, I tagged it with my WordPress circles, and went to catch my train.  It was too long for a tweet, too weird for the forums as I didn’t want people to get fussy – I’ve noticed if I raise a post, it scares people.  I guess I have ‘street cred’ on WP and some people worry when I have a problem I can’t fix right away.  Flattering.

    I got replies from Raincoaster, Brad, Ron & Andrea, and Otto, who all said “That is weird.”  Andrea pointed out that it could be caching.  Brad asked about plugins.  Otto and Ron said that if it was cached, it was network wide (which made it even weirder to only see it on one site), and then Ron told me to look in wp_sitemeta table.  I was, I admit, already looking there, but I’d gotten distracted when I found the “Add a Link” page was broken on trunk.

    Fancy Pants ManAfter Ron’s comment kicked my pants, I went to that table and thought to myself “Where are the caches?”  I knew this from ages back, that anything named _transient… was a cache.  There are tons of transient feeds in your wp_options table because the RSS feeds you see on the dashboard are cached.  Cool, right?  Well, what if, just what if one of them was corrupted?  You can delete them without hurting your site!  So I hovered my mouse over the update alert and noticed the mouseover said “1 Plugin Update.”  Then I looked at the transients and found this:

    _site_transient_update_plugins

    And I deleted it.

    And my error went away.