In the old days, tables were your only tool. Whatever you needed to do, you created tables, nested tables, and played with table attributes. Tables could do a lot, but the final code for a complex page was all but incomprehensible, and forget trying to debug someone else's. It could be a real mess to find and fix errors, or to try to add new elements into pages.
The shift over time has been to use CSS styles applied to DIV tags. This keeps a great deal of presentation details separate from the pages, allow for page content to be developed apart from really complex styles. In addition to separating the actual code, this also provides great ways to take a page and render it completely differently based completely on the CSS applied. Content management systems in particular make extensive use of this because their individual widgets can display simple content, and the CSS applied can really change the output. This would have been a very difficult job in the old table days.
So back to CRE Loaded styles. I recently was working on putting a new template on a storefront, when one of my team members thought to look at the in IE6. The results were horrific. The site not only looked bad, elements such as the product menu just didn't show up. We ran some stats and found to our surprise that nearly 10% of potential customers coming to the store use IE6. So something had to be done.
I decided the easiest solution was to set up another domain, check the browser type, and then redirect IE6 users to the other domain. Connection information in CRE Loaded would stay the same, so both sets of users would share the same database, and the job would be trivial.
So, I searched the code and found a good place to put the IE6. The first step was the put the following in includes/application_top.php:
// first.....since IE6 performs very badly with our template....
// detect the browser and send all those poor souls to the
// old template
include('includes/browser_detect.php');
$a_browser_data = browser_detection('full');
if ( $a_browser_data[0] == 'ie' )
{
if ( $a_browser_data[1] <= 6 )
{
$url = (!empty($_SERVER['HTTPS'])) ? "https://".$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'] : "http://".$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];
$url = str_replace("www.myDomain.com", "www2.myDomain.com", $url);
header('Location: ' . $url ) ;
}
}
I found some great code to detect the browser type here. I put that code in includes/browser_detect.php.
Then I went to test, and discovered that half the time I clicked on things, I was being redirected to the old site. After some seaching, I found that the domain is actually stored in a few pages of the php script. I changed those, and then I was staying consistently in the new site. Perfect.
Next I went into the admin side of the new site, and changed the template. Oh wait. The default template is stored in the database! The database that I am sharing between the sites! Time for more analysis.
I searched and searched through the code and discovered that DEFAULT_TEMPLATE was the variable that I needed to set, but DEFAULT_TEMPLATE was not set anywhere in the code. I realized my lack of PHP knowledge was hurting me, so I started looking up constant definition in PHP. It became clear that the value was being set somewhere, but searching the codebase had turned up nothing. Then I realized there must be somewhere in the code that all the configuration variables were being pulled in from the database and constants were being created for them.
After more searching, I discovered the code I expected was in includes/application_top.php, not far from where I had inserted the above lines:
// set application wide parameters
$configuration_query = tep_db_query('select configuration_key as cfgKey, configuration_value as cfgValue from ' . TABLE_CONFIGURATION);
while ($configuration = tep_db_fetch_array($configuration_query)) {
define($configuration['cfgKey'], $configuration['cfgValue']);
}
PHP does not allow you to redefine the constants either....so there was no way to let this loop occur and then redefine the value later. Instead, you could either put an if clause in the code, look for DEFAULT_TEMPLATE, and set the value there, or instead set your override value first, then check as you are looping to see if the value is already defined, and only define it if it is not. It was late at night, so I chose the first. The more bulletproof way would really be to set up an include to define overrides and then put the conditional logic in this loop to skip any values that are currently defined. When I have some free time I will definitely refactor this code.
Anyone ever try to do anything like this? Let me know if you had a better solution. Thanks!
