Jump to content
Latest News: (loading..)


  • Content count

  • Joined

  • Last visited

  • Days Won


MrPhil last won the day on May 21

MrPhil had the most liked content!

Profile Information

Recent Profile Visitors

104,317 profile views
  1. Shopping basket empty After SSL

    For "new", please consider the unofficial, but community-supported and completely up-to-date Edge/CE/Frozen/Final (see my signature link). This is NOT what you get from the official download page, nor from your host's installer. It will be far easier to transfer your data to this version than to another product. You need to stay reasonably current with your osC shop (or any shop, for that matter) so that you can run on current PHP levels and upgrading does not become a royal pain, from having to jump so many versions. Do not get too far behind on PHP versions. Older ones are quite vulnerable to hacking. The oldest currently supported version is 5.6 (goes out of support at the end of the year). 7.2 is the current release, which Edge should support OK. However, there are limits to how recent a PHP version your version of osC will support -- likely no higher than 5.4. Uh, that's confusing. Did you have a working SSL and then it broke or expired? At any rate, you think you now have a working SSL cert? Have you confirmed that the domain name is the same as before (on the SSL cert)? What has changed, besides the SSL cert? Was the PHP version upgraded at all? You should check, in case the host forgot you want an old version. Did you change from SSL only on selected pages, to SSL on all pages? Was the domain name in the cert changed (adding or dropping the "www.")? Something has changed if your cart no longer works!
  2. If your SSL cert is specifically for non-www domain name, and it's not a "wildcard" or otherwise permitting optional www or not (or even other subdomains), you should change everything to the non-www form: config.php files, .htaccess redirects to https, etc. (along with redirecting www to non-www). You'll need to ask whoever issued the SSL cert what it covers, just to be sure before you start making changes. I'm assuming it's just mysite.com. Do a 301 redirect from www to non-www (also http to https) so that search engines update their indexes. If it's a wildcard cert, or at least permits both www and non-www, choose one form and be consistent with it in all your config.php, .htaccess redirects, etc.
  3. Can such a system handle the load that's going to be placed on it? When it's down (it will be a prime target for DoS attacks) what will merchants do for backup? I'd be more comfortable with a more distributed lookup system. In most states, tax jurisdictions do not align with ZIP Codes. That is, a ZIP (postal) code may easily span 2 or 3 tax jurisdictions (e.g., across county or city lines), so merchants are specifically warned not to use ZIPs to look up tax rates. However, everyone knows their state and ZIP, but most don't know their county and even fewer know their tax jurisdiction number, so any system will have to be by ZIP (or just statewide). It will have to be up to each state to apportion tax revenue from a ZIP Code to the several tax jurisdictions it overlaps.
  4. We will, although most states only require reporting a total amount of sales and tax collected per tax jurisdiction per tax class, not broken down by components. The real problem is that there are +/- 10000 tax jurisdictions in the US, and every one can do things its own way. The outcry is going to be so great that one of three things will happen in each state: Sales tax will be eliminated, because it's so regressive (the poorer you are, the greater the percentage of your income that goes to sales tax). There will be much rejoicing throughout the land, followed by tears and lamentations when income and property taxes go up. Small businesses will be excluded from online sales tax collection because it's so hard. Slightly larger businesses will then lobby to also be excluded; repeat until no one is collecting and remitting sales tax. The various States will consolidate their tax rules (tax classes, etc.) into a few classes in effect nationwide; they will either have statewide rates or rates by ZIP Code (two things that everyone knows); and there will be a one-stop system to remit collected taxes. Dream on. I think it's going to take Federal (Congressional) action to set the rules for Number 3 -- who knows how that will play out in court if a state decides it doesn't like the plan. That's the only way I can see it working.
  5. Interesting. So if all the products in the cart are downloadable and physically shippable, you'd like the customer to have the option to choose one or the other in one place (rather than individually)? If they choose downloadable for all, skip the checkout_shipping step? From a customer viewpoint, I would think the best way would be to when I'm in the shipping module, to be asked "All your products [or, you have some products that] can be either physically shipped to you, or made available via download. Which would you like to do?" That way they would not have to make a selection for each product, and you would not have to be making odd changes to the code, which might come back to bite you some time in the future. If they choose download, the code would just go back and update all the applicable products to "download" (virtual), and if no physical products are left in the cart, exit checkout_shipping at that point. From your perspective, you might have to add some wording to product descriptions that both methods are available, or that could even be automatic if both "downloadable" and "shipping weight" are entered. Worth thinking about.
  6. The toughest part will be coming up with the right WHERE clause to deal with just the desired category's entries. Blending category information with product data may require a few JOINs in the clause. After that, something like SET weight='3.0' should be trivial. You can play around in phpMyAdmin and see if you can come up with a SELECT statement just for the items you want, and then change it to an UPDATE statement with the SET. Depending on whether this is going to be a frequent operation or is a one-off, you might find it easier to gather the information playing in phpMyAdmin and manually build an SQL file with a bunch of updates, and import it into your database. It would probably be a good idea to back up your database before doing any updates/writing/imports to the database.
  7. Let me see if I've got this straight. You have a main site "all-kinds-of-jackets.com" with a store. Then you have an "add-on domain" (different hosts may call these different things) "denim-jackets.com" which is a discrete, independent website, although it is implemented on your host as a subdirectory under public_html/. Right so far? Then you redirect from denim-jackets to all-kinds-of-jackets (301 redirect or 200 rewrite?) so the visitor is in the main store. Was the redirect via .htaccess (will differ by whether you see the domain name or it was already translated to main domain/subdirectory), or an index.html with a redirect meta? A visitor to denim-jackets.com should instantly find themselves in all-kinds-of-jackets.com. OK, what has changed? What is Google doing differently? You still want to pop over to the main store? Is denim-jackets now a fully separate account, rather than an add-on? That would probably have to be a 301 redirect (if you weren't using it before), but otherwise there should be no changes. If you have a single 301 redirect to move over to the main store, Google shouldn't be complaining about that, but if you have several layers of rewrites/redirects it could penalize you. I don't know if they count an index.html with a redirect meta tag as a single redirect. Just be careful that you're not causing multiple redirects (round trips between the server and browser or search engine), such as using one to tack on "www." and another to change http: to https: and still another to go to a new domain. Google will really ding you on that. Also remember that for an add-on domain, the main domain's .htaccess should be visited every time, before the add-on's .htaccess.
  8. Installing Mistake

    You don't ever want 777 permissions, if you can help it. Long ago, when you could trust everyone sharing your system, 777 was harmless. However, it opens the doors wide for anyone sharing your server (and sometimes, people coming in through the web interface) to look at and change files. It's basically turning security off. Anyone telling you first thing to "change all permissions to 777" is an idiot and you should avoid them. In some extreme cases, with a poorly configured server, PHP may be running as "other" or "world" and you may need to chmod 777 (world writable) on selected directories so that PHP can write to them (temporarily or even permanently), but those cases should be few and far between. Some systems may even still require PHP files to be marked "executable" (7 instead of 6) but that's rare. Start with the most restrictive permissions you can (usually 644 for files and 755 for directories), and loosen permissions as needed for the system to function. By the way, if you're running your own server to save money, without professional expertise, be assured that hackers know far more about security exploits than you ever will. It's false economy, as you will be hacked. And it's worse with ecommerce, because real money is involved.
  9. That's an unusual case (to have downloadable products, but limited quantities like a physical product). The system was written assuming that you have an infinite supply of whatever you're downloading. If you've managed to implement limited quantities, congratulations. I'm curious as to why you would have limited quantities of a downloadable product. If you have to customize each download (serial number, etc.) rather than being a simple copy, and you do it in a batch process, maybe you can look for a way to automate the customization as the product is sold and put in the download area.
  10. The errors you're getting suggest that you have a fairly old version of osC, and you've moved it to a fairly recent version of PHP. Suppose you tell us exactly what version of osC you're working with, and what PHP version on the old server, and what PHP version on the new server? If it will be more than a trivial amount of work to update your store to work with the new PHP version, you will find it much easier to install the latest osC ( Edge/CE/"Frozen") on the new system and migrate your data over. This assumes that the new system is at PHP 5.6 or higher, which is the oldest supported PHP version. $language not defined (the "/.php" errors) is a sign of old osC and new PHP. MySQL deprecated is a sign of newer PHP versions. The most recent osC release uses MySQLi.
  11. OK, being in the US, it figured out that I don't need to pay any VAT. What if I were a French citizen who happened to be on a business trip (or holiday) to the US when I placed the order? Or I was in France, but using a proxy outside the country? Once I gave my billing or shipping address, presumably it would update the VAT to the proper amount, but is it legal for your site to quote one (low) price for display, and increase it at checkout (VAT to be added in)? I would think that at a minimum, I should be able to click on something around the VAT notice to give my country or province (whatever is needed to figure the VAT rate), to display the correct price with VAT. Or have the authorities admitted that it is not practical to show correct VAT on a website (until the shopper takes some action to give their location), and now allow a "without VAT (select your location)" price? In the US, it is customary to display prices sans sales tax, but something similar could be done to update the product display with possible shipping costs and sales tax, given a ZIP Code (postal code), either by manual action by the shopper, or by their signing in.
  12. Depending on the exact order of addition, multiplication by non-integer amounts, and rounding of intermediate results, it's easy to get a penny or two of difference in totals when using different computation methods. If you're getting close to .50 difference, though, something is badly wrong. Generally, most differences end up canceling out (plus and minus), and should not keep adding in one direction. Have you checked that PayPal isn't handling shipping amounts (or tax on it) differently from osC?
  13. For the vast majority of online shoppers, the lowest possible price (so long as the service isn't too painful) rules. The biggest retailers, like Amazon, who can put the most price pressure on their suppliers, will win. There used to be a concept of "trusts" and "monopolies" and "anticompetitive behavior" which governments tried to put an end to, but they all seem to have given up on that, allowing (and even encouraging) ever-larger businesses. Some day very soon Amazon will be large enough to start dictating government policy, and no one will be able to stand up and say, "no." Just look at all the state and city governments falling over themselves to be HQ2.
  14. Well, you still have to know who the customer is before you can tell them the VAT amount. My point is that VAT has always had to be included in the displayed price -- has that requirement been relaxed recently? Is it now legal to display a price "plus VAT" in any country where VAT is collected? If you don't know where the shopper is (geographically), you don't know the VAT rate is, and an IP address is insufficient to determine the whereabouts of the shopper (not to mention that they may be using a proxy or be out of their country when placing the order). Once you know the billing or shipping address of a signed-on customer (or they've filled out the information as a guest), it's simple to figure any tax rate. I assume that no one wants to require that a potential customer sign up/sign on before they can see prices.
  15. My assumption since the first post is that VAT must be displayed for the product even before you know who the customer is. Is everyone else assuming that you don't need to figure the VAT until the customer gives his shipping address? I think we're working on two very different problems. Once you have been given the shipping address, it's easy to figure out the tax rate (merely by country in this case... within US states with multiple tax jurisdictions, it's a nightmare requiring geolocation from the address and determining which county and city the buyer is within). Not having to display VAT to random shoppers would greatly simplify matters.