Latest News: (loading..)

MrPhil

Members
  • Content count

    6,993
  • Joined

  • Last visited

  • Days Won

    69

MrPhil last won the day on June 21

MrPhil had the most liked content!

About MrPhil

Profile Information

  • Real Name
    Phil
  • Gender
    Male

Recent Profile Visitors

100,633 profile views
  1. Are you absolutely sure this is osC 1.203 you're looking at? That version (if it even ever existed) is so ancient that it would be foolish to try to repair it. A store that old isn't going to run on any current PHP and would be a hacker's delight (i.e., extremely insecure). Over the years I have seen many people give a 1.xxx template version, which has nothing to do with osC's version number. Perhaps that's the number you're looking at. Templates are from external companies, are not controlled by osC development, and their numbering is all over the place. Look in the application_top.php file to see what version number it gives there. If it's 2.2 MS2 or higher, you stand a chance. Even so, you should think about moving to the current osC (2.3.4BS Edge) for the latest in compatibility, stability, and security.
  2. An FTP client could conceivably change the character encoding in a file it's transferring, but that's not normally done (just how lines are separated). There could be all sorts of reasons that Dan is seeing different treatment of a UTF-8 file on the two systems. First of all, he needs to get rid of the BOM bytes if they're actually in the files (edit in Latin-1 mode). Make sure that the same page is being displayed (i.e., both specify UTF-8 encoding). I've even seen servers that override the encoding tag and force Latin-1, so the server configuration should be checked.
  3. My guess would be you're seeing three odd characters at the beginning of the text (file), but only when looking at the file when in a single-byte encoding page display (e.g., Latin-1 or Windows-1252). They would be the UTF-8 Byte Order Mark, put there by brain-dead editors (such as from Microsoft) when editing in UTF-8 mode. It should not be in files intended for Web use (see if you can configure your editor to save without BOM). You don't see it when displaying in UTF-8 mode (it's simply eaten and discarded), but in non-UTF-8 mode, the browser doesn't know what it is, and displays it as three oddball characters (bytes). Hi Dan! It's nice to actually be missed...
  4. 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.
  5. Yo, bud, that's how community-supported software works! If you ask a question and someone takes the time and effort to try to help, the least you can do is let us know what solution you found, to aid others who come after you.
  6. It sounds almost like the file got truncated during a move, but I don't see any unmatched { } [ ] or () in your listed code. Have you tried re-transferring this file from the old system to the new? Maybe the first move corrupted it in some way. The other possibility is that you're not running on quite the same level of PHP as before, and PHP is barfing on something too downlevel. Incidentally, I agree with Dan that you're asking for continued trouble and misery if you try to keep such ancient code (osC 2.2 MS2) patched and running. PHP 5.3 is also long out of support, and is thus very vulnerable to hackers. It's bad practice to keep using such out-of-date software (PHP 5.3) just so you can run an out-of-date application. You should migrate ASAP to osC 2.3.4BS Edge, the current supported version of osC. You can migrate all your product and customer data over, so you won't lose anything. Note that this is not the "official" osC 2.3.4 download -- it has to be downloaded from GitHub.
  7. In osCommerce (osC), each product has detail information stored in the database. This is the text explaining all the cool features of the product and how you'll be happy forever after if you buy it. The limitation is that it is HTML-only code -- no PHP code permitted. With some code changes to the osC product, it could be made to run PHP code in your product detail information, but not out of the box. There are add-ons to drop in WYSIWYG editors (e.g., CKeditor) to make editing the HTML markup easier. Perhaps you could tell us what kind of "custom product detail form" you're thinking of? If it's for things like color and size, there are already several "attribute" add-ons available to drop into osC. What kind of information are you looking to get from the customer? -- perhaps it already exists. By the way, if you're just starting with osC, don't use the official 2.3.4 product offered for download. It is obsolete and won't even run on modern servers. Use the 2.3.4BS Edge version (it's downloaded from GitHub). It's up to date, has more features, is responsive (BS = BootStrap), supports PHP 5.6 (and soon, 7.0), and is supported here.
  8. 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?
  9. What version of osC are we talking about here? You say a "template" is involved -- that could mean anything from replacing a few files to completely replacing the stock osC installation. What level of PHP and server were you running on before (successfully), and has anything changed on the new host? Old versions of osC can have lots of problems when transplanted to recent PHP levels. Is the entire site SSL, or just (by default) specific pages with sensitive information? Do other SSL pages work, or are they broken too? If all SSL pages are broken, check that your certificate matches the domain name you are using -- your host might have dropped or added "www." when they obtained the new certificate. You probably weren't running on a "shared" certificate before -- those generally don't work with PHP code. Are you sure you didn't have a private certificate? Clear out your caches (any osC-related cache on the server, and your browser's). Work with your host to find any caches on the server end. If just one SSL-protected page is broken, look at the HTML source code in the browser -- maybe it's specifying http: instead of https: for a style file (CSS). It's odd that just one page would break like this, and the others would work, but maybe the "template" is hard coded to http:? However, this should have made it break on the old system too. Grill your host as to exactly what they changed in files that they brought over -- maybe they accidentally changed something they shouldn't have.
  10. Yes and no. There are advantages to using a common framework, but having to put up with severe limitations is not an advantage. I only mentioned tables because some people seem to think it a mortal sin to use <table> for any purpose, including display of tabular data! Tables are bad for doing general layout, but still excellent for display of information that naturally falls into a grid. The only downside is that (currently) there does not seem to be an easy way to adjust the number of columns per row on the fly, for responsive layout. If improvements to Bootstrap/Flex/whatever library can either do that, or set up an equal-height row without adding layers and layers of cruft (divs within divs within divs...), that would be a winner. Does CSS already support something like <div style="height: max-child-height;"> ? I've seen lots of discussions about making a parent the height of its children, but they always seem to come with plenty of caveats and restrictions and warnings. Is it simple to do, yet? By strange coincidence, input and participants welcome... http://www.catskilltech.com/forum/practical-computing/building-an-application-framework/
  11. When changing text color like this, keep a few rules in mind: Be consistent -- use the same color scheme to mean the same thing everywhere, so your employees don't have to learn a half-dozen different conventions. Define a class, rather than hard coding a style into a tag. Try to adhere to standard UI design -- light gray means "disabled", red means "error", etc. "Disabled" might be appropriate for a "don't use this" address, but be careful, especially if you have any other uses of "disabled". Watch out for color vision-deficiency people trying to use this. Something like 10% of men and 1% of women have some degree of "color blindness", and you don't want them to misread text as meaning something different than what you intended, or being unable to see it at all! It may be a good idea to not use color changes alone, but also have some sort of notice like "Don't use this address".
  12. Just a random thought on this... back in ye olden times, before CSS usage was widespread, people used tables to lay out their pages. Now, I'm not arguing that we should return to the days of table hell, with tables within tables within tables -- CSS is much better for layout purposes. However, tables are a legitimate way to lay out data in a grid, and cells in a row are automatically equal height. The downside is that I don't know how to change the number of cells in a row when the display width changes, so responsive design is difficult, if not impossible, with a table. Something would have to be done in Javascript to restructure the table, based on display width. Has anyone seen such a thing? I suppose you could send several different tables to the browser, and have one selected based on display width, but that seems rather inefficient. With adaptive design, that's easy (to generate a different table on the server, in the first place).
  13. Indeed, it's a good question: what are they trying to accomplish? I could see making mailing requests to a few selected target emails, in order to swamp (attack) them, or making all sorts of requests to attack you by burying your server under a landslide of outgoing emails, but that seems a lot harder than a normal DoS/DDoS attack. Anyway, to avoid legal and/or SPAM blacklisting trouble for you, your newsletter should always include "You are receiving this because you (or someone pretending to be you) signed you up for it", and give an easy way to get off the mailing list. Some sort of CAPTCHA is a good idea, to at least weed out most of the bots. The graphical ones (letters + noise) don't work all that well any more, and mostly just annoy legitimate users. Jack or Gary had a nice math-based CAPTCHA that I modified to use on my Contact page. As I said at the time, it may become less effective as it comes into more common use, and spammers start writing bots that understand how to deal with it, but so far, so good.
  14. As instructions in the file remind you (or maybe they're just in other, similar files, and missing from this one), the entire content of a "define" is enclosed in single quotes '. Any ' appearing within this content needs to be escaped: \' so it doesn't end the string early.
  15. The actual installation of an SSL certificate is normally something that your host does (usually for a small fee). They have to update their system anyway, to point https requests to your cert. So, you should start by contacting your host. I hope the cert you purchased is compatible with their system so you didn't waste your money.