WordPress.org

1. davidedw
   Member
   Posted 2 years ago #

   Hi, I am using a custom theme on my blog. I wanted to "widgetize" the theme, but I'm finding my widgetized version 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?

2. davidedw
   Member
   Posted 2 years ago #

   I have found and resolved the problem. See the post "Spurious $GLOBALS name attribute caused 404 with widgetized theme". You might also want to look at another post of mine "Understanding WordPress Flow - from URL to page".

   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").

   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.

Topic Closed

This topic has been closed to new replies.