musicmaster

One other wish concerns the payment modules. I noticed that neither with Paypal not Stripe payments I there is any information on which order the payment was for.

I looked in my archive and I found some links. No idea whether they still are available and cost the same. http://addons.prestashop.com/en/front-office-features-prestashop-modules/2942-multi-dimensional-products.html 299 euro http://addons.prestashop.com/en/front-office-features-prestashop-modules/5628-product-properties-extension-sell-by-weight-lengthetc.html 199 euro http://addons.prestashop.com/en/front-office-features-prestashop-modules/18794-linear-meter-sell.html 129,99 http://psandmore.com/ 199 euro PS&More extension for PrestaShop https://www.prestashop.com/forums/topic/93968-change-order-quantity-to-a-decimal-value/page-3 A do-it-yourself method explained on the forum.

There are several modules for this. However, this is tricky functionality. I remember seeing how it was implemented in one of those modules. It added a new entry to the database (if I remember well a product) for every visitor - even if he didn't buy the product but just visited the page. After some time this resulted in a very bloated database. Of course a more mature implementation would work a bit like Attribute Wizard Pro: each order would have its own entry in the ps_product_attribute table, those entries would have the right price and the only attribute they would refer to was an empty string. If you added the product to the cart the length or weight would be stored in some extra field in the ps_cart_product table. When the order was completed the length/weight would be part of the product name so that the ps_order_detail wouldn't have to be changed.

My wishes: - An option to start an attribute combination with “select a” instead of a default value. I know this is a template job... - Option to automatically hide categories without products or subcategories with products. You have now modules that do such a thing. But the problem is that while they disable you have to re-enable yourself. - Option to disable combinations. - Auto-save for customizations - Option to include attachments in messages to customers - And finally the big fish: a solution for the combination problems. There are several situations where the Prestashop combination structure gives problems: - with too many combinations everything becomes slow - some attributes don't influence stock - some attributes have their own stock The solution that seems the most feasible to me at the moment is the following: - you need an additional table. Let's call it product-addons. - a product-addon can be either a product or an attribute. If you need stock keeping you use a product. A product can be set to be used in this function only. - the attribute table is expanded with a weight and a price field - an addon product can have attribute combinations. If there is more than one attribute the combinations will be merged into a single select menu ("carpet size:large; color:red"). If an addon product has product-addons itself they will be ignored. - addon products without combinations and single value attribute groups will be displayed as checkboxes. - I hope there is some possibility to insert those extra fields with hooks in templates that don't support them. - the category_product table will need an extra field for the product-addons. In the order_detail table the information can be part of the name field.

Thanks. I see that you allow settings per feature and you have also added a flag for custom values. Nice to see extra options compared to Prestashop. But I am I am not yet sure how easy it will be to implement for me.

Is there some flag in the database that indicates that multifeature? I would like to support it in Prestools like I do it for PS 1.7.3+. I assume other people building for Thirty Bees will face the same question.

I had a look at it. I created an account; logged out and tried to login again. I couldn't login again but I always got the same error - no matter whether the password was right or not. My gut feeling is that it could have something to do with groups.

What kind of errors do you have? Many errors are related to errors in the database when due to timeout there are some inconsistencies. They can easily be solved.

I tested Prestools in an upgraded TB 1.2 shop but I didn't see any error messages. I just uploaded a new version of Prestools. But I doubt that it will solve your problems as I don't understand them very well. Both line numbers that you mention are VAT related. My guess would be that there is something wrong with one of the tax tables. But it is hard to find out what without more information. If you want you can pm me.

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.

Did you enable debug mode? Did you look in the PHP error log?