musicmaster

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.

I am not sure what you mean with "the modules list at the bottom of this page are all highlighted in red? " The javascript error is in Jquery and I can't find what the real origin is. My prime suspect - for lack of better - is your highdpi/highres code. Could you try what happens when you switch that off (don't forget to clean the cache after you do that)?

Can you look in the error log of your server to see what this 500 error was about?

In the modules section of this forum you will find quite a few free modules. Did you try Prestools?

Could you disable the smart cache for javascript and some other optimizations in Advanced settings->Performance? There are some javascript errors and with the optimizations it is not possible to determine which files cause them. In addition you might consider switching off pretty urls. The file system and the database for images are exactly the same for Prestashop and Thirty Bees. So I would consider the fact that most product images did not make the migration a rather serious problem. It is a common problem that images need to be regenerated after a migration or a change of theme. But in your shop the images I checked are really missing. Have also a look at your shops with Prestools. As it works directly on the database it will provide a good indication to what extent your problems are in the database and to what extent in the software and shop settings.

Other people have a problem to reproduce your problem. So the obvious next step would be that you try to reproduce it on a test shop (just a fresh TB 1.1 installation on localhost). That would help to pinpoint the problem.

That is a risk. But with an automated replacement system you have the risk that the replacement will not have the same 250x250 format as the original for which the layout was built. It might even rectangular instead of square.

Personally I prefer to add the _default image formats to my shop:

Nice catch. I was wondering whether it wouldn't be possible to centralize the test information. Now we have - ConfigurationTest.php listing the tests that need to be done and doing the tests. - AdminInformationController.php for the error messages in an active shop - install/controllers/http/system.php for the error messages during installation It was this complexity that made this problem so hard to solve. Wouldn't it be possible to centralize everything in ConfigurationTest.php. For example by having a more complex array of tests that includes the error messages?

Your error message was: This function checkOptionalTests() is in the file install/models/system.php. Can you have a check whether it is indeed there on your system?

Try going one level higher: \classes\ConfigurationTest.php from line 75 and further There you find the functions getDefaultTests() and getDefaultTestsOp() In my installation 'Tlsv12' is in getDefaultTestsOp() and not run at all. Anyway, just delete it from both.

That was not what I meant and it will destroy Windows compatibility for modules and third party software. Quite likely it will make Thirty Bees unusable for Windows users. Prestashop is built with _PS_ROOT_DIR_ and _PS_CORE_DIR_ the way they are. The only places where we have problems until now is two places with recent code changes. That is easy to fix. Note also that what happens in the socialsharing module (storing the full server path of a file in a javascript file visible to the customer) is highly unusual.