Noodleman

I would do some reading about making websites available for offline use, should be a good starting point

You can still do what you want, but you may lose some of the dynamic content. You could save an offline copy of your store. That would be static HTML files in line with what you've mentioned then save those onto a pen drive or DVD (Any device really). You can save sties within your browser, simply using "save as", although this may only get you partially towards your goal.

Ah, so your thinking of it more like a digital catalogue rather than an interactive store?

DVD is read only, HDD is read and write. CC will need to read and write data to the HDD so you can't use a DVD. the DB server (MySQL) is where the raw "data" gets stored. So, flipping this around, why would you want to run it from a DVD? (Assuming DVD is meaning, a movie/data DVD rather than some other abbreviation) also, why not sign up with a hosting company, it will save you a LOT of time and money and will provide all the underlying infrastructure you may require Check out Havenswift Hosting

you simply need to remove " {$REGISTER_CHECKED}". don't forget to clear your cubecart cache after, otherwise it may not pick up the change right away.

firstly, rename all the folders in your /modules/plugin directory, just in case a plugin isn't playing nice. Secondly, review your web hosting error log, it will have errors in there. Copy/Paste those here and we can review

What store skin are you using? I can't replicate this using the 612 foundation theme with only that payment module installed, I suspect it's related to your store skin. As a test, switch to the latest foundation theme and validate if you still have the issue.

When you uploaded all your files, did ALL of them upload correctly? can you delete the /admin directory, or does that give you an error? If you are able to remove it, you can upload it again from the 612 zip file.

It looks like your CC6 files didn't fully upload. You are missing some files within the /admin directory. re-upload the CC6 files (except the /setup directory) and check if that resolves the issue Alec.

Check your web server error log for any issues. a white screen usually means a PHP error. Let me know what you find

Opened ticket: https://github.com/cubecart/v6/issues

@Ggib, Check the default language of all admins setup to receive e-mail notifications, Check they are all what you expect them to be. When an e-mail is sent, the cart will match up the admin language to the language in the templates/content list. If there is no match it won't send anything or throw an error. If you are 100% sure you are editing the ENGLISH language e-mail template, and it's showing a language other than English, what happens if you change the language in the drop down list to English and save the settings? Do e-mails start to arrive?

Hmm, interesting. sounds like there is a conflict here. clicking the checkout button, no payment method defined... but when you click on the paypal button, it works? I am guessing the only payment gateway you have installed is PayPal Pro rather than regular PayPal?

Assuming your using CC5 or CC6, Can almost guarentee this is because your hosting upgraded PHP version doesn't appear to have MySQLi enabled. I am guessing you've moved to PHP7, since in 7 the MySQL functions were removed. Log into your cPanel for your hosting provided and if possible set your PHP level to be 5.6, this will fix the issue for you for now.

1) Check the email template has not been corrupted. This will prevent it from being sent. It's common on 610 or less. 2) Do a mail test from store settings, does it report as sending OK? In e-mail terms, you need to remember that once a mail has been sent, IE it's left the server it's totally at the mercy of the internet. It's not uncommon for e-mails to get delayed or sometimes not get delivered. An e-mail will only be considered failed if you get an NDR (non delivery report). If you can prove it's been sent, but never arrived within 72 hours then it's almost guaretneed to have been caught in a mail filter somewhere along the way, or possibly still stuck on a relay mail queue.

totally agree. This appears to drive the need to rewrite the URL and breaks the sort. I think the change of the URL would be considered a work around for the time being. Yup, removing it was only for the purpose of testing / validating that was causing the issue. I didnt get any further with this yet. :). To clarify, I don't recommend people do this in their prodution stores I think at this point we should open a github ticket for the issue as it's definately a bug, then get Al to comment on how he can address it. I think this issue will overlap with some other github requests so may be interesting to get that feedback. I will open it later unless somebody else does it first.

Well, The issue with no sorting on the sale items page is a confirmed bug in my opinion. When you change a sort order on the sale item page, the newly selected sort criteria is POSTED via a form. The posted elements are processed in cubecart.class.php and then it converts those to URL parameters and redirects. httpredir('?'.http_build_query($query, null, '&')); httpredir('?'.http_build_query($query, null, '&')); The parameters are correct: _a=saleitems&cat_id=sale&sort%5Bproduct_code%5D=DESC the function that builds the sorting selections checks the URL parameters, but at the point it checks them the information in the URL above has already been dropped. This suggests there is another redirect in play somewhere which is taking you back to the standard sale items page. so the next step is to find out where that other redirection is. Update: I tracked the problem back to the seo.class.php file. There is a redirect which when removed solves the search issues. httpredir($seo_url);

your welcome

Ok, a quick review and I've a better idea of what is going on here. My testing is using CC612, Adding the code snippit works correctly within the hook class.catalogue.product_sort $sorters['product_code'] = $GLOBALS['language']->catalogue['product_code']; This adds the "Product Code" ASC/DESC option to the menu the users see on the storefront. Selecting this item works correctly as long as you are within a category. This is important because simply gathering the products within a category is not (well it is, kind of) using "search". Using search applies some other methods for sorting data, which has known issues. Note in this ticket the example is using the "sale items" page, which does trigger a search and for the purposes of this explination should be considered "using search". https://github.com/cubecart/v6/issues/821 When I try and use the sort by product_code on the pages that "search", It doesn't work. It's the same bug as described in the github ticket. I dont have time to get into the details this very second, but the issue in my test system is that the sort code is NEVER called when you are on the sale items page. if (isset($_GET['sort']) && is_array($_GET['sort'])) { foreach ($_GET['sort'] as $field => $direction) { $order[$field] = (strtolower($direction) == 'asc') ? 'ASC' : 'DESC'; break; } } else { $order['name'] = 'ASC'; } the $_GET variable contains only this data after the sort selection is made: array(2) { ["_a"]=> string(9) "saleitems" ["cat_id"]=> string(4) "sale" } I suspect there is a redirect somewhere which is causing the data to not be processed OR the data is never submitted correctly. Note all the above is specific to "sale items", there is a SIMILAR, but different behaviour if you manually use the search. Summing up product code sorting works OK when: 1) you are in a category and use the menu 2) you use search and used the menu to sort. I can't get it to work without code changes when viewing sale items.

Pretty sure your running into a known issue with sorting, although I will see if I can walk through the code later and give you the answers to work around it.

"The third method sound like it might limit future growth if we added yet another category that required different shipping fees." Actually, it may be the most flexible, but it is the most complex to setup. Once setup you should be in good shape. If you were to add another category in the future, and for example sold Bricks, they are heavy and need special shipping. The Bricks category can be linked to another module where you define special rates for bricks and those products get linked. If a customer buys a mixture of all your good types they will get a combined rate from all the underlying shipping modules. But, as I said, it is the most complex to setup which does often stop people going down that route. I just helped setup another forum user with this method for their store who had a more complex shipping issue to resolve. I would definately start with the most simple option first, and work your way from there. There is no point in making it more complex that you would need.

Hi Frank, You don't need to configure Zones in your store because you only have one country defined. Having no countries setup also means "work for all countries". The difference will be the customer. Before providing their details (setting up an account and logged in) the modules were able to calculate a shipping rate. After the customer provided their details and was logged in, it stopped. There still looks to be some oddities with the country configuration in your store. It's weird. The issue is the underlying shipping modules working correctly at the moment, the plugin simply uses the data they return. if they return no data, there is no shipping cost. as a "not logged in" customer, the address information for the purposes of calculations is your store address. Once a customer provides their address information the rates will be based on the delivery address. I had another look at your "Zones" configuration, All of your "Zones" (Counties/States) for the USA are not associated with a country, It's blank. They should all be associated with the " United States". My guess is that your countries/zones were all deleted, and then the data you wanted was manually added, but it's not been added correctly. This isn't a good idea. It's better to selectivley delete those countries you dont want to use, or disable them by unchecking the "Status" checkbox. 1) I've fixed your invalid "Zones" data by running an update query on your database. It now has all the zones linked to a country. 2) This means in the "Store Settings" you can now configure a "State" in your stores address, and as a customer select a State when providing your address. I set your state as "Ilinois", then as a customer went back to your store front. I emptied my cart, then re-populated it with the items (this forces the cart to clear some stuff in the background and rebuild it). I now get all the correct shipping options. Any existing customers MAY need to update their addresses before they will get a shipping price as they will have the "invalid" address data stored in their address book. After they update the address it should work OK.

following up with a conclusion in case anybody else is interested. the other issue, with shipping prices being 0 was being caused by a misconfiguration in the stores country/zone list. the ID was missing, which invalidated addresses to the module and meant the couldn't return a price. After updating the ID to be correct for the USA, everything started to return prices. also, as part of the All In One clone process, there are JS files in the modules /js/ directory which also needs to be renamed. when those were renamed correctly the admin side of the module, deletions and updates started to work correctly.

you can quite easily add those directly into your stores .htaccess file. The module you linked to simply offers a friendly admin page to make those edits, rather than adding the code directly to the file.

It sounds like you can use this module: https://www.cubecart.com/extensions/shipping-methods/per-category You can install and test this along side your existing shipping module. You can have as many active shipping modules as you wish, only those enabled will return a shipping rate. It's a good way to try it out and configure it and test it it meets all of your requirements. I think it's the most simple solution, assuming you can get the prices as you want them to be. I've also got a shipping module that will do what you want. You can instal the module and try it out to see if it's actually able to do what you need. This would be a medium complexity solution. https://www.cubecart.com/extensions/shipping-methods/multi-level-shipping-by-quantity-product-category-level Direct download of the most recent version is here: https://www.noodleman.co.uk/downloads/multilevel_shipping/1.0.3_multilevel_shipping.zip There is also a third option, although it's a little more complex to setup BUT it may give you the overall level of configuration that you are looking for, and are familiar with. You can clone the All in one shipping module, essentially giving you two versions of it. One will be for use with your existing products and essentially remains as is. The other, will be specifically for your DataPets inventory. You can configure the shipping rates you would like for those items. You can then use the module linked below to configure that DataPets products use the DataPets shipping module, and all other items use your standard rates. The module then adds all the rates together to gather the final shipping price. https://www.cubecart.com/extensions/shipping-methods/link-cubecart-products-to-specific-shipping-services-/-modules