Jump to content

bsmither

Member
  • Posts

    17,989
  • Joined

  • Last visited

  • Days Won

    603

Posts posted by bsmither

  1. In your admin panel, General (Store) settings, Max Session Length is probably set to 172800 seconds (48 hours). If having a potential customer sit on your store's pages for two days is too long for you, maybe changing this value to 17280 seconds (4.8 hours) or less might be something to consider.

    You might also try modifying the code as discussed earlier:

    /includes/content/logout.inc.php

    Near lines:

    40 - setcookie("ccUser", "", , time() - 3600);

    41 - setcookie("ccRemember", "", time() - 3600);

    Then think about uncommenting line 44. If that breaks things, re-comment that line.

  2. What is "3.1"? Is this a CC version? I'm not aware of a version greater than 3.0.17. Could you reply with a verified CC3 version?

    Because CC3 uses cookies to maintain the appearance of carrying a session across pages, there's going to be a problem. Maybe someone has made a mod to the logout function when a visitor properly logs out of their cart.

    In PHP, see PHP Manual: session_start(). Also see PHP Manual: session_destroy() and PHP Manual: setcookie().

    I've run a search through the code looking for session_start(), session_destroy(), and setcookie(). While I'm no expert on PHP coding, it *seems* to me that in /includes/content/logout.inc.php, the "delete cookie" routine is wrong. By using setcookie("name") without a negative expire time (defaulting to 0), the application thus relies on the browser's behavior of killing the cookie *only* when all browser windows have been closed.

    Then, also in that file, the unset($_SESSION) is commented out. Why? I don't know. But it seems to me to be important that it executes.

    Advice:

    For testing - login, successfully place a test order, logout, then close *all/same* browser windows. That is, all IEs, or all FFs, or all Operas, or all whatevers to be sure the cookies for that session are killed. Then make another test order.

    Maybe, if enough users complain directly to Devellion, a proper bug fix might come about to deal with issues caused by rogue cookies. If that's the cause of the problem.

  3. I haven't looked in the CC code, but the MySQL database has the product's price set at a certain format.

    Use what ever means you have to access your store's MySQL database and look at the design of the table 'CubeCart_inventory'. The [price] column is formatted to hold Decimal(30,2). Change that to (30,3) and the default value to '0.000'.

    Do the same to tables 'CubeCart_order_inv[price]' and 'CubeCart_order_sum[subtotal] and [prod_total]' if desired.

    There *may* still be CC code that rounds to two decimal places, specifically during tax computations. But the bottom line computation, rounding to two decimal places may be what you actually want to end up with.

    In /includes/functions.inc.php, there is a function, priceFormat(), that uses data from the CubeCart_currencies table, [decimalPlaces] field. You might want to add another record here (maybe it's in the admin panel where you can add a currency) for "microdollars", being a copy of US Dollars (or whatever), but with '3' as the value for decimalPlaces.

  4. Try:

    File: /includes/ini.inc.php

    ------------------------

    Find:

    ------------------------

    // display errors

    @ini_set("display_errors", "1");

    // ste argument separator to & from & for XHTML validity

    @ini_set("arg_separator.output","&");

    ------------------------

    Add After:

    ------------------------

    // declare to sendmail server the From: header

    // probably use the e-mail address on file with your hosting account

    @ini_set("sendmail_from", "[email protected]")

    =============

    I haven't done this, but this seems like a good place to try this edit.

  5. This particular error:

    "Illegal use of string offsets causes E_ERROR (PHP5) instead of E_WARNING (PHP4)."

    As best I understand what's going on, $lang['admin']['yes'] = "Yes" is actually getting processed as:

    $lang['admin']['yes'][0] = "Y"

    $lang['admin']['yes'][1] = "e"

    $lang['admin']['yes'][2] = "s"

    where the third dimension is implied and acts as an offset into the string.

    Realize that $lang is, in fact, a three dimensional array. It's just that when first using it as a two dimensional array, each letter of the string, as an array, takes on the guise of the third dimension.

    I've run CC3.0.15 and .16 against several versions of PHP. PHP version 4 did not ever give me problems with a standard CC install. PHP5 up to version 5.1.2 seemed to work (if I recall correctly - I was experimenting with this July 2007), while for version 5.2.0, I had to modify any file that declared classes. (Had to wrap them inside a if !class_exists() wrapper.) I had absolutely no luck in getting CC3.0.16 running on PHP 5.2.3.

    Advice/Suggestions:

    1) If this is your server box, then maybe - if you're not running any other PHP app that absolutely requires PHP5, like the latest version of MediaWiki - you might consider switching to the latest version of PHP4.

    2) I haven't done the following as my understanding of PHP arrays isn't perfect: modify the GLOBAL ADMIN section to read:

    $lang['admin'] = array (

    'yes' => "Yes",

    'no' => "No",

    etc...

    );

    As I say, I have no idea if the above will fix it or make it worse.

    Let us know how you fare.

  6. I hope it's as easy as copying over the files, updating the settings and changing CHMOD values...
    Copy the files and database. Then update the /includes/global.inc.php file. Then get the EDITCONF code from this site (search for it) and run it from your store root. Update the admin settings that are stored in your database. Then finish up by making any other necessary changes from the admin settings page.

    This should work. I've done it a few times - making test versions of my stores on a local server.

  7. My host doesn't allow there to be a folder called 'admin' in root. It would be nice to know if with version 3 there is a way to do this.
    Well, it depends how much work you are willing to do and what tools you have available.

    I used my programmer's text editor to find all occurances in the code for "/admin".

    There are 18 occurances in the code and two occurances in each of the language files.

    Almost all of the 18 are form action parameters and look like:

    action="<?php echo $GLOBALS['rootRel'];?>admin/..."

    You can either change all occurances of /admin to /whatever, then re-up your store, or create a new $GLOBALS variable, 'adminRel', and make it equal to rootRel&&whatever, and change all the instances of the code.

    But there's gonna be code changes. Here's the files and line numbers:

    \admin\adminusers\administrators.php(178)

    \admin\adminusers\changePass.php(65)

    \admin\includes\header.inc.php(57)

    \admin\includes\header.inc.php(65)

    \admin\includes\navigation.inc.php(102)

    \admin\includes\navigation.inc.php(103)

    \admin\misc\licForm.php(59)

    \admin\modules\index.php(59)

    \admin\modules\affiliate\iDevAffiliate\index.php(66)

    \admin\modules\affiliate\JROX\index.php(64)

    \includes\functions.inc.php(120)

    \install\index.php(127)

    \install\index.php(575)

    \install\index.php(743)

    \install\index.php(744)

    \modules\gateway\HSBC\form.inc.php(47)

    (This is for 3.0.15)

  8. You haven't said whether the database belonging to the second store had its contents copied over from the database belonging to the first store, but there is a table in the database holding admin settings.

    So, when you go to the admin page of the second site (and it looks like the settings from the first site), try changing something and see if what you changed shows up in the admin settings of the first site.

    If not, then there's really no problem. If the change did show up in the admin settings of the first site, then get back to us.

  9. If you can code PHP, look in the file:

    \admin\customers\send.php

    at around line 125. I think this is where the looping occurs to spit out the e-mails.

    Maybe PHP has a Wait Until (trigger) type of command that you can introduce a pause of a certain kind. I was thinking wait until the time cycles past the sixty second mark, then execute the iteration.

    Like:

    curSeconds = Seconds(Now());

    If Seconds(Now()) < curSeconds Then (do it) //will only happen when seconds goes past 59

    but, of course, coded properly in PHP.

    This should limit the sending to one per minute.

    There may be other free (low or reasonable cost) solutions where you can feed your mail list to it.

  10. I think CC is designed around having a text font of 10-12pts, and if your browser interprets that as an equivalent font size of 18-24, then there is going to be numerous places of text areas overlapping others.

    Try reducing the displayed font size of your browser (FF - CTRL-minus, IE - View, Text Size, choice) and see if that makes any difference.

  11. parse() is a function of the X-Template System. This system is the under-pinning of how Cubecart was written.

    X-Template is loaded in as a class and has appropriate methods and functions. One function is to read in a chunk of a template and prepare it for expanding repeating sections, choosing which of either/or sections, and a few other content fulfilling operations.

×
×
  • Create New...