musicmaster

@datakick was thinking aloud how this should be solved in the next TB release. That has limited relevance for the average maintainer of a TB shop.

Actually, if you followed the discussion there was a solution. You should replace the line $cm->user_agent = $_SERVER['HTTP_USER_AGENT']; with $cm->user_agent = substr($_SERVER['HTTP_USER_AGENT'],0,128); on line 178 in ContactController.php

What about ports? Is Authorize.net using a specific port that is blocked by Hostwinds? And is there some aggressive anti-malware software active on Hostwinds? And did you check the keys that you must fill in? As a final step you could look in the console of your browser for what is returned by Authorize.net and consult Authorize.net whether there is something wrong with it.

It looks like somehow the callback from Nexi after the payment is completed is not processed correctly. Did you check for php errors in the error log of the server?

Deleting .htaccess has the same effect as disabling pretty urls. Don't forget to clean the cache after you change this setting.

SEO & URLs The second section contains "Friendly urls"

That sounds like the id field in the database table doesn't have the auto-increase property that it should have. Thirty Bees and Prestashop have more export option than import options. But you cannot just import them as database tables as the exports are almost always composed from several different tables. If you want to copy data from one shop to another I recommend my free tool Copy Shopdata.

You can update it with Prestools too.

There is another point. It is one of the core principles of Prestashop that everything still works when you delete .htaccess. And that helps greatly when solving problems. That principle is left here. For that reason I consider it dirty programming.

Which error message? If you used backticks, did you do it correctly: osl.`name`?

Your query will probably work when you change the last sentence into "order by osl.name". But I would anyway check out what that name field is doing in the tb_order_state table.

No. When a customer address doesn't save my suspicion would be that you get some php error - probably not visible because it is in an ajax call. When a cart has no carrier it could be something "logical" like that no carrier has been assigned to his country. The script checks for that kind of logical problems.

Did you try Prestools? Under Tools&Stats it has an option Shop Rescue where you can enter a shop cart number and see which carriers are enabled for it: The script checks for the most common problems (not AIM) and could help narrowing the number of options down.

What theme are you using?

That makes it a bit more difficult. You can look in the log directory of your webshop. If that doesn't work you can look in the javascript console. To do that you should enable debug mode, open the javascript console and follow what I have described here to see what the error is about.