Jump to content
Latest News: (loading..)

MrPhil

Members
  • Content count

    7,831
  • Joined

  • Last visited

  • Days Won

    102

Everything posted by MrPhil

  1. If PayPal discovers you're charging customers extra to use them, at least in the old days they would threaten to dump you (ban you from their service). Nowadays, with more competition, they might not go to such drastic lengths, but still they discourage the practice. Almost any payment method involves some per-transaction amount, so why not take your average customer's transaction fee percentage and just bury it in your base price? As has been pointed out, such fees are a normal business expense and you should be expected to account for them in some above-board manner (i.e., not simply eat them).
  2. MrPhil

    Checkout confirmation blank white page

    Kellie, I hope you can find a more-or-less working copy in your (or your host's) backup, and at least get running again. You need to keep a log of exactly everything you change, so that when you break it, you can quickly roll back your changes and at least be working again. You also need to keep orderly backups, know which one is which, and be able to restore them when needed. Blunt speaking time. When changing a website, you have to go about it in a rational, orderly manner; and have some idea what you're doing. From the sound of it, you know nothing about programming, are unable or unwilling to learn, and get into a blind panic, changing everything frantically and losing track of where you are. You have to stop that. I think you should give up on trying to modify the site yourself, and hire someone fairly locally to do it for you. If you really want to learn how to do it, and think you can, you should not modify your live site. You should be setting up a sandbox to play in, as a private test system on your site, and don't copy over changes to your live system until you have tested it thoroughly on the test system. That's the only way you can avoid such disasters. Even experienced programmers do it this way for major changes, although they may put minor changes on the live site, knowing they can quickly back them out.
  3. MrPhil

    Checkout confirmation blank white page

    Check your configurations... in some places you show the shop installed directly in root (public_html/), and other places you show in "catalog" (public_html/catalog/). You need to find out what your actual file directory structure is (with or without catalog/) and consistently use that. Then, I've seen "admin" and "admin-name" in file paths. At some point, you probably (should have) changed your "admin" to something else. Both "admin" and "admin-name" in configuration files should match whatever your actual admin directory name is. And finally, "username" is another placeholder that needs to be changed to your actual account name. Do not show your account username or the admin name in any public forum, such as this one. Be sure to change them before posting. Using "****" or "[username]" and "[admin]" makes it clear that you've changed it.
  4. MrPhil

    Checkout confirmation blank white page

    Just to be clear, if you added the line for defining DIR_FS_ADMIN, you have to change "admin-name" in the string to the actual name of your admin directory. "admin-name" is just a placeholder, as is "username".
  5. MrPhil

    Checkout confirmation blank white page

    Does it literally say "admin-name", rather than the actual name of the admin directory? You should have given (or changed) your admin directory from the default "admin" to something else during installation (and never give out that name, including in this forum!). It's also a little late now, but you should not give out your hosting account name, either, as someone sharing your server might be able to get into your files (or at least, take a look around). The error messages say that it's looking for /catalog/<adminname>/includes/languages/english/invoice.php in /includes/modules/email_invoice/email_invoice.php. email_invoice.php would appear to be in a root installation of the catalog (public store side), while it's looking for the file in /catalog/<adminname>/ area... did you put your store into the root, and the admin under catalog? That's a strange setup, but I suppose it's possible. BTW, if you wanted customers to not have to type in /catalog, you would have been better off leaving it in /catalog and using a URL rewrite to jump visitors to / (root) to /catalog. I don't know if something on the public side looking for files on the admin side is normal in your version of osC, or if something is seriously screwed up. What changed since November 3? Could you have been hacked?
  6. I'm sure it's possible, but I can't tell you how much work it will be to convert your old shop's data to osC. I wouldn't do it by trial and error ("testruns exporting existing tables") -- you really need to fully understand what the data is all about in the old and new shops, to determine whether and how you can move it over. Very likely the mapping from old to new will be fairly straightforward once you understand the data in both shops (unless FWS has a very strange setup). You still may end up discarding some data that osC doesn't use, or synthesizing some data that doesn't exist in the old shop (e.g., which mailing address format a customer uses). I'm not clear what you mean by the "A" and "B" parts of the shop. There's information on the shop itself, and products which will go into the database (is that 'A'?), and there is customer data on past orders, addresses, etc. which you say you want to preserve (is that 'B'?). Speaking of customer accounts, were passwords "hashed" in the old database, or did they store plaintext passwords? If they were hashed, you likely will not be able to recover the plaintext password, unless FWS and osC use the same hashing system and you can simply copy over the old hashed password (unlikely, but possible). You might end up having to generate a new password for each customer, and email it to them (requiring them to change it within a certain time period), like a lost password recovery function. A clarification on the osC version to use: Edge is still under development (but reasonably stable), while Frozen is a frozen milestone release that's not quite as up-to-date. I think Gary is working primarily on Bootstrap v4 and PHP 7.2 compatibility on Edge.
  7. MrPhil

    Checkout confirmation blank white page

    The White Screen of Death often means that there was a fatal PHP error encountered -- your code is messed up. Undo all your changes, see if you're running again, and as suggested, reintroduce changes one at a time. Be very, very careful that you don't make mistakes editing (you probably did, somewhere). As for one file being unaccountably updated recently, take a close look at that file to make sure you haven't been hacked. Compare it to a known-good backup copy.
  8. By the way, before you get too far with this, are you using the correct osC version? It is 2.3.4.1BS Edge (or Frozen), not the obsolete official 2.3.4.1 download from this site. The official release will have lots of problems running with PHP 7.2. Even Frozen (and to a lesser extent, Edge), while fine with PHP 7.1, have some patches needed for PHP 7.2.
  9. Sometimes these defined language strings are in a language file, and sometimes they are put in the database. In either case, if you are missing one or more strings, it's likely that something didn't go right with your install (base product or an add-on). Double check your work that you didn't skip a step, or overlook a warning message that a file couldn't be read or written, or data couldn't be put in the database. Look for the missing strings in your install package (language files and .sql files) and if you find them, you may be able to either manually copy the file(s) into place, manually update the proper file(s), or import them into the database. This will take some knowledge of how osC installs things, so don't go about it blindly (i.e., know what you're doing, and be able to recover from backups if you screw up).
  10. MrPhil

    wrong urls do not redirect to 404 Not Found

    The first solution is wrong. It forces the URL to http (non-SSL), which is not what you want these days (https/SSL is much preferred), and potentially adds or removes www from the domain name, which may not be desirable. To simply remove the "index.php/" part from the URL (if that works for you): RewriteEngine On RewriteRule ^index\.php/(.*)$ /$1 [R=301,L] which would not disturb the protocol (http or https) or the domain name that you may have adjusted already. The same comments apply to the second solution. In both cases, the browser (or search engine) gets a bounceback that says, "use this new URL instead of that old one you sent me." You want to try to avoid multiple 301 or 302 status messages (combine them into one if possible) so you aren't penalized by search engines.
  11. MrPhil

    </head> location

    This "Surfalot" product appears to be an HTML editor, rather than a proper PHP editor (or plain text editor). Never use an HTML editor (such as Dreamweaver) to edit PHP code. If it has a PHP (or plain text) edit mode, perhaps that would be safe to use. Whatever you're doing, it's thoroughly corrupting your code, as shown in your screen image. Something like Surfalot might be suitable for WYSIWYG-style editing of product descriptions, but don't touch PHP code with it!
  12. MrPhil

    open_basedir restriction

    Sounds good, glad to have helped. Any place the code reads a directory, it should check for . and .. entries, and skip them.
  13. It would be easiest to make a test install of Frozen and use phpMyAdmin to dump out the sample database, including the table definitions. The oscommerce.sql file in the install package is probably just as good. Compare them to your old DB and decide how to best modify the old DB schema to match (or be a superset of) the new DB, either in phpMyAdmin or editing the .sql dump of the file. For very old versions of osC, or ones that have been modified, that's about the best you can do.
  14. The Smothers Brothers used to irritate the CBS network by playing a clip of the President saying something and then *cough*Bolshoi!*cough*. Now that the status of the Edge family has been clarified, I will update my signature to point to both Frozen and Edge.
  15. MrPhil

    wrong urls do not redirect to 404 Not Found

    The code for USU5 has been removed, you say, so now /index.php simply receives a Query String (name and empty value?) and ignores it because there is no code telling it how to handle it? Does this happen for both invalid products and those that are still live? I would think it would. My server isn't configured to work this way, so I can't tell exactly how yours is handling it, but something like foreach ($_REQUEST as $key => $value) { if $key == known request, continue; if $key == known request, continue; // $key is a product name redirect to 404 or 301 } might work. USU5 was presumably checking product names against the database, and if a product was missing, give some sort of 404 response. If you still have the code, you might be able to look at it and put in a stub to handle it (301 to the current URL for that product, if it's live, and otherwise 404). Hopefully you can do that, otherwise you'll be re-inventing a big chunk of the USU5 wheel!
  16. Keep in mind that adding flags to suppress errors is only a temporary workaround. It is not a permanent fix by any means. Use the time gained to fix the problem. I'm worried about the "undefined constant DIR_WS_HTTP_CATALOG" message. That string should be defined in the configure.php files -- did they get removed? Did any other defines get removed? Once you get past this one, will others pop up? I don't know why PHP 7.2 would stop processing defines. Most of the messages after that about "headers already sent" can be ignored, as they will clear up by themselves once the initial errors are resolved. Don't forget to look at the thread about known errors in Frozen and their fixes. Also, drop back to PHP 7.1 if you can easily do so.
  17. MrPhil

    wrong urls do not redirect to 404 Not Found

    OK, so your server is set up to treat anything after index.php as a Query String? That's a bit unusual, as I understand it, but let's see what we can do with it. You have working OK, while is going to the home page (just /index.php)? And you desire that it 404? If the server (externally to osC) is converting /*_product to a URL Query String, apparently osC + add-on is handling it correctly, but if there's no product match it's simply dumping it back to /index.php. That would require a change to osC + add-on, but did it ever handle no_longer_a_product as desired (404)? I'm trying to get a handle on what this thing is doing -- the SEO I'm familiar with uses .htaccess to convert to /index.php?id=value format. It should be easy enough to change the code to do a header() call to 404 rather than to /index.php (or simply take an internal path to the front page). The question is, how did it used to work, and what changed?
  18. Most browsers have some sort of tool to examine elements (e.g., in Firefox, right-click and select "inspect element"). Often they have a feature to let you point exactly at the screen element to display the HTML and CSS for. This should let you quickly find the class, id (better yet, as it should be unique to a page), or the tag hierarchy needed to specify as the selector in your user.css file. border: 0px and border: none I don't think are quite the same thing.
  19. So you installed into /shoponline directory, and if you just given that path, it redirects to /shoponline/web? I can't think of anything in osCommerce that would do that. Most likely you or your host left something in your .htaccess file. Do you have something like Wordpress also installed? It could be doing something like that (many applications do). This is why you should never install a major application into the site root, as it will create much extra work when you install another application and the two get tangled up in each other. If you do have another application's .htaccess redirecting root traffic, it should be possible to separate them if you don't want to break an existing other application's bookmarks, etc. If you are also just starting out with Wordpress or something else, move it to its own directory (e.g., /blog) and write a "landing page" to direct visitors to the desired application. By the way, since you're just starting out, did you install the right version? The official release 2.3.4.1 downloadable from this site is years out of date. You should be installing the community-supported 2.3.4.1BS Edge (a.k.a. CE, Frozen) version available on GitHub (see my link below). It is Responsive (mobile friendly), PHP 7.1 ready, and has a lot of bug fixes and new features.
  20. It's an ordinary MySQL database, so all sorts of Third Party DB backup/restore programs should work. Have you asked your host for any recommendations? If something doesn't work because it times out (runs too long), they may be able to tell you how to get around that limit, or will even occasionally do it for you as a favor. Even phpMyAdmin, or whatever you have similar to that, has a backup function (Export), but that may still be subject to process time limits. I don't know how good osCommerce's built-in backup is. Typically, backup functions added by application developers aren't quite as good as dedicated backup/restore programs, but some I've seen are atrocious (e.g., SMF).
  21. My point was that ALTER is for changing the structure of a table, while UPDATE is for changing the data in the table. If NULL is permitted as a value, and the code understands it as "value not set" and not as a 0 or something, then setting the timestamp to NULL could work. My guess as to why it is 2017 is that is the last time a special was set for most products. Perhaps it would even be easier not to do it as a "special", but simply UPDATE each product price to 0.75 * the old price, but that might have to be done product-by-product. Easy Populate?
  22. Of course it's possible, but it could end up costing you a pretty Euro. Someone will have to understand both your current database and the osC database, and figure out what each field in your current DB maps to what table and field in osC. Some data may have to be modified or even synthesized to fill out osC properly and completely. If you want to keep all your current customers and product data, and transfer it over, you will have no choice but to do this. It might be easier just to re-enter everything manually, but you won't know until you take a detailed look at your data. By the way, do NOT use the official osC 2.3.4.1 download available on this site. Use only the community-supported osC 2.3.4.1BS Edge (a.k.a. CE, Frozen) version on GitHub (see my signature below for the link).
  23. I wouldn't use ALTER, as that's for changing the structure of the table. Something like UPDATE specials SET expires_date = 2000000000 (where a timestamp of 2 billion is well in the future) might work. Of course, back up your database first.
  24. MrPhil

    open_basedir restriction

    OK, "alar" was a typo or something, and the name we're using is "mspggy" (I see it as "Miss Piggy", from the Muppets). Carrying on... File(/usr/www/users/mspggy/..) is not within the allowed path(s): should be quite self-explanatory -- you are trying to read or write files in /usr/www/users/, which is not in the list of allowed path roots (basedirs). If your account is, in fact, /usr/www/users/mspggy/, a DIR_FS_CATALOG with that string should work. Possibly you are running into problems because the second entry for any directory will be "..", which means you will be querying /usr/www/users/mspggy/.., which will be not allowed. Try this: test if $file is "." or ".." and if it is, bypass it: $file_extension = substr($PHP_SELF, strrpos($PHP_SELF, '.')); $files_array = array(); if ($dir = @dir(DIR_FS_CATALOG)) { while ($file = $dir->read()) { if ($file == '.' || $file == '..') continue; // new line to bypass . and .. if (!is_dir(DIR_FS_CATALOG . $file)) { if (substr($file, strrpos($file, '.')) == $file_extension) { $files_array[] = $file; } } } sort($files_array); $dir->close(); } Failing to check for (and skip) . and .. was just sloppy coding on someone's part.
  25. Could all respondents clarify whether it's a Merchant Account type setup (A.net?), a Third Party payment system (e.g., basic PayPal), or something else? Some shop owners may not be able to (or wish to pay for) something requiring PCI compliance. Let's assume everyone has SSL by now. How about an idea of monthly and per-transaction fees? Small shops may not want to pay stiff monthly fees in return for lower transaction fees, while those with higher volume might find it worthwhile. Finally, what about refund policies and other such things (e.g., PayPal is notorious for "the customer is always right")? A simple "I use XYZ and it's great!" is useless for someone trying to decide which payment system(s) to use.
×