bsmither

Ioncube is a PHP extension (commonly installed on commercial hosting platforms). It's purpose is to execute code that has been pseudo-compiled and obfuscated so that reverse-engineering is (virtually) impossible. This allows code to enforce licensure restrictions - as well as completely hide what the code does.

Where did you modify this value? In the PHP.INI file? In CubeCart's Session class, this value is overwritten if it is less than 604800. You can verify this value in CubeCart's admin, PHP Info screen.

I would argue it is the plugin's responsibility to provide the form validation. I disagree with the core code providing specific and dedicated support for distinct plugins. But that's just me. As I see it, the "Basic PayPal" takes the customer to PayPal's site to make payment. This most closely resembles Authorize.net's SIM method, whereas this situation is using the AIM method. There are assumptions made prior to displaying the AIM form: the initial form is populated with basket billing address data. If the form is getting re-displayed with empty fields, then it must have happened after CubeCart discarded the basket after a successful transaction. The question is, what is causing the form to be re-displayed? The gateway class code suggests the module should not call the process() function unless $_POST['cardNumber'] is set - presumably with a card number but could be anything.

Please make the code edits I have posted earlier. If you have in fact done this, we need to troubleshoot a bit more.

In this statement: <ul banner1.png="" class="bxslider_homepage" style="display:none;"> The code banner1.png="" is not necessary.

This happens to me with my commercial-grade hosting provider, and never with my "localhost", nor never with the in-house server under my complete control. (See my sig.) I blame my hosting provider. You may want to consult with yours.

If this is what you used: <?xml version="1.0" encoding="UTF-8"?> <definitions version="1.0"> <string name="module_title"><![CDATA[Tax Exempt Customers]]></string> </definitions> then please use this version instead: <?xml version="1.0" encoding="UTF-8"?> <definitions version="1.0"> <group name="tax_exempt_customers"> <string name="module_title"><![CDATA[Tax Exempt Customers]]></string> </group> </definitions> I am just guessing about the group name. The error references line 246: if(!isset($content->group->string) && !isset($content->group[0]->attributes()->name)) { Without the 'group' node, the first expression is true, so try the next expression. However, since there is no 'group' node, that part of the object chaining resolves to 'null', and the attempt to use the attributes() method on a null object fails - fatally. PHP crashes and you get the white screen of death. The revised code follows CubeCart's 'Language version 1.0' node hierarchy (schema).

This is what my browser has for the HTML sent: <ul banner1.png="" class="bxslider_homepage" style="display:none;"> <li><img src="images/homebxslider/Banner1.png"/></li> <li><img src="images/homebxslider/Banner2.png"/></li> <li><img src="images/homebxslider/Banner3.png" title="" /></li> </ul> The 'banner1.png' attribute shouldn't be there, but probably isn't causing any damage. I also see this: $(document).foundation({equalizer:{equalize_on_stack:true}}); $('.bxslider_homepage').show().bxSlider({auto:true,captions:true}) .show().bxSlider({auto:true,captions:true}); $('.chzn-select').chosen({width:"100%",search_contains:true}); The second line has too much code, although I do not know if this is the problem. That line should be: $('.bxslider_homepage').show().bxSlider({auto:true,captions:true});

Welcome GarlandsO! Glad to see you made it to the forums. Please verify that the file /includes/functions.inc.php has this function - probably located at the end of the file. If not, then perhaps an upgrade step missed getting this file replaced. Download a fresh copy of CC448 from CubeCart.com and replace the existing file (unless you made modifications to the existing file - then just add the missing function). If it is the case that this file was not upgraded, give some thought to the possibility that other files may not be at the CC448 version.

Latest versions of CubeCart have a session timeout of 604800 (seven days). This value is then assigned to session.gc_maxlifetime and session.cookie_lifetime. However, on a local dev machine, this works as I can work on Monday and get back to it on Saturday and the session would still be alive. On a working installation on a paid hosting service, the session is lost after about an hour or two. So, you may want to confirm with your hosting provider if there is some other factor being imposed upon your site's session length.

Welcome Hollister! Glad to see you made it to the forums. I will test this with CC6112. The order should be at Pending. That is, the order has been placed but not yet paid for. Once paid, then the admin will manually set the order to Processing. Once the product has been given to the shipping company, the admin manually sets the order to Completed. Sometimes the customer can cancel an order, and the admin can manually set the order to Cancelled, but the payment gateway does not (I do not know if maybe one of the PayPal modules can do this). In admin, Store Settings, Features tab, there is "Order status for admin email notifications". Actually, you only have a choice of Pending or Processing even though all order statuses are listed. So, when CubeCart sends the order to the POF, and if that choice is Pending, the email address used as the store's general email address and any email address for admins who have checked the related box in their profile will get the email advising of a new order. The POF, if set to send the email, will send the email the customer would get when the order goes to processing. Please check this setting in the POF configuration screen. However, if the order somehow went straight to Cancelled, the customer should have received the specific cancellation email, but the admin would not be notified of that action.

Including the red banner with a reference to indexupgrade.inc.php?

That will work.

The eTone starts with setting all font size to 14px. It then overrides specific selectors with specific values, such as a class of 'price_previous' that follows a class of 'price' (common.css, line 299). But there isn't any CSS for just a class of 'price' (defaults to using the global setting), nor any CSS for a class of 'sale_price' that follows a class of 'price'. In common.css, find near line 296: .product-list .price{ font-size:1.1em; } .price .price_previous{ font-size:0.8em; text-decoration:line-through; } Change to: .product .price .price_previous{ font-size:0.8em; text-decoration:line-through; } .product .price .price_sale{ font-size:1.1em; text-decoration:none; } .product-list .price, .product .price{ font-size:1.1em; } There is a problem, though, as now the product panels are no longer the same height - those with no sale price are shorter. This causes irregular placement of the panels. I'm still trying to sort that one. Because you have edited a page resource, you will need to force your browser to fetch all new copies of these files. This is generally done with CTRL-F5.

The product's friendly SEO URLs are stated on the Search Engines tab.

When uploading the new CubeCart package, you will be 'overwriting' all existing files. The existing file /includes/global.inc.php contains info specific to your installation - thus this file cannot exist in a CubeCart downloaded package. It won't have the right info, and you wouldn't want an empty file overwriting the existing file. Existing files not found in the downloaded package will not be overwritten (images, other skins, languages, plugins, etc). Look in the existing global.inc.php file and rename the extracted admin.php and admin folder from the downloaded package to those names. Then, the upload will correctly overwrite the existing admin file and folder with the accurately-named admin file and folder from the package. For most scenarios, you may ignore the file /includes/global.inc.php-dist. This is included for those who want to study what information is required should they wish to fool about with the installation. An upgrade (or same-version reload) uses the existing global.inc.php, and a fresh installation creates a new global.inc.php, renaming any existing global.inc.php to have a dated backup filename.

It's easy but the process requires direct access to the database. In CubeCart_sessions, find the record that has the IP address you want gone. Delete the row(s). Unless someone with that cookie value (session_id) is making page requests, it should disappear eventually anyway - maybe a week?

Some of the weird things involved mobiles in some fashion. (I don't do this, so I cannot say for sure) It may be the case that the browser on the mobile device had logged in, did some stuff, etc, while using the data plan. Then, later, the browser, still having the logged in cookie, but now using Wi-Fi, accessed your site. The IP would be different, but use the same cookie. (Again, just a wild guess.)

Are the Session Start times close together? Could it be that you first tried to access your admin using admin.php or /admin/index.php? Recent versions of CubeCart will cause a 404 response for that. But I have no answer for the different IP addresses. On the other hand, I have seen some weird stuff in error_logs I have examined.

Yes. The checkbox should appear when registering, but otherwise, at checkout. This depends on the skin being used. I am not aware of any skin that does not have the code to show this. In admin, Documents, the list o documents will have a column of radio buttons to indicate which document is to b used as the T&C document. There must be one selected.

Welcome Beagle Bytes! Glad to see you made it to the forums. Do the regulations say there must be a "specific" notice - visible and uniquely selectable at each and every sale? Or do you think that CubeCart's ability to require an unregistered customer to read the "Terms and Conditions" document in order to progress through the checkout process, or to read the "Terms and Conditions" document in order to complete the registration process, would suffice? Currently, the checkbox says "I agree to the Terms and Conditions," which is a link to that document. But if the regulations say that the checkbox must say something specific about waiving a right, we can change the phrase to include "and Waive Certain of My Rights." The Terms and Conditions document would have all that verbiage.

We may need to see your site to discern the cause of the problem. If possible, please let us have your site's web address.

At Authorize.net (account.authorize.net), view the AFDS settings. Here are some code changes that will make CubeCart's response more friendly. Keep in mind, however, Authorize.net, probably because of AFDS, has NOT put this transaction in the batch. The money will NOT transfer from the customer to the merchant unless and until the Merchant has 'approved' this transaction. In /modules/gateway/Authorize/gateway.class.php From: private $_result_message; To: private $_result_message; private $_result_status; From: } elseif($results[0] == 3) { $status = 'Error'; $order->orderStatus(Order::ORDER_PENDING, $cart_order_id); } if($results[0] != 1) { $this->_result_message = $results[3]; } To: } elseif($results[0] == 3) { $status = 'Error'; $order->orderStatus(Order::ORDER_PENDING, $cart_order_id); } elseif($results[0] == 4) { $status = 'To Review'; $order->orderStatus(Order::ORDER_PENDING, $cart_order_id); } if($results[0] != 1) { $this->_result_message = $results[3]; } $this->_result_status = $results[1]; From: // Display payment result message if (!empty($this->_result_message)) { $GLOBALS['gui']->setError($this->_result_message); } To: // Display payment result message if (!empty($this->_result_message)) { switch ($this->_result_status) { case 1: case 4: $GLOBALS['gui']->setInfo($this->_result_message); break; default: $GLOBALS['gui']->setError($this->_result_message); } } I strongly urge that Authorize.net's actual message that is returned with a "Hold for Review" status be changed in the Authorize.net Merchant Account interface (account.authorize.net).

I cannot reproduce it on CC6110, and if, as you say, this was happening with CC618, then I should be able to see something. PM sent.

This situation is quite probably the result of the Merchant having enabled Authorize.net's "Advanced Fraud Detection Suite" (AFDS). Here are some links that discuss it: https://support.authorize.net/authkb/index?page=content&id=A509&pmv=print&impressions=false https://community.developer.authorize.net/t5/Integration-and-Testing/Held-for-Review-Status-to-do/td-p/29840 https://community.developer.authorize.net/t5/Integration-and-Testing/Are-quot-held-for-review-quot-transactions-included-in-the-batch/td-p/48673