SimChris

Tip to all with this issue ... get in the habit of capturing the I.P. address of those creating accounts, as saved by your store. Keep these in text file, or excel spreadsheet, or whatever. You can check who/where the location is by using the WHOIS for either the U.S. or other countries to see WHERE that is coming from. If it's a country you won't ever do business with (Romania, Argentina, Iran, Iraq, etc.), you should create an .htaccess file or edit the one you have to BLOCK access to your server from those IPs. So, if you end up with 20 "fake accounts" in your store from Russia, well guess what .. block the suckers from access to your site entirely. Only way to fly. We do this here both at server level for hackers, and at domain level for abuse. A ban IP option in the store itself would be useful, too, at some point.

Finally upgraded to 5.15 today from 5.14; no problems. My server doesn't do the "auto upgrade" from panel due to permission settings; but the FTP upload, and manual upgrade button worked first time, per usual (changing the includes file permission to 777 of course). Only notable "change" I saw was that my custom skin file for the top right cart box no longer used, which implies new locale/file for that element, not a problem. I had added my hours of operation and phone number to that box along with a login/register link (seems good place for that, no?). Other than that, seems to work with all my customizations. Yay. Need to go through the list of what has changed in the skins to paste in any major things needed for compatibility. but, so far so good! Thanks for the regular updates to CC5. Chris

Thanks for the heads up on this ... it's been a major headache past couple of months with clients having this issue. Now solved ! Should have checked the forum sooner. Thanks to CC for keeping this forum so active. Realllllllly helps! Did the 5.15 upgrade today from 5.14.

And ... I solved my own problem (again... aren't I special!!) ;-) OK, you can mark this one RESOLVED. For anybody searching for this it will help. YES: the correct variable to add the customer comments box to your customer/admin email templates in the CCadminpanel > email temlplates is: {$DATA.customer_comments}

Hmmm... don't think it was me about the photo on packing slip, since we sell services, we only need the "special instructions" from customer to show on the emails. This is different from the store comments, which we don't need after all. Just need that box where the customer can type in comment/instructions during checkout. Looking at the /templates/content.receipts.php there is this varialble: {$SUM.customer_comments} SUM.customer_comments so .... would I use {$DATA.customer_comments} I just put that into the email templates via CC5 admin panel... and nothing blew-up, so I suppose next step is to do a test order .... Anyone else done this one previously? Thanks!

Hi, I thought I posted this already but seems to have been eaten or I'm losing my mind (both?). On the checkout screen is an option for customer to type in any special instructions, or notes, and we use this for stuff like the ability for them to put in a purchase order number, or anything like "chris said special discount ..." or somesuch. This comment box from customer prints okay on the printable invoice, but the shortcode to add that element is not in the list found for the email templates. Anybody know what that is? We MUST be able to have the customer comment on the emails, as we use those to internally track projects, and customers most of the time rely on email receipt, NOT printing one post checkout. Thanks for any pointers! Chris

hey all... just a note about best practices for SEO, site loading and all that. In an "optimum" situation, once the system works properly, the current "web 3.0 / HTML5 / nextgen" think on loading jquery from Google is to actually do a if/then query to Google where if the code doesn't load due to problem with Google, it will fall back to loading the .js locally. Sometimes if your page is slow to load, it's waiting for Google ...(folks who run Adsense or similar know of what I speak...). <!-- Grab Google CDN's jQuery. fall back to local if necessary --> <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script> <script>!window.jQuery && document.write('<script src="js/jquery-1.4.2.min.js"><\/script>')</script> sorry... this may not be relevant to the issue of problems with sortation, javascript ,etc.

have no idea how permissions got reset ... but folders were all pretty much 'un-writable' ... I had to use the setup program to "reset" the folders by running the upgrade, and going through for it to show all appropriate folders were writable; then had to force reinstall my key, by making the key file writable (!). Managed to get back in, and back up and running. I *think* this issue had something to do with Plesk trying to install sub-domain into the root httpdocs domain as hidden sub folder, vs putting outside of public root into the /subdomains/ directory. I have to say, Plesk/Parallels has been a bundle of fun lately also. (WAAHHHHH!). The java fix seemed to help with stuff like the "sortation" on category pages, thanks! You can make this topic resolved -- or remove it entirely unless you want to make a "warning" about trying to install sub-domain resetting permissions on php scripts in the public root. Didn't impact my cgi-scripts, but seems to have whacked some php stuff like cubecart. (SIGH.)

Hello - as of this afternoon, I cannot login, white screen of nothing; and clients trying to add stuff to cart get redirect back to home page. Will try to apply the java fix, but this is so bad, it's really painful. Wishing now we'd stuck with the 'end of life' 4x version... (sigh) C

+1 on this question. :-)

RESOLVED (apparently). I only tried to do one test order, but it seems to work now. What I did: a ) cleared all cache stuff under dashboard > maintenance b ) then ran "repair" vs "optimize" on the database, for ALL tables placed new test order under my own test account, same one that wouldn't print yesterday, but for different item. No trouble printing receipt. However, as time permits will re-test with multiple items; multiple quanties on some. For the moment at least, I was able to print and see the printable template on screen. WHEW!

Thanks :-) No rush; just useful to be able to check for bugs before polluting the support forum for stuff already 'known.' I did submit request last month (July) but never got email. So, the system doesn't appear to send emails at this time automatically (we don't have IP block on the CC servers).

also, looks like store properly fixes normal ASCII entities in product names/titles: I just changed something like this: 4-States Plan 4&#45;States Plan and the store shows the 4-States Plan when opening product again to view. Similarly the ASCII entity for / So, we do use - / : $ . in some of the product names, but looks like it escapes them fine. We never use " or < > ' - and for & we would likely do &amp; to properly escape that. But I'm a big believer in using the word "and" over & anyway. ;-) Ha.. of course, unrelated to that I installed the Goober related products thing, and that plugin generates some errors when updating some products File: [admin.product.save.post_process.php(1) : eval()'d code(1) : eval()'d code(1) : eval()'d code] Line: [20] "UPDATE `CubeCart_GWorks_Product_Accessories` SET `id` = '1',`accessory_price` = '239.99' ;" - Duplicate entry '1' for key 1 Sheesh.

Second request for login/password; still no email from the system to verify.

UPDATED: (un-related to testing the print button working .... related to elements in customer fields ) note I did check one client whose first name is J'ai and just for laughs tried to update client (changed newsletter no to newsletter yes, retyped the name J'ai ...); got: ERROR unable to update client. Noticed in the title (we use as salutation), she has "Mrs." ... changed to "Mrs" and resaved : success. So, looks like the "title" field may have issue with periods, which could be problematic with "Mr." or "Ph.d" or "Dr." .... so possible "bug" there. Wil resubmit request for access to bug track again. Never heard back on original request from last month. Chris

Thanks. Happy to help with the free debugging of the software I've paid for. Always fun to waste my time on fixing things that work in on one version, then break on the update. Hopefully we'll get a fully functional version at some point. Since we generate millions of page views per month, it's a little time consuming to check error logs, hence not first thing to do when a new bug is found in the application. When I have time I'll go through and spend my time again on placing an order to get to the print receipt link, then have to see what if anything is in the source; then will have to go in and void the order, clear the pending item in the gateway, etc. (sigh). Will update when I can, since there is not a currently known fix for this issue, apparently. Frustrated. Waited for 5.1.1 to upgrade from 4x. Still buggy. Annoying, but will keep at it. Also dealing with an Amazon EC2 customer in their cloud system who has been actively trying to hack our server from no less than 10 different IPs in the EC2 system. Day off? what's that? "Life is an illusion, lunchtime doubly so." -- Douglas Adams THANK YOU for your help and feedback; sorry to be a di*k about it today. No - none of the items have high ascii characters, as we avoid any odd naming conventions for all things. But will check that just to double check. Would presume the store would convert any high ASCII elements to proper escaped elements such as a customer name J'ai ... where the ' would convert to an ASCII element.

Hi, updated today from 5.1.1 to 5.1.3 and a client in US couldn't checkout via authorize.net without getting the "not enabled for your country" error, even though the admin panel still showed the authorized zones under the gateways > authorize net settings. I deleted the US one, saved it again. Was able to checkout. If you rely on these zones, you likely should delete all of the enabled ones, and resave them to be safe. Not sure if it impacts other gateways, but I resaved the paypal ones also. Chris

Hi, just updated and ran into couple of client problems 1) client got error saying their ship to wasn't in a supported country; so I am using authorize.net as default and paypal as optional. I went in an resaved the allowed countries for US. Was able to place order no problem; haven't seen order from client yet. 2) when I completed checkout I clicked link to print receipt, got blank screen. Previously with 5.1.1. this worked.

Also, fyi, with some hosting platforms now; including Plesk/Parallels on LInux with the latest versions, I don't believe a dedicated IP is still needed for implementing SSL due to some clever internal DNS trickery. I remember seeing this in one of our system updates not long ago, so I don't have link to point at, but check with your hosting provider. We manage our own DNS as well, so it may only work in that instance, not sure. But I do remember seeing this as a new "feature" due to the idea of making dedicated IPs less necessary for hosting environments due to so-called "scarcity" of IPv4 IP addresses. Upshot - you may not need to pay extra for dedicated IP with your host if they have updated their core OS and hosting panels to 2012 versions. And, SSL is good for any site which has a username/password environment, working with customers.

awesome... was just looking for this, and just what I needed to sort out my skin file updates. THANKS!

HI, I wanted to offer some information about SEO. YES: http://www.yourstore...t-t-shirts-xxl/ is better than http://www.yourstore...duct=5&size=XXL Google does prefer "pretty URLs" now when there are 2 sites with similar content, same "weight" (not page rank). We've been doing SEO since March 1995, and Google *DOES* now incorporate the text found in the URL as part of its hinting for results -- in fact, this is clearly noted in their latest and recent SEO guidelines on HOW THEY see optimized websites. If anybody hasn't read that, then you should as it's pretty eye opening for the layman and shows you the majority of what must be done, and so you don't have to pay a "predatory" SEO firm to do what is already explicitly described by Google as the "right" way to do stuff post Penguin and their current algorithms post 2011 changes. Beware copies of this on fake sites with google or seo in the URL, or hidden redirects -- this is the official link on GOOGLE's webmaster portal. http://www.google.co...arter-guide.pdf (PDF) the info page http://support.googl...en&answer=35291 AND: the basic Google guide for webmasters ("Webmaster Guidelines") http://support.googl...en&answer=35769 I highly recommend anybody even speaking on the topic of SEO please first read the above 2 docs, as I can tell you from personal experience running a large news network, and building sites as long as I have that it's a NEW WORLD with search now. And some stupid things that used to not matter (like titles in the URL), do now matter to Google.

A self-signed SSL cert is better than nothing, but it provides no info for the visitor from a third party. You should technically have SSL for anything that is a log-in, and Google and others are starting to enforce that kind of link for some things, and may at some point throw up their own 'warning' when going to any login page without SSL. Realistically, even with a cheap GoDaddy cert, you're better off giving your customers peace of mind. I won't fill out any login/password without SSL, particularly since stuff CAN be intercepted in various ways - especially if you're on a shared server, etc. SSL makes that point to point "lock" safe from a lot of stuff. We also use authorize.net, so we have to use SSL also for the secure connection. It's also nice that the connection from our system to PayPal is secure on both sides.

Some people can mask their IP via a proxy of some kind, but you should still see some kind of IP. The benefit of capturing the IP is multi-fold; we've run into issues where a fraudster is placing order from Australia, claiming the card is from Arizona, but then putting in a company address in Florida. Doh. IP is super useful for friendly fraud, also, since you can enhance the proof of the AVS passing (don't take order without AVS pass, or you set yourself up for fraud), by showing IP of the purchase, and often it's in the same vicinity of the customer's billing info (e.g., Los Angeles, or Chicago, etc.). --- speaking of customers in the US of course ;-) We've gotten our money from Amex with couple of creeps who tried to claim they didn't place the order, when we had valid IP showing tt came from THEIR INTRANET (!), and the AVS matched, and we had emails from their staff from their email accounts attached to their valid domain names. So, IP isn't 100% full proof, but it's an extra line of defense (or defence for you euros) to help stop potential fraud. Since we also have clients fill out a project form, we have second chance to capture IP and if it's radically different - differetn state, different service provider, etc., we also flag that to double check. If you're selling $10 t-shirts no reason to obsess too much. If selling a $700 service, you have to be crazy paranoid. IP helps!! :-)

Hi, all bsmither: we changed the admin file name and ini file per the help from CC support. Will change back once I get the all clear on our latest PCI-DSS compliance scan. SO, that should fix those little gotchas like the image stuff not showing, etc., which worked perfectly prior to the name switch. Yes, it was changed in the global file also (otherwise it would really have crashed!) ;-) Thanks for the double check on that. I think the SEO error in the log, I think that was from one of two things, the pci-dss scanner throwing long strings at the system to see if it could be gained from injections, etc. (my shop error log showed about 85 hideous string array hack attempts); and also with the store update some of our 3 year old page URLs changed, due to the new (BETTER!) seo structure for "pretty URLs" vs the old method - or put another way, the new seo URLs are slightly different from our old SEO URLs generated by the store. I had to change some of the on-page links, or in-description links to things like t the terms of service, how-to-order page, etc. - so a combination of those two things were - I think- generating 404 errors, technically. Since the store doesn't support a 404 redirect (ahem) for missing pages, the shop defaults back to our site wide 404 to go back to main front page of site outside of the store. I need to do some 301 redirects in the htaccess for the old URLs, which ... stupidly I forgot to do until today. (DOH). So - good reminder there: for those who upgraded and their SEO URLs changed, be sure to do 301 redirects from old URL to new one! :-)

e.g. (client IP and actual domain obfuscated) [Tue Jul 31 22:44:52 2012] [error] [client XXXXX] PHP Fatal error: Call to a member function update() on a non-object in /var/www/vhosts/MYDOM/httpdocs/ecom/classes/cart.class.php on line 934, referer: https://www.MYDOM/ecom/index.php?_a=gateway [Wed Aug 01 01:51:18 2012] [error] [client XXXXXXXXX] PHP Fatal error: Call to a member function read() on a non-object in /var/www/vhosts/MYDOMAIN/httpdocs/ecom/classes/seo.class.php on line 711 [Wed Aug 01 02:03:08 2012] [error] [client XXXXXXXXX] PHP Fatal error: Call to a member function read() on a non-object in /var/www/vhosts/MYDOMAIN/httpdocs/ecom/classes/seo.class.php on line 711 [Wed Aug 01 02:48:51 2012] [error] [client XXX] PHP Warning: Security Warning: Dirty array key "$Version" detected and was removed. in /var/www/vhosts/MYDOM/httpdocs/ecom/classes/sanitize.class.php on line 104 [Wed Aug 01 02:48:51 2012] [error] [client XXX] PHP Warning: Security Warning: Dirty array key "$Path" detected and was removed. in /var/www/vhosts/MYDOM/httpdocs/ecom/classes/sanitize.class.php on line 104 [Wed Aug 01 02:48:51 2012] [error] [client XXX] PHP Warning: Security Warning: Dirty array key "$Version" detected and was removed. in /var/www/vhosts/MYDOM/httpdocs/ecom/classes/sanitize.class.php on line 104 [Wed Aug 01 02:48:51 2012] [error] [client XXX] PHP Warning: Security Warning: Dirty array key "$Path" detected and was removed. in /var/www/vhosts/MYDOM/httpdocs/ecom/classes/sanitize.class.php on line 104 need to get updated error log, this was from couple days back, obviously ...