bsmither

CC 3.0.16 works under PHP 5.1.2 while under PHP 5.2.3, it doesn't (according to my experiments). I still have all the wrappers around the function definition blocks, and I'll test with original files shortly. Can we get a poll started as to what's the latest version of PHP that CC 3.0.16 successfully runs under?

Would if I could. I went ahead and wrapped each function definition block in a if (!function_exists()) test. I don't get any more Fatal Errors..., I don't get anything at all. Just Firefox burning up 15% CPU power waiting for the host to deliver something. I'm going to see if I can find a PHP 5.1.2 installation package and see if that makes any difference.

I've noticed that the code in 3.0.16 has include_once() most everywhere except in almost all the files in the admin folder. I'm trying to troubleshoot a "Fatal Error: Cannot Redeclare unsetGlobals ..." error immediately after I successfully log in. So far, if I put a echo"Hello";die(); before line 29 in the login.php, I get the Hello. If I put it after line 29, I get the Fatal Error. So somehow, ini.inc.php is getting called twice - which it is, once through admin/index.php and again through admin/login.php. My research suggests that PHP 4 doesn't care. And CC3.0.15 with PHP 5.1.4 seems to be working fine (installed on a dev server). But on another dev server (WinXPSP2 with Abyss Web Server X1 v2.4) running CC3.0.16 and PHP 5.2.3, I get these Fatal Errors. So, examining the code and placing echo/die at places where I want the thing to stop in the admin section, I see lots of include() and very few include_once(). Before I do a global replace of include("../includes/ini.inc.php") with include_once, I would like to know if the programmers had a specific reason to keep the include() construct instead of universally changing it to include_once(). And is there any comment as whether this global replace will even work? Other research suggest wrapping (something like) IfExists("unsetGlobals") around the function declaration, but that only solves that function - until the next is stumbled upon. Wouldn't using include_once() be the more elegant programming fix? Now, I realize I have yet to discover the exact reason why I am having this problem: code changes in the PHP engine, Zend optimization, CC 15 vs 16, or the fact that it's July in Colorado -- I don't know. Well, that didn't work. Still got the fatal error. So I commented out line 29 in login.php and didn't get the error for unsetGlobals. But I did get another Fatal Error: Cannot redeclare detectssl() in /includes/functions.inc.php. Will keep on experimenting.

In this fresh installation, (page 3 of the install script) did you keep the checkbox setting to "Drop existing tables?" I don't think I'm wrong when I say that (due to personal experience), with this box checked, existing tables with the same name are deleted and fresh, empty tables are created. At least you don't get server or script errors saying "Unable to access database."

I don't have an answer for you, but why is 'php' on the line below the 'script begin' delimiter? Did this get pasted into your message exactly as it is in the file? If so, maybe you should fix it so that it reads: <?php $glob... I honestly don't know if PHP would make a fuss about this.

Might be an issue of where in the .tpl file you put the {MYNEWVAR} placeholder. Look at the source code view of the page sent back to your browser and see if HELLOWORLD shows up, but the browser isn't rendering it.

Just a few thoughts: Maybe the problem happened "around" the 1000th category (or sub-category), but not exactly at the 1000th. I do see anything that would limit the drop-down box to 1000 entries. In /admin/products/index.php, line 347, a query is pulling three columns from the _category table, then in line 373, a list of OPTION statements is being built from the rowset. And apparently that's where the code generation stops. If you are still having this problem, what we need to see are the last few lines of the web page source that was delivered to your browser. (View Source in your browser.) I'm thinking the last line will contain a clue as to what's stalling the PHP of your store's delivery of the page's HTML. If you are, in fact, receiving the entire page, then look for the string of OPTION tags in the source. There might be about a thousand of them! I'm going to make a gentleman's wager that one of your category names has an illegal character. If so, then what you are seeing might be a problem with your browser's inability to make sloppy guesses as to what it should do. IE6 was reasonably good this, maybe IE7 not so much.

Do you actually mean to say that some subs have multiple parents in your source data? The table column _category.cat_father_id is an integer value (0 = top-level category). To have multiple parents, you would need to change the datatype of this column to... well, I'm not an expert on MySQL, so I don't know if there's a column datatype of array, or if it needs to be text. Then, there's line 52 in viewCat.inc.php that has a SELECT statement that's looking for a single value, not an array or comma separated list. On the category page that lists all products in that category, at the top, there's a "breadcrumb" feature. This is built by code in the functions.inc.php file, getCatDir(). I haven't figured out that function but I'm sure that having multiple parents is going to break this. I suppose you could comment out line 235 in viewCat.inc.php to inhibit this function. You might also need to do something about line 19 in viewCat.tpl.

I tried to place two e-mails seprated by a comma on the Store Settings page and a "500 Internal Server Error" message for my effort. Then I thought to create an alias e-mail (since I own the domain name) and have that redirected to as many e-mails as I need.

Right-click on the blank image placeholder and select properties. The properties window should tell you where your browser is asking for the images. If the URL shown has too many or missing backslashes, then there's a misunderstanding in your responses to the URL field's of your store during installation. But missing images during the installation? Hmm... Maybe, by chance, did you upload the "upload" folder from the CC distribution archive? Or did you upload the "contents" of the upload folder onto your site? Maybe you have a firewall or pop-up blocker that prevents images from being downloaded from unapproved sites? Did you FTP the contents of the upload folder having a setting in the FTP program that forces all file and folder names lowercase when transferring? If the properties page of the graphic that's supposed to be there says "cclogo.gif" instead of ccLogo.gif", then that's what happened.

Woohoo! Can you use escaped quotes?

In addition to a skewed cookie that somehow got into your browser's cache, your firewall, or pop-up blocker, or anti-virus, or all-in-one Internet Security Suite, or Cookie Cruncher, or Javascript Annihilator, or IE6/7 Security Settings may be munging the cookie, or returning a munged cookie. Please investigate the possibility that the protective screens you've installed on your computer may be causing the problem.

Verify what you have in your \includes\global.inc.php: The name of your MySQL database as installed on your Windows server (dbdatabase) is 'ocal1_ocal'. You have not set a prefix (dbprefix) for CubeCart's set of tables in this database. It's a zero-length string. For the rootDir path, try this - for every backslash, make it four backslashes. That is: $glob['rootDir'] = 'D:\\\\hshome\\\\ocal\\\\mysite.com'; And for the storeURL, try not putting the trailing slash on it. See what happens - let us know.

I got that on a totally unrelated application. Decided to switch to the ISAPI.DLL mode as opposed to the CGI mode of running PHP. That solved it for me. However, if I were to troubleshoot the exact cause, I would start with using Firefox and Live HTTP Headers (although I don't know if you actually need Firefox for this). I would find out what headers are missing. As a general point to investgate, I would study what ended up with capital letters and what didn't when compared to your Unix installation. Database table names, folder/file names, etc.

My (novice) conclusion is that the role of a gateway sends and receives only that information necessary for you to confirm that you got your money from your customer. The gateway e-mails that I get only detail the transaction, not any information about *what* was purchased. I do not know if or how one can get CubeCart to send an administrative e-mail for each order placed. I would imagine that once your store starts processing dozens or hundreds of sales a day, you won't need the e-mails -- just do your daily managerial duties.

Perhaps the *entire* domain space was changed to, what?, 000? Anyway, maybe more than just the global.inc.php needs to have permissions checked out. And, just to cover more bases, have you cleared your browser's cache? Have you verified that a computer other than yours can ascertain that your store is still non-functional?

My way would be to identify the skin you want for the store at location 1, copy and rename that skin folder to "thisSite". Identify the skin you want for the store at location 2, copy and rename that skin folder to "thisSite". In either store's admin panel (because you are sharing the database), for Store Skin, choose "thisSite". Let us know how it works.

I'm not too sure about the "pear:.:/public_html/" portion of the address. Part of it is duplicated and part of it has characters I would never use in a URL string. In your admin panel, click Server Info, scroll to Configuration, PHP Core section, and look at the value for "include_path". It might say something like ".:/usr/local/lib/php". There might be something seriously wrong with this value of this variable. If there is, to have it fixed, your hosting support might have to get involved.

Yeah, I also think it's a good idea to go over to CubeCartForums. There, you enter a new topic and I'll post the same response as I did here. Then one of the programming people can figure out what the PHP code should be. But conceptually, I think this is what you want. You might even try: $view_doc=file_get_contents("includes/docs/".mySQLSafe($_GET['docId'])."html"); And did you copy "mySQLSafe()" capitalized as I wrote it?

Here's what I would look into (since I haven't actually done it): In /includes/content/viewDoc.inc.php, insert before this line (should be 38 in CC3.0.15): if($lang_folder !== $config['defaultLang']){ the following (perhaps not perfect php code): $view_doc->include("includes/docs/".mySQLSafe($_GET['docId'])."html"); (Maybe the "->" needs to be an "=", I don't know.) Then comment out everything afterwards but the last two lines: $page_content = $view_doc->text("view_doc"); ?> So, when a visitor clicks a siteDoc link, the form sends a URL containing "?act=viewDoc&docId=4" (for example). The new line above is going to use the "4" to construct "4.html" which will be found in the folder of your specification. The include will assign it to the already present variable and be processed out to the page's content normally. Let us know if this works.

walter4, did this fix your problem?

There might be something up with the database. To be sure, you need to visually inspect the table names of your store's database using something like phpMyAdmin. See a write-up about this here: http://www.cubecart.com/site/forums/index....st&p=130180 Basically, if your IIS6 has a MySQL system variable set a certain way, lettercase of table names become an issue. You said you had copied your development installation over to your production environment. What OS is your MAC running? That *nix variant? And what is the value of that system variable in your MAC's installation of MySQL? Are the table names in all lower case? For a good explanation of the consequences of that system variable, "lower_case_table_names", search the MySQL developer's site's MySQL manual pages for it.

Yup. That was the problem. Admin, General Settings (Store Settings), Styles and Misc: Email Address You cannot put more than one e-mail address in this field. I thought this address was to be used only to send relevant status notices To:, not From:. But I see that it's used as both. The email address specified when Administrators are created must receive something from the store???

Brilliant! (And I say that in a good way!) Thanks for the response!

Line 27 in /index.php is a line commented out in a block describing the ownership of this application. Same with line 28 in /admin/index.php. Is your new domain on a different server, that is, running under a different installation PHP? Maybe you've made an adjustment to how PHP runs on this new server? Have you looked at the code of these files mentioned in the error report? The line where sessionStart is called in is on line 56. And if you removed the 28-line chunk of commented out text, then the line where sessionStart is called would indeed end up on line 28. In the file /includes/global.inc.php, see what the value is for 'rootRel'. If this store is at the root, I believe 'rootRel' needs to be '/'.