Title: Debugging help for widgetized theme
Last modified: August 19, 2016

---

# Debugging help for widgetized theme

 *  Resolved [davidedw](https://wordpress.org/support/users/davidedw/)
 * (@davidedw)
 * [16 years, 7 months ago](https://wordpress.org/support/topic/debugging-help-for-widgetized-theme/)
 * Hi, I am using a custom theme on [my blog](http://davidedwardsphotos.com/blog).
   I wanted to “widgetize” the theme, but I’m finding my [widgetized version](http://davidedwardsphotos.com/test_blog)
   does not find any pages. For example on the normal blog, the default page shown
   is generated from home.php in my theme. In the new theme, the default page is
   not found, it goes to the fallback index.php.
 * I have not changed any WP settings, just the theme:
    - I added a custom **functions.php** to my theme directory. It only contains
      the definition of the new sidebars. I know this is being loaded, as WP admin
      prompts me to define the new sidebars, and I can see one of the custom (widegetized)
      sidebars on the index.php page displayed.
    - I set each of the **sidebar-\*\*\*.php** files to use the _<?php if ( !function\
      _exists(‘dynamic\_sidebar’) || !dynamic\_sidebar(‘Single Sidebar’) ) : ?>_
      checks. Again I suspect this is working as the widgetized sidebar is being
      displayed.
    - Each of the theme php files (e.g. page.php and index.php) have the appropriate_
      <?php get\_sidebar( ‘home’ ); ?>_.
 * I can’t see any php errors generated, nor is there anything in the http error
   log. The problem seems to be in the routing between entering a url of davidedwardsphotos.
   com/test_blog and the correct home page (or any specific page entered) not being
   found.
 * Any advice on how to debug this?

Viewing 1 replies (of 1 total)

 *  Thread Starter [davidedw](https://wordpress.org/support/users/davidedw/)
 * (@davidedw)
 * [16 years, 7 months ago](https://wordpress.org/support/topic/debugging-help-for-widgetized-theme/#post-1181375)
 * I have found and resolved the problem. See the post [“Spurious $GLOBALS name attribute caused 404 with widgetized theme”](http://wordpress.org/support/topic/302894).
   You might also want to look at another post of mine [“Understanding WordPress Flow – from URL to page”](http://wordpress.org/support/topic/302141).
 * In the end I used a fairly standard debugging approach:
    1. Identify what has changed (in this case the changes were well known, listed 
       above),
    2. Compare the behaviour between the (old) working theme and the (new) broken theme,
       and
    3. Trace through the code using statements/variables written to the PHP log to 
       determine where the point of change was between the working and broken theme
       behaviour.
 * If you’re familiar with the Kepner-Tregoe method, any changed behaviour must 
   be linked to changes in the environment. This was certainly the case here; I 
   knew I’d introduced the new functions.php file and some custom sidebars as well
   as changing the template files.
 * I was able to see that the query being sent to the DB to build the page involved
   the following variables:
 *     ```
       URI: //test_blog/testing-page-category/page/2
       query_string: paged=2&name=Search%20Sidebar&pagename=testing-page-category
       request:  SELECT   wp_posts.* FROM wp_posts  WHERE 1=1  AND wp_posts.post_name = 'search-sidebar' AND wp_posts.post_type = 'post'  ORDER BY wp_posts.post_date DESC
       ```
   
 * The corresponding variables for the working theme were:
 *     ```
       URI: //test_blog/testing-page-category/page/2
       query_string: paged=2&pagename=testing-page-category
       request:  SELECT   wp_posts.* FROM wp_posts  WHERE 1=1  AND (wp_posts.ID = '264') AND wp_posts.post_type = 'page'  ORDER BY wp_posts.post_date DESC
       ```
   
 * Obviously the request coming in from the HTTP server and passed in from the PHP
   processor (the URI) was correct, but between there and building the DB SQL statement
   something was screwed up.
 * So debugging was a matter of determining where in the code the behaviour changed.
   I used the error_log() function to write statements/arguments to the PHP error
   log. For example:
 *     ```
       $dae_error = ">>>> 9a. Name: " . $name . " global name: " . $GLOBALS['name'];
       error_log($dae_error, 0);
       ```
   
 * I then traced back up the code flow from the wrong SQL statement, placing error_log()
   statements to find the point of change.
 * The problem was a global variable somehow being set in my custom functions.php
   file (see [“Spurious $GLOBALS name attribute caused 404 with widgetized theme”](http://wordpress.org/support/topic/302894)).
 * This was a very slow process, and I’m sure the developers have a more efficient
   mechanism. But it did give me a good understanding of how WordPress is built.

Viewing 1 replies (of 1 total)

The topic ‘Debugging help for widgetized theme’ is closed to new replies.

## Tags

 * [debugging](https://wordpress.org/support/topic-tag/debugging/)
 * [home](https://wordpress.org/support/topic-tag/home/)
 * [widgets](https://wordpress.org/support/topic-tag/widgets/)

 * In: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
 * 1 reply
 * 1 participant
 * Last reply from: [davidedw](https://wordpress.org/support/users/davidedw/)
 * Last activity: [16 years, 7 months ago](https://wordpress.org/support/topic/debugging-help-for-widgetized-theme/#post-1181375)
 * Status: resolved

## Topics

### Topics with no replies

### Non-support topics

### Resolved topics

### Unresolved topics

### All topics