bsmither

A simple way (apparently, as I haven't verified this works everywhere) to disable checking the token, regardless if it exists or not, is: In /classes/sanitize.class.php, in the checkToken() function, there are two places: The first applies to the admin section. We will leave that as it is for now. The second applies to when payment gateways call back with transaction results. An exception is created. We will make that exception apply regardless. In this function, find: if (!empty($_POST)) { $csrf_exception = false; Change to: if (!empty($_POST)) { $csrf_exception = true; // Set this to false to restore normal CSRF protection!

To keep things straight, I would imagine there to be a three step process: 1. The customer checks out with making a payment in Authorize Only mode. This "reserves" an amount on their credit card but doesn't actually take it out. If the following steps do not happen, the 'reserve' is eventually released. Depending on the card's issuing bank, this could take up to a month (an extreme case, but I've seen it). (I'm not sure how the module's code records an Authorize - still at Pending or will it go to Processing.) 2. After consulting with the customer, or at least making the customer fully informed of the extra charges and discounts, the merchant needs to sign in to their payment processor's "Transaction Resolution" screen. There, adjustments are made and finalized. 3. The merchant then makes similar adjustments to the order at CubeCart's Order Summary screen. If not already known, and unless a plugin alters this, CubeCart accepts only one coupon per order. That one coupon either gives a fixed money amount or a percentage amount based on the sub-total, and/or affects shipping costs. When you say "the customer doesn't always get right", are you sure they can actually get to the right solution?

I think Hotmail is somewhat particular about whose emails get in. Perhaps a better test would be the Test button on admin, Store Settings, Advanced tab.

I have written several -- to the specs of what the report was to contain. The report is in the form of a CSV file. It was then up to the user of the delivered report to load the CSV data into the application necessary to print the data in whatever format and layout required.

Even so, searching for a customer that only exists on the Order Summary list - not in the Customer list - might only be accomplished through the admin, Orders, Search Orders tab. There you can search by customer name (although this seems to be broken at the moment - does not actually filter for the name). Anyway, I'll be working on creating a customer with no email.

That stands to reason. Is searching for a customer by their name important to your business?

What are your results (if you tried) to Create Order and just manually entering in customer details -- not first creating the customer?

Ok, my bad. You said "with phone orders of customers", I inferred you are creating an order, as in admin, Orders Create Order. This edit is for that action. In my experiments, I assumed the customer already existed. I see now that that was a bad assumption. You are also wanting to create a customer. I will experiment some more with a new Create Order and manually filling in the Customer data. For a phone order, if you need to actually Create a New Customer and enter in an address in their Addressbook, I will see what can be done about that. That may need more complicated edits.

Please try this edit. It seems to work for me. In the file /admin/skins/default/templates/orders.index.php: Near line 271, find: <div><label for="ajax_email">{$LANG.common.email}</label><span><input type="text" id="ajax_email" name="customer[email]" value="{$SUMMARY.email}" class="textbox billing required"></span></div> Change to: <div><label for="ajax_email">{$LANG.common.email}</label><span><input type="text" id="ajax_email" name="customer[email]" value="{$SUMMARY.email}" class="textbox billing"></span></div> You should now be able to submit the form at admin, Orders, Create Order with a blank email address. No emails will be sent that would otherwise be sent because there is no email address.

Won't hurt.

Please verify the version of the WorldPay module you are using. There was a syntax error in version 1.0.7 and earlier. Fixed in 1.0.8.

Sure, but assuming the screen grabs were taken at the same time, how does one get the new phrase but the other does not?

I was asking because of the phrases "Delivery Method" versus "Shipped Via".

No way to be 100% sure. So, you have a choice: spend more expensive time looking for more clues, or just keep an eye out for more of this.

That is where to change it. But instead, I found code in CC6112 that asks for a "Use this name" for the DELIVERY.method. The AIOS module doesn't use it, but, if you are willing, I would like to send you a set of code edits to the AIOS module to experiment with. The edits simply add the ability for the AIOS module to answer that question. It seems once the "Use this name" value is obtained, it gets propagated everywhere. Everywhere I have checked, that is. So, "All_In_One_Shipping" can get changed to just "Shipping" or whatever you want. Getting back to the images posted above, is the second image from admin? If not, where is it from?

In the skin template content.receipt.php: Find something that looks like: {if !empty($DELIVERY.method)} <div class="row"> <div class="small-6 medium-3 columns">{$LANG.catalogue.delivery_method}:</div> <div class="small-6 medium-9 columns">{$DELIVERY.method}{if !empty($DELIVERY.product)} ({$DELIVERY.product}){/if}</div> </div> {/if} There will at least be {$DELIVERY.method} and {$DELIVERY.product} The problem is that the $DELIVERY.method is generally the name of the folder, and are specifically wanting to overrule that if and only if the method is All_In_One_Shipping. You want the method to show if it is anything else. You might notice some anomalies: 'USPS' is the method and 'First Class' is the product. I do not know where the way it is expressed is coming from.

You installed CC5.2.16? When you say you have "migrated the store", you mean to say you did not copyany code from another version of CubeCart overwriting what was already there? If you can get into that CubeCart's admin, view the Maintenance page, Query Database tab. Don't do anything on this page - just look at the info shown just above the Query Box. This is the database server host and username. Next, click Maintenance again, Database tab. The list of tables will show the name of the database as prepended to the table name. Find CubeCart_inventory. How many records does it show? If there is 1 record, then what you are looking at via phpMyAdmin is not the same database (or database server) as what is in the /includes/global.inc.php file.

I read the response as saying an ID Code number of "0008650666" is not a valid number. You may need to apply for an account to use their online Rate calculator (if you haven't done so already). The error message may also show if there are no shipping modules that are installed/enabled. This number seems to be a 10-digit Canada Post Venture One number. As such, the next step is: * Request a CPC ID: To use Canada Post Sell Online, you'll need a CPC account. To obtain one, send an email to [email protected] requesting a CPC ID. Include the following information in the email: Company Name 10 digit Venture One ID number Address Contact name Phone number * Wait for Email Reply: Once your registration is complete, you will receive a CPC ID to access Sell Online.

Spelling error - the "web" page showing CubeCart's Order Summary for that order. Ok, so it is in the database CubeCart_order_summary.

'Hash' is a term that describes a series of letters and numbers that do not spell anything, and generally cannot be reversed into something readable. So, the 128 characters is a hash. That hash is computed by also using a randomly-generated salt value. Once the salt is generated, it is used along with the login username - they are swished around together to come up with the final hash. That final hash and the salt used to create it are databased. Then, when logging in, the username entered on the form and the databased salt are swished around in the same manner to come up with the same hash. If the computed hash matches the databased hash, then the username must be correct. Using phpMyAdmin, view the contents of the database table CubeCart_order_summary. The customer name in use at the time when the order was made is stored in this table. You are viewing an Order Summary, so you should be seeing the customer's name as it was databased when the order was made. If there is no corruption in the customer's name in the CubeCart_order_summary table, but is appearing on the wen page, then the corruption is happening somewhere in-between.

According to the code, clicking the Update Basket button will re-verify the items in the cart, and apply any discounts awarded by a coupon token entered on the form. That page is then sent back out. Shipping is not dealt with. Any other reason the form was submitted, including a change of shipping, if a coupon is to be added or removed, that is handled and that page is then sent back out. Shipping is not dealt with. Only with an auto-submitted form caused by a change in the choice of shipping is when a change in shipping is dealt with. So, I think we need to figure out how to get the radio buttons to auto-submit the form. "I switched my install to catalog mode whilst we sorted some things out." Could it be that the things that got sorted was to implement radio buttons for shipping choices?

Would that be the encoded password? The 128 character-long hash? If so, then the 'salt' value must also be the same. Catching this in CubeCart_customer is noteworthy, but what about the data in CubeCart_order_summary?

I have added something to the shopping basket and was taken to view the basket contents (?_a=basket). I am not logged in, so I get estimated shipping and taxes as applicable. At the "Your Shopping Basket" page (not yet at Checkout), I see the two choices of shipping: "Collect and Mini Standard". The placement of the radio button selector is not where I am used to seeing the shipping choices. Currently, 'Collect' is chosen (the cheapest), and when I select the other, nothing happens. I believe this to be a a problem, but not the problem. The choice of shipping does get POSTed when the Update Basket is clicked. It seems that CubeCart does not switch to using that choice. (Your initial post suggests that the problem is that the shipping selector does not appear. That is not the case for me. The shipping defaults to 'Collect" at zero-cost.) To go further, I would like to discuss troubleshooting via email.

Please use an external database utility to view CubeCart's database directly. In CubeCart_order_summary, examine the customer data for the suspect order.

For the domain having problems, log in to the hosting provider account's control panel (Cpanel?). There you will find a tool to construct and configure your database for this domain (this tool is NOT phpMyAdmin). This tool will tell you the Host:, Database Name:, and authorized UserName(s): and to create passwords for them. Currently, for some reason, the database server this CubeCart is connecting to does not like the user 'ssilberberg' or its password for either being wrong, or has no authority to use this database.