MrPhil

What the GPL says and what a "good" lawyer can convince a jury is the truth, can be two completely different things. That's all I'm saying. Using code which can unnecessarily expose customer financial data to hackers is a good way to get slapped with a big lawsuit -- the store owner, the osC organization, the bank, et al. Therefore, it's not a good idea to use it, or to provide it for use.

What a jury thinks and what the GPL says are two different things. At least in the US, if you provide a "defective product" (e.g., software that is obviously insecure), you might be held liable for damages (losses when the system is hacked). Just sayin'.

I think the "Encrypted Credit Card with cvv2" add-on was intended for offline (manual) processing of credit cards, such as through a brick-and-mortar store point of sale terminal. If you intend to use it in this way, first check with your bank that they're OK with your doing this. Most will forbid it, and those that allow it will charge higher fees (because of the higher fraud rate of online purchases). As you are handling credit card information on your site, PCI-DSS security regulations will apply. Figure out just what you want to do regarding accepting credit cards, and what the total cost is, before proceeding any further. There are payment gateways that allow you to handle credit cards on your site without storing CC data (a direct connection to the merchant account). There are third party payment sites (such as PayPal) that handle everything for you. Both charge fees, of course. Security requirements are much higher (PCI-DSS) and more expensive if you are going to actually have CC data pass through your own site (SSL, mandatory security audits, handling fees). Unless you expect to have quite high volumes, a third party payment system is probably cheaper. The only real downside is that customers see that they are being taken offsite for payment. If your sales volume goes up to the point that keeping it all on-site is cheaper (payment gateway/merchant account), you can always switch over in the future. If those who control osC had any sense, they would remove all add-ons which encourage getting around payment security practices, such as "Encrypted Credit Card with cvv2". If someone had their credit card information stolen on a site which used such an add-on, it's quite possible that Harald, et al. would be in a lot of legal trouble.

What osC version? Is this add-on supposed to be compatible with it? Also, be sure to check first that your bank/merchant account is happy that you're storing credit card information, including the CVV2! That is usually in violation of agreements, and not meeting PCI-DSS standards. Even though it's encrypted, it won't take a hacker long snooping around your code to discover the encryption method and key, and access all the goodies in your database. If they're OK with this, make sure you have in writing that you're not liable for damage done by security breaches.

Round up the usual suspects -- which pseudo cron (there are 2.2 and 2.3 versions), what osC version, what PHP version, etc.? The add-on is 5 years old, so it might not work with recent PHP levels (needs to be updated).

Another unconventional (store credit only) payment request: http://www.oscommerce.com/forums/topic/409992-purchase-with-store-credit-in-osc-store/

That is rarely necessary. Only a few very oddly set-up servers need .php files to be marked "executable". 644 (read-write by owner, read-only by everyone else) will usually do the job, although files that PHP needs to write to (update) may have to be "writable" by group (664) or even by world (666), depending on how your server is set up (where PHP is running). In general, you want to give directories and files the least (most restrictive) permissions that will do the job. Don't listen to fools who blithely tell you to "chmod 777 everything" -- they're dead wrong.

Terms such as MODULE_HEADER_TAGS_PRODUCT_SEO_SEPARATOR were defined in an English language file, but not for other languages. You need to go through your "english" files and see where terms such as MODULE_HEADER_TAGS_PRODUCT_SEO_SEPARATOR are defined, and then go to the corresponding <other language> file (create it if necessary) and define that term (with your language's translation) in the file. Repeat for all other missing terms. For some, no translation is needed (e.g., define ('MODULE_HEADER_TAGS_CATEGORY_SEO_SEPARATOR', ' | '); or similar). You would just copy the line from the English to your language file.

Well, I won't "bare" with you, as you're evidently not an attractive lady, but I will be happy to "bear" with you! :) This really doesn't have anything to do with Easy Populate, other than both involving a CSV file. How are you producing this file? Are you exporting a CSV from your store database and then manually editing it? Do you have a PHP (or other) script to read your store database and directly write out the CSV? That would involve some minor programming, but would allow you to mix and match data to produce a finished CSV in one step. If this is not a one-time job, that would certainly be worth doing (and might be worth it for a large one-off job). Specifically, in your product URL http://www.mysite.com/blank-widget-panel-p-8513.html, I don't think you actually need "blank-widget-panel" (which comes from the product name or title field) in the URL. Just the "-p-8513" is the critical part. By the way, is this other application going to be accessing your store via the normal osC links (such as your product URL), or is it supposed to go directly into the database? If the latter, it's not going to work. The product number (id) (8513) is somewhere in the product database, possibly as the product_id field. If you can tell us how you plan to produce the CSV file (which can be imported into a spreadsheet, if the other party actually wants it that way), we could offer some suggestions on how to do it. For a one-off job, I would suggest manually exporting selected database fields to a CSV file, and then either manually edit it or knock together a quick and dirty "rearranger" in your favorite language to reformat the data to the desired form. If this is a job to be done periodically, I would write PHP code to read the database and write out the CSV file in the desired final form. There may be an add-on or two somewhere to do something similar, which you could adapt to your purposes.

You want to add an entire category (or other group of products) in one action, rather than one at a time? You might search this forum (and the add-ons) for keywords like bundle(s/d) and master product. There may be other keywords that have been used.

Sorry, but I don't see any add-on matching that description or version number. Did you get it from this site, or from someplace else? If from this site, what is its 4-digit add-on number?

You're not giving us much information to go on here. What osC version? What PHP version? Which add-on are you talking about? How did you install it? How did you try to use it? What error messages and other results (or lack of results)?

Are you using the Easy Populate add-on? If so, it does not take .xls files as input. It needs .csv files. Maybe that's your problem. By the way, if you're just starting out, consider installing and using osC 2.3.4BS (responsive version) instead of the outdated 2.3.4. Also, your hosting service is a long way out of date. PHP 5.2 is long unsupported. They should be at least at PHP 5.4 by now.

Do NOT directly import XLS or CSV files into the database. Adding a product ("goodie") requires updating multiple tables. If you want to bulk import or update products (more than one at a time), install the "Easy Populate" add-on, which allows you to use a CSV (Comma Separated Values) file as your source. Or are you already using Easy Populate, and gave it the wrong name? What osCommerce version are you using? What PHP version?

What are you hoping to gain by this changeover? Remember... whether you have a bunch of if-then-elses (or a switch statement), or you look up an error message in a database, someone (you?) still has to enter all this information. Whether it's into PHP code or into a database record is irrelevant. If the error codes and associated messages are changing constantly, a database might make it easier to maintain, but if not, I don't see any advantage.

Something to consider is that osC is moving to using Bootstrap (2.3.4BS and presumably 2.3.5/2.4 later), which seems to bring in jQuery and AJAX anyway, so I think we can consider AJAX availability to be a given. I'm no expert in this end of things, but it sounds to me like we can count on using AJAX (or maybe jQuery) going forward, so you might as well concentrate on that version. Does anyone else have a reading as to whether osC should rely on AJAX/jQuery from this point on? Do people still turn off Javascript for "security" reasons? Will the store even work that way? Do enough still use ancient browsers (IE6, for instance) that we should accommodate them in some way (at least, fail gracefully or give limited function)? If code can be kept fast, clean, and tight by assuming some reasonable level of subsystem support (AJAX/jQuery), let's go for it.

Did you manually add the code in application_top.php to set $age_restricted_category_id? It appears that this variable is not being set. In turn, it requires in turn that AGE_PAGE_CATEGORY define be set (I'm not sure where). Check that you didn't leave out something in your installation.

Which meta tag(s) are not found? Self-closing tags (ending with />) for certain tags without a separate end tag, have long been legal in HTML, at least as far back as version 4. If <meta name="Description" content="Foto Meinema is uw online specialist in alles voor de fotostudio en outdoor" /> is being missed by your search tool, but <meta name="Description" content="Foto Meinema is uw online specialist in alles voor de fotostudio en outdoor"> is found OK, that sounds like a serious flaw in the search tool. To rule that out, run your page through an HTML validator (such as http://validator.w3.org/) and make sure there isn't some problem in an earlier HTML tag, that needs to be cleaned up first. It's also possible that the search tool is simply old and doesn't recognize and pick up recently added meta tags such as twitter:* or slurp, or is even fatally confused by some of the twitter format (@ sign, etc.). Maybe try removing the twitter tags and see if that cures the problem?

Can this add-on be adapted for use with 2.3.4BS? Before I dive into it, I'd like to hear anyone's experience with such. I'm assuming that the SDS functionality isn't built into 2.3.4BS already! Second, when I try to download the add-on, it appears to be a fix for PayPal on v2.3.3.4. Is the real SDS somewhere else?

Has anyone already looked to find where the amount (here: £20.20) showing up in the email comes from? Is it being fed back in from PayPal, or from the order total page? If it's from PayPal, that amount sounds like some sort of sandbox test amount, but the rest of the amounts, and that the customer is correctly charged, suggests that's not the case. @@Oza, what version of osC are you using, what version of PHP, what add-ons (including those removed or unsuccessfully installed)? There doesn't seem to be an amount of 20.20 in any currency hard coded into osC, so maybe it's part of an add-on? Did someone do some experimenting and use that amount as a test value, and forget to reset it to the actual amount?

It's always more useful to the community if you can tell us what fixed the problem. That way, people searching around for a solution to a similar problem won't be wasting their time by finding this thread and coming here only to find "fixed". Even if it's just "I found I had accidentally deleted the last 10 lines of file X, and had to restore them from backup", that's somewhat useful. The only lower life form is someone who posts a question, gets solutions from the community, and then erases their original question (deliberately, so it won't be of help to potential competitors).

Does stamps.com say anywhere what osC version this "plug-in" is intended for? For all I know, you're running 2.3.4 and their code is written for osC 2.2. Or vice-versa. If that's the case, it's possible that the plug-in didn't correctly install, or that it simply doesn't work with your level of osC.

With PayPal (and probably with other, similar payment systems) there has long been a problem with customers not following instructions for how to get back to the store to complete the purchase process, after they have been taken offsite to the payment site. Customers see "payment made" and assume they can just go off to some other site at that point. Maybe that's what's happening to you. Recent versions of osC have had some improvements made to try to detect such situations, but my understanding is that nothing is foolproof. So, if the process works for you, but doesn't for some customers (but not all), I would assume they're not following instructions on how to return to the store to complete the transaction. It might help to put in a big bold notice just before going offsite, reminding customers of the steps they need to take to finish the job. Or, if you're several levels back on your osC, try upgrading to 2.3.4 or 2.3.4BS and see if that reduces the problem. osC can't simply assume that the customer wandered off after completing payment, as they might have decided at the payment step to drop the whole order!

You can't use explode() in this case, as it's trying to split up a string on BOTH : and ,. You will have to use preg_split(): preg_split("/[:,]/" , $dp_cost)

In the add-ons section there are a number of existing photo galleries that you can just drop in to osC. Have you already taken a look at them, and found them to be unsatisfactory? Do they not work with your version of osC (without major modifications)? It seems like that would be a lot less work for you, even if you do have to re-enter the photos into the osC database rather than just importing the Wordpress database.