Jump to content

MrPhil

Members
  • Content count

    8,158
  • Joined

  • Last visited

  • Days Won

    112

Everything posted by MrPhil

  1. Any place that full identifiable names are made public (such as in reviews) probably needs to be fixed:
  2. I don't care what EU laws say. I'm asking what privacy regulations make sense and should be in any web application.
  3. OK, so just what is the problem the EU is trying to solve with these GDPR regulations, and what can be solved with common sense and what is a bureaucratic nightmare? The following seem reasonable, without having to go through five permission popups per page: Let them know (via button or link, not an annoying popup), when signing up or placing an order, what data you keep and for how long (justify keeping something like an IP address) All data is available on their account information page, and (where reasonable and appropriate, such as their current shipping address or email address) can be updated, with confirmation sent to the [old and] new email addresses No automatic signup (e.g., pre-selected checkboxes) for something like a newsletter or targeted ads -- the customer has to take explicit action to sign up No tracking cookies or other saving of invasive personal information without explicit consent Ability to unsubscribe from newsletters, targeted ads, etc. on the account information page, with reminder in the newsletter or ad Can request to be forgotten (erase account) by an action on the account information page "Last chance" notice that payment will be made and order processed if customer clicks a certain button What else do customers need? Make it clear that some data is necessary for proper operation of the site (e.g., session cookies) and some is necessary for fulfillment of the order and may be retained according to statutory or accounting requirements. The customer will not be asked for permission on these items, but they should be listed somewhere for those who are curious. The customer will not be explicitly asked for permission to keep data when they have implicitly given permission by the act of filling in data fields -- the only time they will be asked is for optional items not absolutely required for the fulfillment of the order, such as signing up for a newsletter. Anything missing? That may or may not meet the exact letter of the law, but does common sense say that it's sufficient to safeguard customer privacy? I'm leery of having to encrypt some customer data (except passwords), as anyone able to get to my database surely can get to my code and see the encryption key! I'm also leery of having to allow "outside" access (outside of the account information page, which already requires an ID and password), as that opens up a whole Pandora's box of access control issues, as well as "security questions" which are themselves invasive (and if compromised, could be used to gain access to other accounts of the customer).
  4. What good does encrypting your customer data do? The password, etc. has to be in your store code, so anyone who can get access to your database can probably easily get the means to decrypt the data, too. And vice-versa -- if they get to your code, they can find the DB name and access information. This doesn't seem to me to be very useful. Only a hash (one-way encryption), such as used for a signon password, would be fairly secure, and that's good only for passwords where you're comparing hashed fields (not decrypting data). Please don't say, "well, it satisfies the regulators".
  5. It should be interesting to see if Harald updates this forum to get explicit permission for each post and to put up an avatar, and that anyone claiming to be that member can request that everything be removed! Common sense data protection is one thing, but the ability to delete all your material (including posts and avatars) is absurd. I'm not sure I would let someone remove their posts, as that would totally scramble any forum or blog. It only makes sense that permission is implicitly given if someone chooses to place an order, make a post, add an avatar, etc. I don't care to ask for explicit permission -- that's too much Nanny State. Whatever happened to people exercising common sense? If irresponsible parents choose to let their children act unsupervised, that's not my problem -- don't punish me for a minor joining up, posting, or making a purchase while claiming to be an adult. Obviously, the vast majority of those who post on social media and news websites are about 12 years old!
  6. So, is there any written legal guidance on what constitutes proof of identity? If someone calls me up and asks what information I have on them, but can't remember their ID and password, and no longer has the email they signed up with, and I don't keep their credit card number, and they can't remember their last order... what am I supposed to do? Is every EU customer supposed to give me security questions that I keep on file*, and can challenge them with? It seems that this is getting very stupid. I wouldn't want to get in trouble for giving out personal information to the wrong people, either. There is no legitimate reason for someone to ask what information I have on file, and if they have an active account, they can check, verify, and update it themselves (or ask to be forgotten). Case closed. I'm not in the EU, and I intend to ignore these "requirements" for any EU customers. * which, if you think about it, constitutes even more personal information to protect and be queried about!
  7. That's what worries me. If someone sends me an email that's not associated with their account, or calls me up, and asks what personal data I'm keeping on Carine Bruyndoncx, how do I know it's really you? Should I only permit access via signon through their customer account? What if they claim they have forgotten their password and no longer have that email address? I don't want to give out personal data to random people who may well have malicious intent. If someone can sign on to their account, they can see their data, modify it if they wish, or ask for removal (in practice, taking it offline). That's all that seems reasonable to me. If they no longer can sign on to their account, they have no way to prove who they are, so T.S.
  8. MrPhil

    Quick Updater PRO - anything similar?

    Have you looked at Easy Populate? It's spreadsheet (CSV file) mass update of your store database, and might be what you're looking for.
  9. MrPhil

    Header Tags SEO

    I wouldn't be terribly surprised if giving the currency twice (explicit '$' in price, and 'USD' in currency), is upsetting somebody. Can you format the price as simply '179.00'? If the code is pulling the price from some other field, and it already has '$' in it, something as simple as changing $price to ...substr($price, 1)... might do the job.
  10. MrPhil

    Auto Update Currencies

    Don't forget that running PHP code in cron (system command line) is different from running it in the web server (via HTTP). You are not in the same environment, and may have different path settings, environmental settings, and even a different version of PHP. In general, if using cron, you want to make sure everything (paths, settings, etc.) are explicitly spelled out.
  11. MrPhil

    Store Search Bar (BS)

    Why not simply move the Search box over to the right, so that the typeahead also aligns with it? If I understand your posts, you're looking to keep the Search box where it is and move the typeahead to the left, to right-align with the Search box?
  12. MrPhil

    Auto Update Currencies

    Something at sessions.php on line 98 sent text or tags to the browser (the very first text; it could be as little as a blank or a carriage return). That triggers the server to send all the HTTP "headers" it has at the moment. Once those headers are sent, no more can normally be sent, and you get those errors when the osC code attempts to set more headers to send. You need to look at line 98 and vicinity, and see what got sent. It could be a blank or empty line after the very last ?> (simply go in with an editor and clean out any junk at the end). It could be an error message from the code. it could even be output from a hack. Look in the browser "Show Page Source" to see what comes before the on-screen error message (there ought to be some text there). Once you clear it up, both the error messages you got should disappear. It's not necessary to try removing the ?> and everything following, unless you absolutely can't find the cause. And be careful when editing PHP files not to leave garbage behind (you may have to change editors if yours leaves ^Z or something behind).
  13. MrPhil

    Database Optimizer

    What's this "Blu-ray" thing you old geezers keep prattling on about? Don't you watch a movie like everyone else does, by swallowing a pill? Oh wait, there's now a topical cream containing nanoflash chips, but it's facing stiff competition from the clip-on movie earring.
  14. MrPhil

    Database Optimizer

    Having a <form> as the direct child of a <table> is certainly not kosher HTML. Most browsers will silently insert <tr> and <td> to make the DOM legal and presentable, but a validator will certainly squawk about it. Best in the long run to clean it up by making a <form> the child of <td>, or maybe <table> the child of a <form>, or best of all, get rid of all the tables and use <div>s and CSS to control layout.
  15. MrPhil

    Database Optimizer

    Oh, the horror. The horror. My eyes have melted. Tables within tables within tables for layout control is so 1999! If the W3C validator is complaining about missing or misnested tags (elements), you'll have to copy and paste the HTML page code from your browser's View Page Source. Feel free to ****-out anything sensitive, but don't delete lines (or, conversely, just show pertinent blocks, with the lines numbered so they can be cross referenced with the validator messages). The PHP file you showed has no correlation with the validator line numbers, but will be useful for tracking down the source of problems, once we see exactly what the validator is complaining about. A look through the PHP code didn't seem to show anything particularly bad, and it's possible the validator simply got crossed up with all the nested tables.
  16. MrPhil

    Database Optimizer

    Well, I think only your first example is correct HTML. Most HTML validators will squawk about unexpected tags (e.g., expecting a <tr> and seeing a <form>). Many HTML tags have a list of legal parent and child tags. Most browsers will attempt to fix up problem nesting and produce something reasonable looking (by inserting new tags), but it's bad practice to rely on that behavior. Your HTML should be properly structured (proper nesting and proper parents and children) if you want the best chances of it always working correctly. Within a table, all content such as a form should be within <td>...</td>, and not in arbitrary places.
  17. MrPhil

    Database Optimizer

    I'm not aware of a rule that states what the form must surround. This sounds like a W3C error and is not a real issue, that I can see. My understanding of <form> rules is that a <form>...</form> is a single element that must be properly nested inside the rest of the page (nothing starting outside and ending inside, or vice-versa), and in turn, everything in the form is properly nested within <form>. Demitry should be able to examine the page HTML in his browser and see if these rules are violated. "Between two </tr> tags" -- huh? I don't think there's any way to directly nest table rows without a </table> and more between them. Maybe there's an error in the surrounding page code, and not the form itself.
  18. MrPhil

    Header Tags SEO

    Don't confuse people. Due to chronic abuse by SEO "experts", most search engines simply ignore the meta keywords tag, or at best, use it as an advisory to see what to pick out as keywords from other places on the page. You certainly do want to decide on some key words (terms that people will search for) to use in various places on the page, but don't confuse these with a list of keywords in a meta tag.
  19. MrPhil

    Advanced Specials

    Look at /admin/specials.php. Is line 368 the last line? There is probably a blank or empty line after the last ?>, causing text to be sent to the browser "too early", before all the header information has been updated. Did you manually edit this file at some point, and maybe left a blank line? Edit the file manually, being careful not to leave an extra line (note: it may not be visible to you in the browser!), and save it. Try using it again and see if the problem has gone away.
  20. MrPhil

    Charge tax on all orders 8%

    I think that would start a trade war. The screaming over US companies being blocked, and charges of "unfair protectionism" for Aussie companies will be intense. Should be interesting...
  21. MrPhil

    Database Optimizer

    @imusorka, if you are running from cron, it's entirely possible that your PHP and/or MySQL installations are at a different version than your website's. You should run phpinfo() from cron, and compare it to phpinfo() from a browser. If substantially different, you may need to ask your host what "php" command you need in cron to use the same PHP and MySQL as your website does.
  22. MrPhil

    Charge tax on all orders 8%

    The only way a US business selling to Oz could be persuaded to collect GST/VAT for you would be to have an Australian subsidiary or operations which can be held hostage in some manner. Otherwise, it ain't never gonna happen.The big attraction of ecommerce is that people decide they can get away without paying sales tax, even though they're legally supposed to (or the equivalent, "use tax"). The only solution will be for every state to eliminate sales tax (and raise other taxes, no doubt).
  23. MrPhil

    Charge tax on all orders 8%

    First of all, check that you really are required to collect sales tax on all sales, regardless of where the buyer lives (destination address). If you are in the US, you are not required to collect state sales tax in another state (or country), unless you have a nexus there (a legally significant business presence). You can collect and remit sales tax in non-nexus states, but it has to be the proper rate. I've never heard of collecting sales taxes and VAT for other countries. Most states use "destination" address (where the shipment is delivered to) to determine the rate, while some states (I think California, among others), uses the "source" address (where the shipment is sent from). Outside the US, it's anybody's guess as to what the tax rules are. If you are in, say, California, and your local sales tax rate is 8%, you would collect 8% on all your sales to California customers, but no one else. If you had a nexus in, say, Arizona, you would have to follow the rules for collecting sales tax on purchases sent to AZ.
  24. The page is being displayed in UTF-8 (which is normal practice), but the data (probably coming out of the database) is Latin-1 or CP-1252. Non-ASCII characters like a pound currency sign in a single-byte encoding are invalid UTF-8.
  25. Your pound currency symbol was entered as a single byte encoding (Latin-1 or CP-1252) into the database, but is being displayed as UTF-8 on the page, and thus is an invalid UTF-8 symbol. Is this a new setup? Was the database imported from an .sql file dump of another working database?
×