MrPhil

Members
  • Content count

    6,990
  • Joined

  • Last visited

  • Days Won

    68

MrPhil last won the day on April 19

MrPhil had the most liked content!

Community Reputation

383 Excellent

About MrPhil

Profile Information

  • Real Name
    Phil
  • Gender
    Male
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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?
  6. 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.
  7. 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/
  8. 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".
  9. 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).
  10. 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.
  11. 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.
  12. 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.
  13. Well, yes it should be possible to do something like that, but not easily. The most general case would be to allow embedding of PHP within the HTML of your text (out of the database). This would require that whatever is handling the category description text to look for "<?php", extract that part of the text, do some sort of "eval()" on it, and insert the resulting text back into the HTML text for output to the browser. Note that a browser is expecting pure HTML... it has no idea what to do with PHP code. Also note that you have to be very careful to do this only with trusted sources -- imagine what a hacker could do if they could insert PHP into a product review or something! A more limited approach would be to modify the category description (or whatever) code to drop your code permanently into the middle of the PHP, and then the normal HTML text from the database is placed before, after, or around the output of your custom code. Either approach would still be vulnerable to being wiped out by updates to the osC code, especially if you're messing around in "core" code.
  14. Who gets that message likely depends on what browser they're using. Some current browsers have become very aggressive in warning users away from non-SSL pages. It doesn't sound like this was from a login or payment page, which normally is SSL-protected. Anyway, you're going to see more and more of this. If you have SSL, you should be thinking about making the whole site under SSL. For the most part, this is a minor configuration change, although you will need to add a redirect from http: to https: in your .htaccess, and you will need to go through your add-ons to see if any of them need updating (are using hard coded http: URLs). Start here: http://forums.oscommerce.com/topic/410451-time-to-get-secure-if-you-havent-already/ . If you don't have SSL at all, time to get cracking and purchase it.
  15. They're the same distribution, under two slightly different names. Unfortunately, Gary wasn't entirely consistent in naming things, and this has resulted in some confusion. osC 2.3.4 --- "plain", "official" latest release. DO NOT INSTALL -- it hasn't been updated in 3 years and won't run with most PHP levels (above 5.4 or so) osC 2.3.4BS Gold --- early snapshot of what is now Edge. Don't install it unless you absolutely are unable to run Edge osC 2.3.4BS Edge --- current version ("bleeding edge") responsive (Bootstrap) version of osC, with many enhancements and PHP 5.6 support (PHP 7.0 promised soon-ish). Despite being under development, almost everyone has found it to be quite stable. Gary and friends seem to do a good job of testing before releasing code. As for your 2.3.1 site suddenly going kerfluey, your host did make some sort of upgrade to the server, which broke your ancient version of osC. Software can't be installed and forgotten about -- the underlying platform (server) is constantly upgraded, and eventually your application will break. Your host has to keep updated, to provide security and needed features, so you can't blame them. You are responsible for keeping your site software up to date. Install 2.3.4BS Edge and enjoy a nice operating and stable shop for a few years, anyway. Eventually it will have to be upgraded, by which time hopefully the official 2.4 will be out.