Jack_mcs

1 - It's difficult to say how to best approach this because it varies with the database. But, usually, I think just copying the customers, orders and address book tables is enough for most sites. The only differences in those tables are usually the collation, which can be fixed afterwards, and the index key. The key is important for speed. If the conversion script mentioned keeps that then it should work. 2 - The easiest way to be sure products are handled correctly, short of properly converting the database, is to install Easy Populate into both shops. Then download the products from the old shop and upload them to the new one. 3 - Correct. There are many programs on the web that will help with this. MySQL Workbench is free. I haven't used it in a long time but it used to work very well and I think it has probably improved since then. You may want to look at these, and others: MySQL Workbench https://www.mysql.com/products/workbench/ Compare two databases: https://adamspiers.org/computing/mysqldiff/

The domain you mentioned doesn't appear to be valid so I can't comment on what is needed for it. But, in general, you can use this thread to switch to the latest version. Hosts use a third-party service to provide packages to install. That third-party can only include packages recognized by the owner of the package. Since @Harald Ponce de Leon has not done that with the Community Edition, they can't include. The one they include is a very old and should not be used.

For the code I posted, use $keywords = preg_replace('/[^ \w-\'\"]/', '', $_GET['keywords']);

@ArtcoIncThe r87 dot com is a site on godaddy. You could report it as a spammer and/or block its IP's. Although the whois for it lists quite a few similar names so I suspect this guy wouldn't be easily stopped. Limiting the search string probably won't make a difference since they can type directly into the url. Many times the hackers will enter some invalid command so that an error is displayed that gives them more details about the database. You can test your site here to see if that is the case. Also be sure that anything entered in the search does not show up on the page after the search. This doesn't occur with the CE version but might with older versions. If your search doesn't require any special characters, then I suggest you change this code in the advanced_search_result.php file if (isset($_GET['keywords'])) { $keywords = tep_db_prepare_input($_GET['keywords']); } to this if (isset($_GET['keywords'])) { $keywords = preg_replace('/[^\w]/', '', $_GET['keywords']); $keywords = tep_db_prepare_input($keywords); } That will remove everything from the search string other than letters and numbers.

The error is caused by a mistake in the changes for older shops that can't use modules. I don't have a V2.3.4 shop to test but I think it can use modules so you should not be using that code. But for those that have the problem, change the following. But note, if your shop uses the module, making this change will cause problems. insert into configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, date_added) values ('Exclude IP\'s', 'MODULE_HEADER_TAGS_HONEYPOT_EXCLUDE_IPS', '', 'A comma-separated list of IP\'s that are not blocked by the create account checks.', '1', '108', now())"); to insert into configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, date_added) values ('Exclude IP\'s', 'MODULE_HEADER_TAGS_HONEYPOT_EXCLUDE_IPS', '', 'A comma-separated list of IP\'s that are not blocked by the create account checks.', '1', '108', now());

What is the error? What version of oscommerce are you using? What version of php are you using?

I haven't read through this thread so please excuse me if this has been stated. But the minimum requirement for the Responsive version of oscommerce is 5.4, as I recall

Before you go any farther, I suggest you install the Paypal App. It is the only module that supports paypal. The older versions probably won't work correctly.

It's not needed since the code will issue a 301 if they try to visit such a link. If the original problem isn't fixed and they keep getting a url with the lower case, they will probably complain about it.

@douglaswalker Try this. In inludes/application_top,.php, find require('includes/functions/html_output.php'); add beneath if (strpos($_SERVER['REQUEST_URI'], "cpath") !== FALSE ){ $_SERVER['REQUEST_URI'] = str_replace('cpath', 'cPath', $_SERVER['REQUEST_URI']); $location = "https://YOUR DOMAIN" . $_SERVER['REQUEST_URI']; header("HTTP/1.0 301 Moved Permanently"); header("Location: $location"); } If that doesn't work, it would require being able to work with the code and that is probably not worth the effort if it is just one url, especially if it is as @Hotclutch mentioned.

I think the code should be class Glotz { // constructor function __construct () { There's no reason to have a function by the class name that I can see. If code elsewhere in the shop calls the function named Glotz, I would change that to a unique name (in the class too).

I think this is more likely just an excuse for what they did. If they are using Easy Apache 4, it comes installed with more than one version of php. The host can remove the extra versions and that sounds like what they might have done but it seems like wasted effort to me. If your host uses cPanel, take a look in it to see if there is a php selector icon. Maybe it's there and the tech you spoke with was not aware of that option. Frozen won't run 7.2 without warnings. I've posted a fix or two for some known issues in threads where they were needed. But even if did work with 7.2 without warnings, the problem you will have are the addons. Many of those that have been converted, and maybe even some new ones, will need updating and that isn't something that will happen very easily.

I mentioned adding cpath, not cPath. cPath is a valid name and google will add it as it is found. It should be set to let them decide. But cpath is invalid and you are wanting to stop them so adding it is fine. In includes/application_top.php if (isset($_GET['cPath'])) { replace with if (isset($_GET['cPath']) || isset($_GET['cpath'])) { if (isset($_GET['cpath'])) $_GET['cPath'] = $_GET['cpath']; I haven't test the above but I think it will work. The best fix is to find out where the links are coming from. Even if you get all of this to work, what if a link shows up for products that uses Products_id instead of products_id?

@douglaswalkerThe problem is that the url's are coming from outside of the shop, from what you have posted. So changing code in the shop is the wrong approach, in my opinion. I suggest at least one of the following: Use googles parameter blocking tool. It is case-sensitive so be sure to use lowercase cpath when adding it. The above only affects google. To apply to all search engines, add redirect code in the roots .htaccess file to change all instances of cpath to cPath. Edit the application_top file and add code to replace cpath with cPath.

The short answer is no. The code just redirects to the given page. Once on that page, if it doesn't exist then it should show not found. But oscommerce doesn't return 404's. It might show a 404 on the page but the actual header status is different. That's why I wrote the https://apps.oscommerce.com/znMRO. Though I'm not sure that will help with your problem. Try turning this addon off to see if it makes a difference.