bsmither

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.

For the forum thread you referenced, what did the layout look like that wasn't exactly like what you were looking for?

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.

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.

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.

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.

Also, see this thread... http://www.cubecart.com/site/forums/index....showtopic=31289

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.

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)

All the graphics files are in: store\skins\yourskin\styleImages\backgrounds Grab an image editor and go to town.

Just a related question... How are you going about viewing this activity? Server logs, a third-party mod, ...?

The code for "Notify Customer on Order Success" is in includes/orderSuccess.inc.php. The actual verbiage that is sitting inside arrays can be found in your language's lang.inc.php file.

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.

I would recommend a try at making the topHeader.gif image wider, that is, add about 250 pixels of the right edge to itself (which is what the red sliver appears to be). Since the topHeader.gif image is already a background image, and the topHeader DIV has no defined width, then try making the image really wide so that the excess goes under the sessionBox DIV.

http://www.cubecart.com/site/forums/index....ost&p=92122

My advice is to look for the third-party mod for really extending the capabilities of the site docs functionality. Look around at CubeCartForums.org.

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.

In the file: \admin\orders\order.php at about line 322, find type="checkbox" id="inform" value="1" /> and change it to type="checkbox" id="inform" value="1" checked="checked" />

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.

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.

Are you, by chance, usiong GoDaddy to host your site. If so, search for all threads that have the word GoDaddy in it and read about a slight mod that's necessary. If not using GoDaddy, then, sorry, don't know.

This quite probably has to do with the fact that the MySQL database is configured to be "Strict." See http://www.cubecart.com/site/forums/index....showtopic=28650

Can you NOT use https: and just rely on CC's built-in functionality to figure out what the URL is for the SSL access?

I can guess that the form is a third-party mod thats installed based on a declared path at the time of the mod's purchase. Maybe you said the form is for "domain", and the publisher gave you a key (or hard-coded it) for "domain", but you installed it at "domain/path". Dunno.

Two possibilities: 1) You FTP'd the contents of the upload folder to your site, but the FTP program converted upper/lower case to all lower case. 2) See http://www.cubecart.com/site/forums/index....showtopic=28589 Also http://www.cubecart.com/site/forums/index....showtopic=26177 I would like to know what version of PHP you are running under.