musicmaster

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.

The Prestashop solution was to standardize on the --xxx_default. That is the format of the standard theme and of the backoffice. Some themes just used that format. Others used their own format but left the Prestashop format on the disk for the modules and the backoffice. My preference would be to continue that policy. I don't like solutions with a notfound routine. It is not transparent and as such confusing. You are bound to get questions from people who notice that things don't work like they expected. Simplicity is a great thing. In my opinion highres images are a much bigger problem. I gave up on them after - probably due to some conflict between Panda and Thirty Bees settings - I ended up with four versions of every image.

I tried changing _PS_ROOT_DIR_ and _PS_CORE_DIR_. It doesn't work. On the backoffice you see it immediately as you get the typical "without-css" unformatted page display. The front office seems to work at first sight. But when you check for javascript errors you see problems there too. There are a few php commands - such as realpath - that produce the backslashes and they are used widely in the software. It would be a major effort to check them all out for causing problems (for example by subtracting _PS_ROOT_DIR_ ). Also - even if you did this you might find problems with modules and other third party software. Besides that it would harm the PS 1.6 compatibility.

The CoreUpdater has some Windows problems that as far as I know still hasn't been fixed in the official distribution. You can find here what you must change:

Try to install a fresh TB 1.10 with the Niara theme and you will see dead image links in the new products section. That module is looking for medium_default and that is not available as only Niara image formats are generated. I doubt whether the PageNotFoundController can be a good solution. Modules expects a certain format and when they receive another format their layout can become seriously damaged.