This is an extra special EMPIRE STRIKES BACK themed episode of the v10 redesign series!
Everything starts out just fine. We start moving some things over to our WordPress template from our static mockup. We have the header working in our static mockup, so we start with that. That’s always a great place to start because we do all that foundational work like getting the site section CSS loading conditionally and all that.
We then look at what markup already exists for the Alamanc. Pretty much the entire page is wrapped in <nav> since this homepage of the Almanac is essentially just navigation to actual content.
Then we start tinkering away with layout and building the two-page spread layout we designed in Photoshop. We use CSS gradients here to get the shadowing job done, using Compass mixins of course. Things start going a little downhill here as we struggle with getting the gradient just right.
Around the 20 minute mark in this video we start trying to output all the stuff we need to output here. Essentially, using wp_list_pages() a bunch to spit out child pages of the Almanac.
And then the world explodes! For totally inexplicable reasons, it won’t output the right stuff for us. This is an extremely frustrating moment. I like sharing this kind of thing because it’s very real-world. You know this kind of thing happens! Troubleshooting through it is part of the job.
We try Googling things. We try resetting the query. We try double checking the code. We try manipulating the parameters. We try different functions. Nothing.
We try setting define('WP_DEBUG', true); in our wp-config.php file to try and get more information. This works once we can read the text it outputs. It doesn’t help much though, until we find the out of memory error! We know the problem now, but how do we fix it?
We end this screencast totally defeated like Luke Skywalker. You might as well just tell me <table>s are my father.
One of the things I do when developing/debugging on WordPress is set the following in my
wp-config.php:define('WP_DEBUG', true); if (WP_DEBUG) { define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); define('SAVEQUERIES', true); @ini_set('display_errors',0); }This hides errors from displaying in the webpage and outputs everything to a log file in the wp-content directory named debug.log. Open debug.log in the Console.app program under
/Applications/Utilitiesand make sure Console has the preference checked to ‘Bounce the dock icon’ when an open log is updated. Now, just leave the Console open while you are coding and if you run across a WordPress error the console will bounce and you can see the error message without having to search for it in the browser. Leave the PHP Notices on so you can make sure you don’t have any, but it can get pretty noisy when you are running poorly coded plugins. (Also, don’t forget to add debug.log to your .gitignore file so it doesn’t get synced up to your live server!)