2.3.2 update killed my store

[Guest]

I updated to the 2.3.2 update from 2.3.1.1. Now all I get when I try to open my store in my browser is a blank page. This is on my dev store. I went through all the instructions again and even did a file-compare to the full 2.3.2 installation files. They were all identical other than a few spacing changes. I changed everything back using file-compare with my live store and it worked again. Then I went through the instructions again and made sure I followed it to the letter. Now I am back to the blank page.

 

I have gone over every file checking for un-closed tags, etc. and have found nothing that should cause this. The general.php file changes were the same as the ones I had already done as part of the 2.3.1.1 update, but those are the only ones I can see that could break the whole store. Wouldn't the others only have an effect if I had tried to log in or forgot my password?

 

Anybody have an idea what to look for?

[Guest]

UPDATE: I did another file comparison and this is what I found:

 

admin/includes/functions/general.php - identical

admin/includes/classes/passwordhash.php - identical, other than spacing

includes/classes/passwordhash.php - identical, other than spacing

includes/functions/general.php - identical

 

So that led me to think the problem is with one of the others. However, I made a few minor (I thought) changes to the spacing (extra spaces before a line of code) to one of the pages listed above and the front end now works ( I also did a little spacing changing on password_forgotten.php). The back end is still a blank page.

 

Is it possible that a few spaces used to format the code could cause this? I don't think I changed anything else.

 

CORRECTION: The front end does not work. Why it suddenly came back up correctly once but not the next time I don't know. Anybody have an idea?

[MrPhil]

A White Screen of Death (WSOD) is almost always caused by a PHP coding error (syntax error). Look around for any entries in your server error log and any "error_log" or similar error loggings scattered throughout your server directories. Read http://www.catskilltech.com/freeSW/SMF/faqs/#wsod and see if anything there applies.

[♥14steve14]

Apart from all the code changes, did you upload all the new jquery files, and the other oscommerce files that are required.

[Guest]

It's kind of late right now, but I will check the error logs when I get the chance. There was no mention of jquery updates in the instructions for 2.3.2. There are for 2.3.3. I updated my jquery several months ago, and I think the version I have has what 2.3.3 updates to anyway.

 

I have changed everything back, even replacing the changed files with the ones from my live store, but in Safari I still get the WSOD. Firefox gave me the index page, but when I clicked on anything or tried to go to the admin area I got the white screen. Could this be a database issue? Except for the changes for the 2.3.2 update I haven't made any changes to the DB for some time. The power has gone out occasionally, though, which kills the SQL server but not the Apache server, then it is difficult to get them both going again. Maybe that caused a problem?

 

Anyway, I just shut it all down and went to bed. It will have to wait until next week some time.

[Guest]

I checked the php error logs and found something about the file includes/languages/.php does not exist and it is called in application_top.php on line 286. That line is this:

require(DIR_WS_LANGUAGES . $language . '.php');

 

The value of $language is set by this just above it:

if (!tep_session_is_registered('language') || isset($HTTP_GET_VARS['language'])) {
if (!tep_session_is_registered('language')) {
tep_session_register('language');
tep_session_register('languages_id');
}

include(DIR_WS_CLASSES . 'language.php');
$lng = new language();

if (isset($HTTP_GET_VARS['language']) && tep_not_null($HTTP_GET_VARS['language'])) {
$lng->set_language($HTTP_GET_VARS['language']);
} else {
$lng->get_browser_language();
}

$language = $lng->language['directory'];
$languages_id = $lng->language['id'];
}

So it can't figure out to use the english.php language file. Did something get corrupted?

[MrPhil]

$language empty or not defined is a very common problem reported. I don't think I recall seeing any definitive solution, but the code you listed should be checking that GET['language'] is not '' before using it, and either unsetting it or changing it to 'english' (or whatever fallback language you want). If nothing else works, try adding the following just before the code above:

if (isset($HTTP_GET_VARS['language']) && $HTTP_GET_VARS['language'] == '') {
$HTTP_GET_VARS['language'] = 'english';
// unset($HTTP_GET_VARS['language']);
}

I haven't tried either way, so I can't promise either will work. But, it's worth a try.

[Guest]

$language empty or not defined is a very common problem reported. I don't think I recall seeing any definitive solution, but the code you listed should be checking that GET['language'] is not '' before using it, and either unsetting it or changing it to 'english' (or whatever fallback language you want). If nothing else works, try adding the following just before the code above:

if (isset($HTTP_GET_VARS['language']) && $HTTP_GET_VARS['language'] == '') {
$HTTP_GET_VARS['language'] = 'english';
// unset($HTTP_GET_VARS['language']);
}

I haven't tried either way, so I can't promise either will work. But, it's worth a try.

Thanks, Phil, but does it go before the first snippet or the second, the second actually being the first in the file?

[MrPhil]

It would go just before

if (!tep_session_is_registered('language') || isset($HTTP_GET_VARS['language'])) {
if (!tep_session_is_registered('language')) {
tep_session_register('language'); tep_session_register('languages_id');
} 

[Guest]

Unfortunately, that didn't work. I get the same error message in the log. But the front page is coming up. Does that mean it is losing session data, or just not setting it, or not getting the language variable back from language.php? I'm far from being even an advanced novice. but shouldn't that bit of code go after the call to language.php to set the language if it comes back with nothing?

[g2777]

I always found that the WSOD was caused by me missing } or ?> in my code. I got lazy and found this. Don't know if this will be of any help. Just paste your code in, select your php version and go. Fairly easy. Might not be your issue though.

Hope you find it.

[♥14steve14]

Have you tried comparing your files to your backup files, or even a new oscommerce file.

[Guest]

Have you tried comparing your files to your backup files, or even a new oscommerce file.

Yes, I have. In fact, I replaced all of the files I had changed with the files from my live store which does not have the problem. I do all changes on my dev store and then do a file sync via FTP to update my live store. So the live store is the same as the previous version of my dev store, i.e. the way it was right before this happened.

 

Since I have no intention of ever using any language other than English, could I change the code to always use English and not even check for anything else?

[Guest]

I always found that the WSOD was caused by me missing } or ?> in my code. I got lazy and found this. Don't know if this will be of any help. Just paste your code in, select your php version and go. Fairly easy. Might not be your issue though.

Hope you find it.

I have found that as well, and that is the first thing I checked. I didn't find any problems. And as the error messages suggest the problem is with a file I haven't even modified, I'm not sure that could be the problem. However, I am going to run them all through that site you linked to just to make sure I didn't just miss something.

[Guest]

Here is the last php error log entry:

 

 

[01-Nov-2012 18:38:54 UTC] PHP Warning: require(includes/languages/.php): failed to open stream: No such file or directory in /Applications/MAMP/htdocs/includes/application_top.php on line 292

[01-Nov-2012 18:38:54 UTC] PHP Fatal error: require(): Failed opening required 'includes/languages/.php' (include_path='.:/Applications/MAMP/bin/php/php5.4.3/lib/php') in /Applications/MAMP/htdocs/includes/application_top.php on line 292

 

Each one appears 3 times. Am I wrong or is the "include path" screwed up?

[Guest]

Here is the kind of URL I get when I click on any link on the front page:

 

http://localhost:8888/--p-160.html

 

The browser history shows the correct URL with the product name, as does the status bar at the bottom when hovering over the link. But when I click on the link the product, or category, name is removed and I get the WSOD.

[♥14steve14]

Are you doing this on your local computer.

[Guest]

Are you doing this on your local computer.

Yes, this is on my computer. My live store is working fine.

[g2777]

Yes, this is on my computer. My live store is working fine.

Are you using Dreamweaver by any chance? I used to find that DW messed up the link paths when I didn't write them out correctly or if it worked out the paths for itself.

[Guest]

Are you using Dreamweaver by any chance? I used to find that DW messed up the link paths when I didn't write them out correctly or if it worked out the paths for itself.

No, I do everything manually in TextWrangler.

 

I found another thread on the same issue, though for version 2.2, and tried a couple of the suggestions from there. The first was to add ?language=en to the end of the URL. That seemed to work on the front end, so I added some code from kymation to set the language to English if the function returns nothing. So the front end now works.

 

However, when trying that on the admin side, adding the ?language=en gets me to the login screen, but after that is blank. And adding it to the URL there gets this error:

Error!
Unable to determine the page link!
Function used:
tep_href_link('', '', 'NONSSL')

Is that because I am losing the session (which I think I am) or is it something else?

 

EDIT: I just noticed there are no prices listed, just a big 0.

[MrPhil]

Your "code from kymation" -- was that something added to includes/application_top.php to force "english" if nothing else came through? That problem (looking for .php instead of <language>.php) is so common that it's a crime not to have fixed it by now. If nothing else, if $language is undefined or empty, set it to 'english'!

 

If you're getting the same problem on the admin side, it has its own application_top.php, which might need a similar fix (I can't check at the moment). Not having to add 'language=en' to the URL might fix whatever is causing the page link error on the admin side, so I'd concentrate on getting the $language business straightened out, first.

[Guest]

Your "code from kymation" -- was that something added to includes/application_top.php to force "english" if nothing else came through? That problem (looking for .php instead of <language>.php) is so common that it's a crime not to have fixed it by now. If nothing else, if $language is undefined or empty, set it to 'english'!

 

If you're getting the same problem on the admin side, it has its own application_top.php, which might need a similar fix (I can't check at the moment). Not having to add 'language=en' to the URL might fix whatever is causing the page link error on the admin side, so I'd concentrate on getting the $language business straightened out, first.

Yes, that is exactly what it does. Maybe they just want to stay "international"?

 

Anyway, I can't help but think that the bigger problem is with the database. I have looked at the DB entry for the language settings and it is correct. The front page loads properly, it is only when I click a link to any other page that it loses the price and product information.

 

I just added that code to the application_top page on the admin side and it loads the login page correctly, but it gives me this error when I log in:

Error!

Unable to determine the page link!

Function used:

tep_href_link('','','NONSSL')

 

Did I somehow turn something off so it can't return the function results? It seems to be getting blanks instead of page names. Would that be the fault of the filenames.php file?

[MrPhil]

First thing to check: comment out the code you just added for the language problem. Does the page link problem go away? If it does, you messed up something in your changes to application_top.php. If it's unchanged (or the .php file problem is masking it again), I'm not sure where to start. Can you show us the before and after changes to application_top.php? Maybe there's something obvious. Is there no hint of where this page link error is happening?

[Guest]

First thing to check: comment out the code you just added for the language problem. Does the page link problem go away? If it does, you messed up something in your changes to application_top.php. If it's unchanged (or the .php file problem is masking it again), I'm not sure where to start. Can you show us the before and after changes to application_top.php? Maybe there's something obvious. Is there no hint of where this page link error is happening?

With the code commented out on the admin application_top all I get is a blank page. I had made no changes to that file before this started. With it commented out on the store side application_top I get the page with no products, prices, pictures, categories, etc. The error in the php log is:

 

[13-Nov-2012 22:47:04 UTC] PHP Warning: http_build_query(): Parameter 1 expected to be Array or Object. Incorrect value given in /Applications/MAMP/htdocs/admin/login.php on line 63

 

Line 63 is this:

             if (tep_session_is_registered('redirect_origin')) {
               $page = $redirect_origin['page'];
               $get_string = '';

               if (function_exists('http_build_query')) {
                 $get_string = http_build_query($redirect_origin['get']);
               }

               tep_session_unregister('redirect_origin');

               tep_redirect(tep_href_link($page, $get_string));
             } else {
               tep_redirect(tep_href_link(FILENAME_DEFAULT));
             }

It is part of the "migrate old hashed password to new phpass password" section. Specifically, line 63 is

$get_string = http_build_query($redirect_origin['get']);

 

As I mentioned before, I replaced all of the files I had modified with the versions on my live store, so none of them have any modifications that had not been done several months ago. I'm not sure what before and after I can show other than to compare mine to a completely unmodified one. Is that what you meant?

 

There are a boat load of errors about the time zone. I didn't think that would have anything to do with this, but that is the only thing new after commenting out the code from the store side application_top. Is this whole problem because it can't get the correct time zone?

[MrPhil]

If you're getting timezone warnings, that means your host is at PHP 5.3, which means you're going to have to set either an appropriate TZ environment variable, or date.timezone in php.ini. It's unlikely that timezone errors would be messing things up, unless you're getting "unable to send header" messages you're not telling us about. Anyway, that one's simple to clean up, so I would do that first and see if anything else changes.

 

Now, what is the history of your store? I think your first mention is of osC 2.3.1 -- is that the original installation, or had you upgraded from some level of 2.2? We all the upgrades done manually (manual editing), or were some of them automatic? I'm wondering if there is some PHP 5.3-incompatible code left in your store that you overlooked during manual upgrades. Note that a store upgraded from 2.2 RC2a to 2.3.1 is not equivalent to a fresh 2.3.1 install. It's basically 2.2 RC2a with a fresh coat of paint, so that it won't get PHP 5.3 too upset.

 

I'm not familiar with the code you showed. There's all sorts of session-related calls that may need to be changed for PHP 5.3. Was this special code originally for osC 2.2-something, or is it guaranteed to be PHP 5.3-compatible? Are you getting an "deprecated function" warnings? Make sure you don't have those warnings suppressed!