musicmaster

It is in the paid functions of Prestools.

Did you: - empty the cache - regenerate .htaccess ???

When someone wants to build a module from Prestools product-edit I would be happy to cooperate. The most popular mass edit module on Prestashop Addons (https://addons.prestashop.com/en/fast-mass-updates/19965-bulk-mass-editing-products.html) looks like it took quite a lot of inspiration from Prestools. If such a module was made both for Thirty Bees and Prestashop it could pay for itself. As I see it mass edit and cronjobs are areas that have a broad appeal and could help TB too. One of the latest additions to Prestools was image edit that allows you to add images by drag and drop. You need to generate thumbnails afterwards as otherwise it would take too much time. However, for Prestashop 1.7 that is not necessary as it generates its thumbnails on the fly. It might be a good things to have such a thing in Thirty Bees too. Also for mass import by csv. Many of the latest additions to Prestools concern maintainability: integrity checks and cleanup procedures. My main inspiration was that I had to deal with some old shops with quite a lot of decay. As I see it, such old shops should play some role in the discussion about stability.

I am glad there is a solution for the business side of Thirty Bees. Good to see that people want to help. As for the future I would like to give the participants the following considerations/ideas: - start with the easy stuff that can make TB more popular. Migration modules from Prestashop 1.7 and WooCommerce are easy targets - as is support for PHP 8. Note that the next major version of Prestashop will be 1.8/8.0 and if they handle it as badly as the upgrade to 1.7 Thirty Bees could once again become a desirable alternative. Functionally PS 1.7 is hardly different from 1.6 and TB. - starting with the easy stuff will give you time to work out ideas for further development. - I would love to see TB once again starting to use version numbers. - As Prestashop told it, one of the reasons they didn't go forward with ASM was that every webshop company they talked to wanted something different. There may be no easy solutions here.

Those backoffice images are stored under the /img/tmp directory. And they are generated independently from the image formats in Preferences. So maybe there is some issue with the rights for this directory.

Settings->Products

A little theory about the category tree structure might help: - categories form a tree under the root category. - A shop has assigned a Home category, typically one level below the root. Its tree is only what is below the Home. - So other categories directly below the root are not visible. They can be used for multishop. They are sometimes also used for categories that people want to keep outside the tree, like Sales. Such a category can then only be reached directly. - The position of a category within the tree is determined by the id_parent and position fields. When id_parent points to a non-existing category it and it child categories will be invisible. Such a thing can happen due to timeouts. - As some people working directly on the database have discovered the hard way, id_parent and position don't work by themselves. Prestashop and Thirty Bees create an Ntree using them and that ntree (embodied in the fields nleft and nright) is what is consulted by most database operations. This Ntree is recreated after every change in the tree structure. So an easy way to trigger a recreation of the ntree is changing the order of two subcategories within a category. Sometimes you can solve problems that way. - I haven't studied the multishop effects on the categories. For example what happens when you don't assign a category in the middle of a tree to one shop. And I don't understand the role of the position field in the tb_category_shop table as nleft and nright are in the tb_category table.

Ideas enough: - look for php errors, both in the log files and by enabling debug mode - look for javascript errors - run the Prestools integrity checks - compare your files in the admin, classes and controllers directories with those of a fresh TB installation of the same version. I use Winmerge for that.

Note that the Cart.php file can contain overrides for several modules. So you need to look inside.

Obviously this is a POS related error. So my guess would be that some override belonging to Rockpos was left behind. You see that also in the Stack trace where the third entry is a Cart.php override. Quite likely this file belongs to Rockpos and deleting it will solve your problem. But I am not clairvoyant, so you will need to have a closer look to be sure.

Het hamburgermenu is hetzelfde als het standaard menu in de desktop versie. Het wil nog wel eens gebeuren dat mensen een speciaal menu hebben en dan het standaard menu leeghalen.

Klinkt als normale functionaliteit. Op smal scherm wordt de linkerkolom niet getoond. Als je de categorieën wilt zien moet je de hamburger gebruiken.

Your best bet is probably copy_shopdata - that is free and specific for PS/TB. But you have also Cart2cart and other cart migration software - usually paid.

Can you try importing the example csv file. And then step-by-step changing it to your format.

Lastname is required. So you might make it the same as the email address.