Remove me... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kirk Steffensen Sent: Thursday, February 02, 2006 12:49 AM To: [email protected] Subject: Re: [wp-testers] Can we delete this code from classes.php?
Andy, WPG2 gets it's coordinated look-and-feel between WP and Gallery2 in one of two ways: 1. Use a custom wpg2-header.php and/or wpg2-footer.php file, or 2. Use the current WP theme's headers and footer. If WPG2 mandated custom headers and footers, we could get away with only calling wp-config.php. But the user experience for the the average Joe user would not be great, because it's extra work to create these extra custom headers and footers. Because WPG2 calls get_header() and get_footer() to get the current WP theme headers and footers, wp-blog-header.php must be called with the current WP architecture. This gets a little convoluted, but here is the stream: 1. If WPG2 only calls wp-config.php, the key API call that is missing from wp-blog-header.php is wp(); 2. Without wp(); the WP class never gets initialized [in classes.php], and hence the WP-Query class never gets initialized [again, in classes.php]. 3. When get_header() and/or get_footer() are called [in template-functions-general.php], they in turn call load_template( TEMPLATEPATH . '/header.php'); [in functions.php] 4. In load_template(...), the extract($wp_query->query_vars); chokes because the WP-Query class was never initialized, so $wp-query doesn't exist. The bottom line is that WPG2 cannot call get_header() and get_footer() without requiring wp-blog-header.php. So that brings us back to the original question of "What is the purpose of forcing the 200 HTTP status code at the end of classes.php." I haven't been on my machine with 1.5.2 code still on it, but since this was not a problem in 1.5.2, I'm betting that this elseif statement wasn't there. It must have been put there to solve some problem. What was that problem, and how else could it be solved. It seems like the cleanest way is to capture the HTTP status code of the originating message and spit it back out at the elseif. Although I think this is the same as just eliminating the elseif, since if you never override the status code, it should stay where it was. (Unless that is the problem that the elseif was intended to solve in some specific server setups.) Your thoughts? Thanks, Kirk _______________________________________________ wp-testers mailing list [email protected] http://lists.automattic.com/mailman/listinfo/wp-testers __________ NOD32 1.1389 (20060131) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com _______________________________________________ wp-testers mailing list [email protected] http://lists.automattic.com/mailman/listinfo/wp-testers
