bsmither

I'm not getting where you are. "Click on Configure in Payments". Do you mean the "Configure" link for the Authorize.net (AIM) gateway in the list of gateways on the Gateway Modules page in the Admin pages? Does your link when you hover your mouse cursor over the configure link look like: /admin/modules/gateway/Authorize_AIM/index.php?module=gateway&folder=Authorize_AIM And does the folder Authorize_AIM exist including the capital letters? What are the values of your URL settings in global.inc.php? Are you hosted at GoDaddy? And finally, are you running any mods?

When you hover the mouse over the edit link, does it look something like this: YourDomain/shop/admin/docs/siteDocs.php?edit=X (where X is a number from 1 to whatever)? Do you have SSL switched on? Are you a "Super User" administrator? (I hope so.)

The built-in editor is displayed in those sections that require it: General Settings (way at the bottom), Add/View Products, Homepage and Site Docs (once you click Edit for a document). The editor is somewhat javascript heavy, so if you have any pop-up blockers, script killers, etc, that might interfere with javascript, see what you can do about allowing your store's URL to bypass these types of things.

I think I've read about this before - either in these forums or on some other forum that was discussing ModReWrite. If I recall correctly all the minute details, the problem is probably with IIS6's "courtesy redirect". (You didn't include any of the details about your store's installation that would help us track down a cause.) And by "as it should be", one cannot conclude which URL you are actually wanting: you have the first but want the second, or have the second but want the first. But this might be an issue with your host and not solvable by anything CC can do.

Do you have the SSL switched on? Presumably you do because I think CC would tell you of this serious mistake. Are you saying you get the white screen *for* that which you believe should be the screen to enter credit card info, or are you getting a white screen *after* submitting the screen that you had entered the card info? Also, I know that CubeCart's gateway fields that ask for the Merchant ID and Transaction Key are not the right words. In your actual Authorize.Net subscriber's control panel, you generate a pair of numbers, neither one being your "Merchant Services Provider's Merchant ID number". As defined by Authorize.net, which is the gateway between your store and your MSP, the Merchant ID is a code that references your store's communication. CC calls it that but (if I recall) Authorize.net doesn't. (Well, this is what I definitely recall as being an issue when I set up two Authorize.net accounts six months to a year ago to be used with CC. My recollection could be a bit fuzzy by now.)

Maybe, maybe not. http://us3.php.net/mhash says it was dropped as of PHP 5.3.0 But if Websurfer's host told him PHP 5.1.x, then it should still be there. I do not know what the differences in the documentation between: http://us3.php.net/mhash and http://us3.php.net/manual/en/function.mhash.php I guess http://us3.php.net/mhash is an introductory overview of the whole mhash() library while http://us3.php.net/manual/en/function.mhash.php describes the core function itself.

I'm not seeing it as being a straight substitute. I took a look over at CubeCartForums.org and nothing relevant came up with mhash or anyone building newer versions of the gateways. 1) string mhash ( int $hash , string $data [, string $key ] ) 2) string hash ( string $algo , string $data [, bool $raw_output ] ) 3) string hash_hmac ( string $algo , string $data , string $key [, bool $raw_output ] ) There are minor differences between mhash() and hash_hmac(). So, maybe (not having tried it myself): Line 125: return (bin2hex (mhash(MHASH_MD5, $data, $key))); to: return (hash_hmac("md5", $data, $key)); 'outputs lower-case hex as default I hope the CC powers-that-be decide to offer up a free upgrade for the gateways (and other code) that uses the obsoleted MHASH extension.

While logged on as your friend and viewing the Administrators page, do you see that log-in as a Super User or not (green vs red status box)? If not, for some reason you may not have the permission to edit the site docs. If you don't, you should see the "401" page. So, you will have to clarify by what you mean, "I can't make it work..." Describe the steps taken, the screens you see, and the outcomes you get vs what you expect to get. The site docs are stored in the CubeCart_docs table in the store's database and are edited using the store's built-in editor.

Guess: Your host moved you to a different machine. In so doing, they used the wrong or outdated backup. Double check the file timestamps on the CC files as they exist in your hosted space vs the timestamps of the files you have on your workstation that you FTP'd to the space originally. (If you did it that way.) My host did that (didn't mess anything up though). One day, *each and every one* of my files on my hosted space had the timestamp of Oct 7, 2007.

Onto what type of OS/Computer are you first unzipping the CC package prior to FTP'ing up to the server? I can imaging this taking more than an hour if your workstation is a 20 year old '286. If the package was truly corrupted, the unzip shouldn't happen at all. I can see where the FTP, if sent in ASCII mode (as opposed to binary), would corrupt the images. But, if when bringing an image back down from the server to the local workstation, it displays whole and complete, then we will look elsewhere.

What type of server is running CC: Apache on *nix or IIS6 on Windows? And, no, unzipping should take only one or two minutes.

OP> I have the SEO Friendly mod being installed ... the crawlers will all only be for/look at the default language text. I believe the meta keywords in the stock code are saved in the config database. Please correct me if I am wrong. If that's the case, then the multi-variant hack as discussed on CubeCartForums.org may be of value to your situation. I have no knowledge of the SEO mod, feel free to ask the author if the data managed by that MOD is stored in the config database. OP> I have read about multiple stores (URLs) running off one DB - but I assume that that would mean they would all have the same language? My experiments show that whatever is stored in the config table [and that there are now distinct config tables for each respective store variant as discussed in the hack], then each store will have its own default language.

I had thought to try to come with a solution transparent to the CC code, but the furthest I got requires MySQL 5.1x which not a reliable requirement. So, a change to the code is probably necessary. It should not be overly difficult - references to the CubeCart_config table is found in only nine statements. Look for a write-up at CubeCartForums.org, Hacks and Tweaks.

In /skins/yourskin/styleSheets/style.css, the .textbox is defined. If it comes to changing the size of the font shown in the textbox, try doing it here. In /modules/gateway/eachgateway/form.tpl, look for: <input type="text" name="cardNumber" value="" size="16" maxlength="16" class="textbox" />

Find the EDITCONF utility in the downloads section and install according to instructions. There are some parts of the store's URLs and paths stored in the _config table (unreadable, however). You will need to update these paths using this utility.

The screen capture of your FTP app is showing a directory other than the ones used by the Admin section. See if: \admin\modules\gateway\PayPal\ has index.php and logo.gif in it. The file index.php is including a lot of other files from directories way off from the other side of the store's hierarchical tree. In Windows IIS, there's this setting called "Enable Parent Paths" and it can be set to No. A parent path is "../../../" where the double-dot is the parent directory. I'm not at all familiar with Apache but maybe an Apache expert can chime in here and give us a clue about disabling parent paths. We might also want to ask the Apache expert what the ramifications of using suEXEC may have - if it's implemented in your Web space.

Uh-Huh... In the browser window header bar, is there the "CubeCart" wording? Has your browser's throbber stopped moving? If you do a "View Source", what do you see? (Throbber, you know, that cool little icon in the upper right-hand corner of your browser? That is your throbber - yeah, I don’t like the name either. However, its job is to let you know when there is still data being transferred from a site’s server by going through its animation cycle.) Are you on a Windows server or Apache?

A completely blank, white screen? Or rather you get the Admin layout, but just with no table shown with a list of the available options for that module? Click the Administrators link and see if you get a listing there? Is the current login listed as a super-user? Does the URL of a module open for configuration look like: /admin/modules/shipping/Per_Category/index.php?module=shipping&folder=Per_Category

I'm not sure myself, so I'm asking for you to reverify the Max Upload Filesize in the Admin. What I'm not sure about is whether CC deals with strictly numbers or if it can deal with symbolic values. That is, Max Upload Filesize has "(Under 2048Kb Recommended)". 2048Kb is a symbolic value. The error message says "...upload limit is 2MB." Again, 2MB is a symbolic value. Is there a pure number in this field or a symbolic value? Or anything at all? Try deleting the value found here and hope that it does default to =(2*1024*1024) and not 0. =============== Ok, scratch the whole of the above. If the situation described above were true, you be getting a slightly different error message. This error message is coming because a test for a successful HTTP POST function is returning false. Somewhere along the way, your upload is being rejected or lost. I'm still looking for the problem. Could you send me a copy of one the files that is not uploading? Can you re-upload the same file? That is, once a file gets uploaded, can you continue to upload it several more times without it getting lost?

Was this resolved? To start, "open_basedir restriction in effect." Your host has set a security measure in place. If not done correctly, it will cause problems. The partial path: /hsphere/local/home/boudoirb/boudoirbazaar.com/ is probably what you have specified in your global.inc.php file. Yet, the location of the file causing the error message returned is something a bit different: /var/hsphere/local/home/boudoirb/boudoirbazaar.com/ The open_basedir parameters are: /hsphere/local/home/boudoirb:/usr/local/lib/php:/hsphere/shared/apache/libexec:/tmp:/var/tmp I am seeing "/var/hsphere/" and "/hsphere/" as both being declared from root. This might be the problem. In your Server Info page of the Store's Admin, find _SERVER["APPL_PHYSICAL_PATH"] in the PHP variables section. Compare that with the paths above.

Can you FTP into your "nlp" space (where "downloads" and "public_html" folders can be seen) and verify that the document is actually in the Downloads folder? Go into the store admin pages, Server Info page, and look in Configuration-PHP Core at the open_basedir setting. Is there a path(s) listed here? If there is, and it goes all the way to "/home/nlp/public_html/", then "downloads" probably isn't going to be accessible. You will have to talk to your host about this. When you say you uploaded the file, was that a manual FTP upload, or did you use some sort of web-based function? I'm not finding where in CC that you can upload anything but images.

If you are trying to replace the "Buy" button with an "Add to Basket" button, look at the relevant code in the viewProd.tpl file. In this file, pressing Add to Basket works. You just need to copy that functionality over to viewCat.tpl. The javascript checks that the form for which the form name passed to the submitDoc function is actually in the page being viewed. This hack looks to be just a bit more complex than simple. Maybe a discussion at www.cubecartforums.org might get you something.

I forget how phpMyAdmin (phpMySqlAdmin ?) works, but if I recall correctly, if you get a table listing of your inventory table, there will be checkboxes along the left edge that will group-do a few tasks: delete being one of them. I think.

I'm not sure what code is checking to make sure the file that was uploaded is a correct format for JPG, but if CC is using the GD extension to PHP, maybe that version of GD cannot recognize progressive scan (as opposed to standard) JPGs? I have received images from my graphics artists a few times that were JPGs but using the CMYK color-space, not the RGB color-space. Maybe you can use IrfanView (free) to examine the particulars of the problematic images.

Not sure where the "_notes" element in the path is coming from - that's not one of the stock languages. Is this a customized copy of an existing language file? When you copied the store to the new site, did you correct the serialized data in the config table of the store's database using the ConfEdit utility?