Keep Shopping Cart From Expiring So Fast

I want to allow shoppers who have not logged in to keep items in their cart for several hours instead of the default which I believe is 1440 seconds (24 minutes).

I looked at Admin>Config>Sessions and did not see a relevant configuration parameter.
So I also messed with /includes/functions/sessions.php with no success, playing with $SESS_LIFE.
SESSION_TIMEOUT_CATALOG sounds like it might be relevant but doesn't seem to be defined or assigned a value anywhere.
I do not want to changed the admin's login session life . . . just the shoppers' cart's life.
I'm not sure how to do it without messing up or if this is even the right approach to the problem.

Thanks!

zc155a
PHP Version: 5.6.27 (Zend: 2.6.0)
Apache Linux

Try the Keep Cart plugin; it hasn't been updated for a while, but should be OK.

I was hoping just a small change to /includes/functions/sessions.php would do the trick.

For example, I tried changing the line $SESS_LIFE = 1440 to $SESS_LIFE = 14409 yet the cart still was gone after 24 minutes.

Here's the sessions.php code from Zen Cart version 155a if anyone wants to take a quick look and make a suggestion . . .

Code:

---

<?php
/**
 * functions/sessions.php
 * Session functions
 *
 * @package functions
 * @copyright Copyright 2003-2016 Zen Cart Development Team
 * @copyright Portions Copyright 2003 osCommerce
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 * @version $Id: Author: ksteslicki  Sun Jan 25 17:45:51 2015 -0800 Modified in v1.5.5 $
 */
if (!defined('IS_ADMIN_FLAG')) {
  die('Illegal Access');
}
  if (IS_ADMIN_FLAG === true) {
    if (PADSS_ADMIN_SESSION_TIMEOUT_ENFORCED != 0 && SESSION_TIMEOUT_ADMIN > 900) {
      $SESS_LIFE = 900;
    } else {
      $SESS_LIFE = (int)SESSION_TIMEOUT_ADMIN;
    }
  } else {
    if (defined('SESSION_TIMEOUT_CATALOG') && (int)SESSION_TIMEOUT_CATALOG > 120) {
      $SESS_LIFE = (int)SESSION_TIMEOUT_CATALOG;
    } else
    if (!$SESS_LIFE = get_cfg_var('session.gc_maxlifetime')) {
    $SESS_LIFE = 1440;
    }
  }

  function _sess_open($save_path, $session_name) {
    return true;
  }

  function _sess_close() {
    return true;
  }

  function _sess_read($key) {
    global $db;
    $qid = "select value
            from " . TABLE_SESSIONS . "
            where sesskey = '" . zen_db_input($key) . "'
            and expiry > '" . time() . "'";

    $value = $db->Execute($qid);

    if (isset($value->fields['value']) && $value->fields['value']) {
      $value->fields['value'] = base64_decode($value->fields['value']);
      return $value->fields['value'];
    }

    return ("");
  }

  function _sess_write($key, $val) {
    global $db;
    if (!is_object($db)) return;
    $val = base64_encode($val);

    global $SESS_LIFE;
    $expiry = time() + $SESS_LIFE;

    $sql = "insert into " . TABLE_SESSIONS . " (sesskey, expiry, `value`)
            values (:zkey, :zexpiry, :zvalue)
            ON DUPLICATE KEY UPDATE `value`=:zvalue, expiry=:zexpiry";
    $sql = $db->bindVars($sql, ':zkey', $key, 'string');
    $sql = $db->bindVars($sql, ':zexpiry', $expiry, 'integer');
    $sql = $db->bindVars($sql, ':zvalue', $val, 'string');
    $result = $db->Execute($sql);

    return (!empty($result) && !empty($result->resource));
  }

  function _sess_destroy($key) {
    global $db;
    $sql = "delete from " . TABLE_SESSIONS . " where sesskey = '" . zen_db_input($key) . "'";
    $db->Execute($sql);
    return TRUE;
  }

  function _sess_gc($maxlifetime) {
    global $db;
    $sql = "delete from " . TABLE_SESSIONS . " where expiry < " . time();
    $db->Execute($sql);
    return true;
  }


  // Initialize session save-handler
  session_set_save_handler('_sess_open', '_sess_close', '_sess_read', '_sess_write', '_sess_destroy', '_sess_gc');
  // write and close session at the end of scripts, and before objects are destroyed
  register_shutdown_function('session_write_close');


  function zen_session_start() {
    @ini_set('session.gc_probability', 1);
    @ini_set('session.gc_divisor', 2);
    if (IS_ADMIN_FLAG === true) {
      @ini_set('session.gc_maxlifetime', (SESSION_TIMEOUT_ADMIN > 900 ? 900 : SESSION_TIMEOUT_ADMIN));
    } elseif (defined('SESSION_TIMEOUT_CATALOG') && (int)SESSION_TIMEOUT_CATALOG > 120) {
      @ini_set('session.gc_maxlifetime', (int)SESSION_TIMEOUT_CATALOG);
    }
    if (preg_replace('/[a-zA-Z0-9,-]/', '', session_id()) != '')
    {
      zen_session_id(md5(uniqid(rand(), true)));
    }
    $temp = session_start();
    if (!isset($_SESSION['securityToken'])) {
      $_SESSION['securityToken'] = md5(uniqid(rand(), true));
    }
    return $temp;
  }

  function zen_session_id($sessid = '') {
    if (!empty($sessid)) {
      $tempSessid = $sessid;
      if (preg_replace('/[a-zA-Z0-9,-]/', '', $tempSessid) != '')
      {
        $sessid = md5(uniqid(rand(), true));
      }
      return session_id($sessid);
    } else {
      return session_id();
    }
  }

  function zen_session_name($name = '') {
    if (!empty($name)) {
      $tempName = $name;
      if (preg_replace('/[a-zA-Z0-9,-]/', '', $tempName) == '') return session_name($name);
      return FALSE;
    } else {
      return session_name();
    }
  }

  function zen_session_write_close() {
    return session_write_close();
  }

  function zen_session_destroy() {
    return session_destroy();
  }

  function zen_session_save_path($path = '') {
    if (!empty($path)) {
      return session_save_path($path);
    } else {
      return session_save_path();
    }
  }

  function zen_session_recreate() {
    global $http_domain, $https_domain, $current_domain;
      if ($http_domain == $https_domain) {
      $saveSession = $_SESSION;
      $oldSessID = session_id();
      session_regenerate_id();
      $newSessID = session_id();
      session_id($oldSessID);
      session_id($newSessID);
      session_set_save_handler('_sess_open', '_sess_close', '_sess_read', '_sess_write', '_sess_destroy', '_sess_gc');
      $_SESSION = $saveSession;
      if (IS_ADMIN_FLAG !== true) {
        whos_online_session_recreate($oldSessID, $newSessID);
      }
    }
  }

---

btw, yes, I saw the Keep Cart addon. I should have mentioned that. I had decided that was not a good choice for me because there is no support thread or any discussion about it in the forum and my concern it could result in unanticipated Zen Cart behavior.

The 1440 comes from your php.ini configuration ... which is the default value that PHP sets out-of-the-box.

Quote:

---

Originally Posted by DrByte

The 1440 comes from your php.ini configuration ... which is the default value that PHP sets out-of-the-box.

---

However, for example, changing the 900 in sessions.php

Code:

---

  if (IS_ADMIN_FLAG === true) {
    if (PADSS_ADMIN_SESSION_TIMEOUT_ENFORCED != 0 && SESSION_TIMEOUT_ADMIN > 900) {
      $SESS_LIFE = 900;

---

to this

Code:

---

if (IS_ADMIN_FLAG === true) {
    if (PADSS_ADMIN_SESSION_TIMEOUT_ENFORCED != 0 && SESSION_TIMEOUT_ADMIN > 86400) {
      $SESS_LIFE = 86400;

---

keeps the admin open for 24 hours.

So, I would like to do the kind of thing to keep the cart from being deleted so fast for shoppers that have not logged in.

However, unlike the above change, changing the $SESS_LIFE assignment from 1440 in the below section of code has no discernible effect.

Code:

---

if (defined('SESSION_TIMEOUT_CATALOG') && (int)SESSION_TIMEOUT_CATALOG > 120) {
      $SESS_LIFE = (int)SESSION_TIMEOUT_CATALOG;
    } else
    if (!$SESS_LIFE = get_cfg_var('session.gc_maxlifetime')) {
      $SESS_LIFE = 1440;

---

I don't understand why it works for the admin $SESS_LIFE but not for the shoppers' $SESS_LIFE.
Thanks!

Right above your injected code is code that checks whether SESSION_TIMEOUT_CATALOG is defined, and if so, uses that.

Have you tried simply embracing that? Just create an /includes/extra_configures/my_ultra_long_session_timeout.php file and in it put:

Code:

---

<?php define('SESSION_TIMEOUT_CATALOG', 1441);

---

Quote:

---

Originally Posted by DrByte

Right above your injected code is code that checks whether SESSION_TIMEOUT_CATALOG is defined, and if so, uses that.

Have you tried simply embracing that? Just create an /includes/extra_configures/my_ultra_long_session_timeout.php file and in it put:

Code:

---

<?php define('SESSION_TIMEOUT_CATALOG', 1441);

---

---

Hmm. I was so excited to try such an elegant solution. However, it breaks my Zen Cart. More specifically, adding the file/includes/extra_configures/my_set_session_timeout_catalog.php containing only the following code prevents the site from loading . . .

Code:

---

<?php define('SESSION_TIMEOUT_CATALOG', 1441);

---

What am I missing?:lookaroun

did any log files get created? if so, please post their contents....

Quote:

---

Originally Posted by carlwhat

did any log files get created? if so, please post their contents....

---

It does not cause a file to be created in /logs
I was thought I would see a new myDEBUG-xxxxx-yyyyyy.log file. But there are just old ones. So I added some non-syntactical garbage to the code just to make sure it would generate a myDEBUG-xxxxx-yyyyyy.log file. And, yes it did. So, I'm stumped.

zean,
an error that can be replicated, is an error that can be solved!

Quote:

---

So I added some non-syntactical garbage to the code

---

where did you add this code? did you remove this new file prior to adding this code?

i tried adding the SESSION_TIMEOUT_CATALOG to my test system and it worked fine.... if your system is erroring out when adding that file and no debug errors get generated, that means that the extra includes files get added PRIOR to the overwrite that gets established for the zen debug logs. which means the error is still getting logged to the system PHP logs. do you have access to those logs on your server?

this seems like a rather simple problem, which means the answer should be staring you right in the face. have you tried adding echo statements in the suspect file before the include and right after the include?

there are a bunch of potential ways to find out what the problem might be.

i would DOUBLE/TRIPLE check your syntax on the new file, and if that looks good, i would add the echo statements before and after the define statement in the new file....

it is entirely possible that the define statement, 'MAY' be causing some problem down the line....

good luck!

Quote:

---

Originally Posted by carlwhat

zean, where did you add this code?

---

I added that non-syntactical garbage (adfgffdfhf erewererer) to the same file to see if I could get it to produce the myDEBUG-xxxxx-yyyyyy.log file which as I mentioned previously it did. I just did that to confirm I was looking in the right place for the error report which I was.

Quote:

---

Originally Posted by carlwhat

i tried adding the SESSION_TIMEOUT_CATALOG to my test system and it worked fine

---

Well that's baffling.

Quote:

---

Originally Posted by carlwhat

which means the error is still getting logged to the system PHP logs. do you have access to those logs on your server?

---

The problem does not get reported in the cpanel>statistics>Error Logs>PHP error_log

Quote:

---

Originally Posted by carlwhat

have you tried adding echo statements in the suspect file before the include and right after the include?

---

I tried removing the define statement and it sill bombs out with just this . . .

Code:

---

<?php ;

---

I even tried adding removing everything from the added file . . . just an empty file and it produced this message in the firefox browser . . .

Code:

---

Content Encoding Error

The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

    Please contact the website owners to inform them of this problem.

---

and this in IE browser . . .

Code:

---

This page can’t be displayed

•Make sure the web address http://www.mydomain.com is correct.
•Look for the page with your search engine.
•Refresh the page in a few minutes.

Fix connection problems

---

And, I tried just this code in the added file . . .

Code:

---

<?php echo "Hello" ;

---

Which produced the same result as the empty file.

zean,
if you go to the admin -> tools -> server/version info and lookup:

zlib.output_compression

what is the value?

i think it is currently off... and you need to turn it on...

assuming you are on a shared host, you can contact your hosting company about a local version of the your php.ini file and do an override of that value. your hosting company should be able to help you with it....

it DEFINITELY is a configuration issue on the server, based on your information. and it IS something your hosting company should be able to help resolve with you.

good luck. let us know how it goes!

Quote:

---

Originally Posted by carlwhat

zean,
if you go to the admin -> tools -> server/version info and lookup:

zlib.output_compression

what is the value?

i think it is currently off... and you need to turn it on...

---

Yes, shared hosting at BlueHost.

Actually, my zen cart configuration turns GZip Compression on . . .

admin>configuration>Enable GZip Compression=1

And here is the zlib.output_compression info from admin>tools>server/version info

Code:

---

Directive        Local Value        Master Value
zlib.output_compression        On        Off
zlib.output_compression_level        1        -1
zlib.output_handler        no value        no value

---

I suspect the compression issue firefox is reporting is a result of the problem and not the cause of the problem.

I think the fundamental question is why does my adding any file with a php extension to /includes/extra_configures/ break my zen cart?
btw, it does NOT break the admin portion of zen cart. It 'just' breaks it for shoppers.

Quote:

---

Originally Posted by Zean

I suspect the compression issue firefox is reporting is a result of the problem and not the cause of the problem.

I think the fundamental question is why does my adding any file with a php extension to /includes/extra_configures/ break my zen cart?
btw, it does NOT break the admin portion of zen cart. It 'just' breaks it for shoppers.

---

zean,
#1 i think we are trying to find the answer to this fundamental question. and based on your information, i am convinced that there is a server configuration issue that is going on.
#2 i do not think the admin loads this file, which is why the admin does not break.
#3 what firefox is reporting is telling us the problem.

"...The output of your application should only contain one output encoding. If you have multiple chunks that are encoded differently, then the browser will get a result that it is impossible to work with. Hence the encoding error...."

a few other things to help in the trouble shooting.... i would first try turning off gzip compression in ZC. see what happens then....

can you send me the URL of your site?

if you open the developer tools, click on the network tab, and then click on the main script getting loaded, you should be able to see the accepted content-encoding.

you really need to see the apache logs as opposed to the php logs on your server. the ZC logs report PHP errors, we are not getting a PHP error which is why you do not see a ZC log or a PHP log error. i'm sure there would be an error in the apache log.

hope that helps. there are multiple compression encodings that seem to be happening at the same time.

good luck!

Quote:

---

Originally Posted by DrByte

Right above your injected code is code that checks whether SESSION_TIMEOUT_CATALOG is defined, and if so, uses that.

Have you tried simply embracing that? Just create an /includes/extra_configures/my_ultra_long_session_timeout.php file and in it put:

Code:

---

<?php define('SESSION_TIMEOUT_CATALOG', 1441);

---

---

Out of curiosity, I also did this with ZC v1.5.5 and no problems.

As it can be helpful sometimes to get a second opinion, a site worth Bookmarking is:
http://checkgzipcompression.com/

See what it says for your site.

Sometimes copy-and-pasting from the forum can put hidden markup characters in the text. While that shouldn't normally introduce extra encoding, I've encountered situations where various sites whose markup for displaying source-code text introduces undesired extra characters when pasting. In those cases simply typing the intended code by hand solves the problem. (So does running it thru a "cleaner", but in the case of the code snipped I pasted earlier it's simple to type by hand.)
Just a thought, to rule out one possible cause of issues.

Quote:

---

Originally Posted by DrByte

Right above your injected code is code that checks whether SESSION_TIMEOUT_CATALOG is defined, and if so, uses that.

Have you tried simply embracing that? Just create an /includes/extra_configures/my_ultra_long_session_timeout.php file and in it put:

Code:

---

<?php define('SESSION_TIMEOUT_CATALOG', 1441);

---

---

Thanks DrByte!
I finally got this to work just as you suggested. So, I've set it to 14400 (4 hours).
I'm thinking of setting it to 1 month. Anything I should monitor?

I have mine set for 365 days, although I'm using keep cart which is excellent and no problem with 1.5.5f

Quote:

---

Originally Posted by lankeeyankee

I have mine set for 365 days, although I'm using keep cart which is excellent and no problem with 1.5.5f

---

Hey lankeeyankee, Good to know! So you've been running your cart with with SESSION_TIMEOUT_CATALOG set to around 1 year. That gives me more confidence to set mine to a month or two. Also, your use of Keep Cart is encouraging. I may try it. Most of my products have lots of attributes so I am mindful of what DrByte said here about cookie limits and possible concerns with an attribute intensive shop running Keep Cart.

Quote:

---

Originally Posted by Zean

HI am mindful of what DrByte said here about cookie limits and possible concerns with an attribute intensive shop running Keep Cart.

---

And I stand corrected, I never saw this so thanks a bunch for pointing it out! Will look at changing since our new launch will have more complex attributes and other features. I didn't realize this was a constraint.

Keep Cart v2.0.3 is now available: https://www.zen-cart.com/downloads.php?do=file&id=992

It's been tested on zc157c and zc158 and requires a minimum of PHP 7.3 to be enabled.

This release contains changes associated with the following GitHub issues:

#8: Correct 'occasional' PHP warnings during cart-restoration from cookies.
#9: Log configuration errors only once per storefront customer session.
#10: Ensure that cookies are removed when the cart is emptied.

Please note, this is now considered the plugin's support-thread!

ZC 1.5.8 on PHP 8.4.2.
ZC session time (for testing) = 120 sec
Cookie life = 30 days

Deleting items from shopping cart works until the very last item. The last item can not be removed from cart.

I have confirmed I am using the latest version of keep cart. It does appear to include the fix for the #10 github issue.

Thanks,
John

I've just tested on a fresh 1.5.8a on 8.2.4 and it does not allow last item to be removed from the cart.

Thanks again,
John

"Keep Cart" v2.0.4 is now available for download: https://www.zen-cart.com/downloads.php?do=file&id=992

This release contains changes associated with the following GitHub issues:

#12: Cart cannot be emptied; last item added cannot be removed.

Thanks to @torvista for the correction!

I've started using 2.0.4 on 1.5.8a, and there are still occasions when the cart is "cleared" / either logged-in or not
that the cart restores. I haven't been able to replicate it yet as to where/why, but it does still happen.

Dan

Quote:

---

Originally Posted by DTomlinson

I've started using 2.0.4 on 1.5.8a, and there are still occasions when the cart is "cleared" / either logged-in or not
that the cart restores. I haven't been able to replicate it yet as to where/why, but it does still happen.

Dan

---

From my customer:

Quote:

---

It still wasn’t working in Safari, but i switched over to Chrome and my cart is clear there (logged in or not). I’ll just use Chrome as my browser…but it might be worth noting there seems to be an issue with your site interacting with Safari.

So just to be clear, when not logged in, if I cleared the cart it immediately reloaded and I couldn’t log in before that happened. When logged in, if I cleared the cart, it would again reload full before I could log off. Super weird. I blame Apple ��

---