[wp-testers] Can we delete this code from classes.php?

Ercin Dedeoglu - ercin.info ercin at ercin.info
Mon Feb 6 10:52:44 GMT 2006


Remove me...

-----Original Message-----
From: wp-testers-bounces at lists.automattic.com
[mailto:wp-testers-bounces at lists.automattic.com] On Behalf Of Kirk
Steffensen
Sent: Thursday, February 02, 2006 12:49 AM
To: wp-testers at lists.automattic.com
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
wp-testers at lists.automattic.com
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




More information about the wp-testers mailing list