X-Cart forums

[spiderwt]

For some reason, with the new version of x-cart, the pages do not load completely. This only happens like 50% of the time. Like today, everything was fine this morning, but now the pages are screwed up. I have tried viewing the website on several different computers, and they all have the same result. I have also tried rebooting the server (which helps temporarily) and running the cleanup.php. Has anyone else experienced this problem? I am not having a problem with any other scripts on the server, so the only thing that I can think of is that it might be a Smarty problem. Any ideas? Please check it out at http://www.spiderwt.net/samplecart, the homepage always stops just after the featured products.

You can also take a look at the PHP info at http://www.spiderwt.com/info.php

Thanks for your help!

[funkydunk]

I had a similar problem to this whereby the page seemed to stall when it got to the log in part of the page. If you view the html, you will see what is causing the issue.

The answer lies in the saving of sessions in mysql.

This is set in line 236 of your config.php is $store_sessions_in_mysql = false;

It worked for me.

[spiderwt]

Thank you funkydunk. It seems to be working now. Hopefully that fixed it.

[Clayster]

So funkydunk, you're saying that the answer is to SET $store_sessions_in_mysql to FALSE?

That's not an option for those whose SSL services are piggybacking on another domain -- in those instances, $store_sessions_in_mysql must be set to TRUE.

I have a store with that requirement, and am also having this page loading problem. I'm considering upgrading to the latest version of Smarty ... has anyone tried that as an attempted solution to this problem?

-Clay

[funkydunk]

Confused - This is a setting within the config.php file in the x-cart root directory.

[Clayster]

Hi funky,

I understand that it's a setting in the config.php file. I'm just trying to confirm that your solution suggestion is to set that to FALSE.

The problem is, that's not an acceptable solution for me since one of the stores I'm working on piggybacks on another SSL domain. (The domain the store runs on does not have its own SSL cert.) In order to do that -- have a different HTTP host and a different HTTPS host -- sessions MUST be stored in MySQL. Therefore, I cannot just set the $store_sessions_in_mysql to FALSE to solve the page-loading problem ... since that will create a NEW problem -- customers cannot check out.

So -- the question is: WHY does setting $store_sessions_in_mysql to FALSE make this page display problem go away? I've been looking through some code to try to determine that, and haven't seen anything jump out at me just yet.

-Clay

PS -- For anyone following this thread, I tried upgrading to Smarty-2.3.1, and it did not make a difference in this problem.

[funkydunk]

Hi Clayster

Sorry - didn't mean to partronise.

The answer I got from the xcart tech team on this was:

We are sorry for delay in answering, but we have managed to find the origin of the issue: enabled storing of sessions in mysql that is controlled with help of variable $store_sessions_in_mysql in file <xcart_dir>/config.php. This feature made web-server (Apache) on your host to crash and customerБ─≥s browser was getting only a part of html code.

Note: controlling of sessions storing in MySQL.
There is a line in file <xcart_dir>/config.php that looks like
$store_sessions_in_mysql = true;
This means to save session contents in MySQL database of your X-Cart installation.

If you change it to
$store_sessions_in_mysql = false;
you will get session handling using standard PHP method.

On some hosts enabled sessions storing in MySQL cause web-server (Apache, mostly) to crash during producing of HTML code of X-Cart page and customerБ─≥s browser gets only partial content of a page.

If you turn store sessions in mysql off, the standard method of setting session variables in PHP is used. I am not sure how this will impact on your scenario but this is not an unusual scenario I am sure.

[Clayster]

Thank you, funkydunk! That was a helpful post that you passed along from the tech support guys ... I didn't realize I was having an Apache crash when this was happening.

Just for grins, I tried turning off the storage of session data in MySQL ... since my non-SSL store and the site WITH the SSL cert that we're piggybacking on happen to be on the same server, everything is working without MySQL session storage.

So -- the problem is resolved for me, so long as the HTTP host and HTTPS host are on the same box. I can imagine this will continue to be a problem for other people who have HTTPS service on a seperate machine.

Thanks again for your post, funky! You saved me a lot of headache!

-Clay