bsmither

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 '/'.

When editing an order's status, if I check the "Inform customer" checkbox, I always get a 500 Internal Server Error. If it's not checked, I get the order status updated successfully. So maybe there's a problem with how e-mails addresses are being manipulated here? I was also told of several 500 ISE's when customers called to say that when moving from step 4 to step 5 of checking out (step five is when the customer is asked for their credit card number, if I recall), it crashed. It happened to me (as a prior successful customer) as I was making a test run through it. Backing up and trying again, I got through. So here it might *not* be an e-mail issue. I mention e-mail because I've stumbled across several messages that pin the blame on mis-matched e-mails for customer and/or administrator when CC didn't work quite right. CCv3.0.15 hosted on Godaddy shared server, Apache Linux.

Low priority question, I know, but it will help me understand how CC works... (for developing a mod) I'm looking at the _order_sum table and seeing fields that replicate fields found in the _customer table. Is there a reason why _order_sum.customer_id isn't enough? Thanks.

Did this and divined a major mess-up spot in the procedure. It involves backing up (moving/copying) from/to a *nix platform and IIS6 platform. On an IIS6 platform, the mySQL system variable "lower_case_table_names" probably should be set equal to 2 as this will preserve the case of table names during a CREATE statement. I had requested a SQL script be created by phpMyAdmin of my (production) store running *nix, then executed that script on a localserver (development) store running IIS6. The table names all came out lower case as viewed in MySQL Query Browser (MySQL AB). Knowing that PHP is case-sensitive, I was concerned what problems this might cause. Apparently none. However, going the other way may be highly problematic - IMHO. If the MySQL administrator on the IIS6 system allows for the total disregard of lettercase, I see problems ahead when moving/copying a store to *nix. The MySQL system variable "lower_case_table_names" may be by default set to equal 1 during installation on IIS6 systems, which is to CREATE all table names in lowercase and to convert all queries to lowercase. (Corrections to my conclusions are welcome.)

OK, so 35 fields. Is this a hard and fast number. I'm thinking of adding a mod to allow me to add custom fields that need to be included in however I manage to get data brought into Quickbooks. Once these custom fields are added, are they then seen by Order Import and presented in the list for inclusion/exclusion?

Yes, but even when there's only one choice (MC/Visa in my case), I still have to click my way through the page that offers the payment methods. The OP and I hope there's an "understanding" with CC that if there's only one enabled choice, just accept it as the default and move on. Maybe a customization of the code? Now, on the other side of the fence, I can suppose that if the one and only payment method offered does not suit the customer, then the the customer, realizing this, can bail. And I can see this side of the fence clearly since if PayPal is the only option available, I will bail. Many an item on eBay did not get my bid because the seller only accepted PayPal.

I messed up once on an FTP upload of my store - my FTP client has a setting that forces all transferred names to lowercase. If your FTP client has this setting, make sure it is not set. These *nix servers are picky about upper/lower case file and directory names. Maybe /store/index.php is being found, but there's nothing else gonna work if the file/directory names got changed, even by lettercase.

Could you not download again the ZIP archive of the version of CC you are running, then extract just the "rte" folder?

I had this problem when I upgraded FCKEditor from the version that shipped with CC3.15 (FCKeditor v2.0FC I believe) to a (supposedly) direct drop-in replacement - version 2.4.0 probably (but it's up to 2.4.2 now). Once the direct drop-in happened, the editor window wouldn't display any more. I had to put the distributed version back in. Do you have anything that may disturb javascript as the page is being loaded into your browser? Zonealarm, anti-phishing settings in your browser, privacy, pop-up blockers, etc.?

Not sure if this is a misunderstanding on your part, or if there is a true problem with CC, but this is how it works on my site: If I'm looking at products listed in a category page and I click on the "Buy" button, CC adds one to the cart and also takes you to the product page where CC offers to you an additional opportunity to add to your basket a specified quantity of this product. Hit the back button on your browser and click "Buy" once again, another unit is added to the cart. While I was showing the cart to my client, both she and I fell into that circumstance. I believe this behavior is outside the paradigm of intuitiveness.

That has happened to me, too, recently. But this was when I was really experimenting with CC. I think the problem shows up, at least for me, when I was trying to log in using the same user/pass in two separate browsers (FF and IE6) using the same IP address at the same time. I also made sure IE6 had the cache deleted. Do you have any other browser windows that may still be open and logged in?

Have you modified your skin? You said your documents are in a side bar, but the three skins that come with CC put the links to the documents centered at the bottom. If you are using Legend, the over-all box lengthens to accommodate all your doc links. But the separator character kind of throws off the effect. Killer has a definite height limit unless you modify \skins\Killer\styleSheets\layout.css to allow it (grab your CSS text books and image editing program!). The code at (or near) line 49 in \skins\Killer\styleTemplates\boxes\siteDocs.tpl checks for the last link and doesn't put a separator after it. If you do want the siteDocs box contents to wrap after x number of links per line, change out lines 49-51 for something that uses a MOD function. You may have to have a PHP guru figure that one out for you. As a second option, in \skins\Killer\styleTemplates\global\index.tpl, you can move the placeholders (called blocks) to wherever you need them. Like, move {SITE_DOCS} into the left column of the table code that's higher up in the template. So, you'll have to change your layout to accommodate a large number of site documents.

From what I'm able to make out, there's a section called "hidden".

Well, text() can save the result to a variable. The problem then becomes how to reintroduce the contents of that variable back into Xtemplate for another go around.