musicmaster

Did you try re-installing Store commander? I noticed that the upgrade caused some strange effects with my modules. One disappeared - but I am not aware of having deleted it. And my payment modules became kind of inactive. That is: they didn't show in the front office but when I activated them in the backoffice they said that they were already active (but doing so solved the problem).

I believe this is a good solution. My idea of implementation would be: - Make this a extra property of an attribute: obligatory choice or not. This means part of the core. - An alternative would be to make it a product attribute but that would automatically involve all attributes. Here you run in the same limitation that causes trouble when a product has too much attribute options: the Prestashop code knows no product-attribute combination as a useful concept. - The best implementation would require that the template is adapted for it so that it can handle that extra flag and insert a class and a "please choose" text (with the option for translations). You could make it template independent but that would involve some extra overhead. - Defaults might still be used when you put the product in the cart on a category page where there are no select fields. I don't believe that this is complicated to do. The main action happens in javascript on the product.tpl template. In the core you only need to add the option to set an extra flag and to transfer that option to the template. Of course, as this a core modification, the ultimate decision is with Lesley and Michael. I wonder how Yaniv14's code would work. Do you have to select a product and an attribute? And how do you insert the changes into the template?

@zimmer-media I am sorry to see you go. I hope Lesley may tell us something that will make you reconsider. If not so: I wish you te best, personally and in business. @Traumflug I still remember that Prestashop had its spinning button problem when Chrome had changed some settings. It was Friday and the guy from Prestashop on the forum wrote that he was going to have a very nice weekend. And the forum exploded from indignation because that meant that at least until Monday (and it fact it took even longer) they had a shop where they couldn't add products. When TB was founded the argument was that we could do this better. Opensource software is not just take it or leave it. Even if he doesn't pay for the software the user invests often a lot of time (and often money) in learning and customizing the software. That puts him in a position where on the one hand he will often be prepared to pay for additional services but where on the other hand he expects some reliability from the author. He should feel responsible that the functionality that he promises actually works. You are right that these are not legal obligations. See it as a kind of moral obligation: unsupported opensource software seldom lasts long. My impression is that Zimmer-media is disappointed at that point. I don't know the technical details so I don't know whether he is right - a lot of problems are caused by third party modules and themes and custom modifications. But given his position in the community we should take his complaints seriously.

This is a tbupdater version with my updates. I have tested it. You can unzip it, rename it and then copy it to your modules directory. https://www.prestools.com/tbupdater126.zip

@lesley The module is not unstable. The bugs that were there were caused by the migration of the code from Prestashop to TB. Sure, there is always room for improvement but the problems weren't so serious that the backup part of the module had to be kept dysfunctional for over a year. I made some bugfixes and they were implemented in tbupdater 1.2.4. There was still one problem left but I needed to work on other things. Finally I came back and fixed the last problem and sent it to Michael. And then he published 1.2.5 that undid all the fixes of 1.2.4. And I never got an explanation... @wakabayashi Except for the update backup everything did what it was designed to do - and that's the problem. Even the backup part's dysfunction was more or less intentional when you consider how long it has been the case and how my code that should repair it was being ignored.

My experience with migration from Prestashop was as follows: - after a seemingly successful migration I opened my shop's front end to find little more than my logo. It took me considerable time before I understood that in the process TB had disabled all non-TB modules. And as it doesn't replace Prestashop modules with their Thirty Bees equivalent that is nearly everything: blockcart, blockcategories, blockcms, homefeatured, etc. So you end up with a very empty screen. - having arrived at 1.01 I wanted to update to 1.03. Being a lazy person I went for the default - and hang forever. Only when I tried to upgrade without the backup did I succeed. - with the migration I had opted to keep my old template (the PS default). But now I decided to try the TB default one. Strangely enough there isn't some place where you can get this just like any other theme. Instead there was some button to install the default theme. So I clicked that button - and I lost my frontoffice. It pointed to an empty directory that was supposed to contain the default theme. Copying the theme from a fresh installation solved the situation. If you asked 100 people to start this journey how many would not give up half way? This is basic functionality that a large part of the potential users will encounter. It should just work fluently and according to what the average ignorant user expects. I started to work on the update module to do something about these problems. It was a rather strange experience. The code is just the old Prestashop code with some changes. Unfortunately those changes had introduced quite a lot of bugs and two of those bugs created an eternal loop. It really puzzles me why this had to stay dysfunctional for such a long time. Was it slow? It depends how you look. The backup might take hours if you had a megashop with gigabytes of data but for the average shop it was ok. Prestashop has been able to live with it for many years without much complaints. And the starting point for optimization was obvious: the present algorithm makes many ajax calls a second that each backup a few files or database elements. Increasing the chunk size would be a quick and easy solution.

@wakabayashi said in Progress sharing: @MockoB with seriously I meant like "if they can devote all their time into tb". Now tb doesn't generate income, so they have to agree on many other coding projects, to save their incomes. Thirty Bees started aiming to be a Prestashop 1.6 without the bugs. Prestashop is making millions so if they accomplished even a part of this they would have stuck gold. Yet I have been puzzled by the implementation. Prestashop's strength is that 9 out of 10 times it works out of the box. Of course it has it problems but they tend to be deeper down. But the basis is very smooth. Unfortunately I am missing that smoothness in Thirty Bees. The core looks great but it has a lot of rough edges. It is easy to work around those rough edges when you know a bit about software but it is a big obstacle when Thirty Bees wants to be the successor of Prestashop. Try to do an upgrade or a migration from Prestashop: it is a disaster. What is worrying in this respect is that I don't see any indication that this will change. Michael seems to love the heavy stuff - like speed optimization, payment modules and search modules. But getting things working smoothly is mostly attention to detail - and a dedication to userfriendliness. From a technical point of view the problems are often trivial. The love of innovation has also harmed the maintenance of compatibility with Prestashop. Was it really necessary that compatibility of themes became a major problem? I made some contribution to the upgrade module - and saw my contribution disappear in smoke without explanation. My feeling is sometimes that Lesley and Michael are disappointed by the speed of adoption of Thirty Bees and are developing doubts about the project. It looks like they haven't given up yet, but that they don't have a clear idea any more on how to go forward.

Today I found suddenly that my shop was down. Whatever I did I got ERRCONNECTIONREFUSED. I have no idea what was the problem. In the end I got the shop running again by rebooting. I have no idea whether this was caused by 30Bees or not. But I hope someone can give me suggestions what did happen so that I can prevent a recurrence.

I want to enable the left column on my product pages. So I went in my backoffice to Preferences->Themes and chose Advanced settings. And then I get a very long list of pages where I can enable or disable the left column. But the product page is not among them. Neither is the home page. Is this not possible?

That depends on how the images have been inserted in the database. If each product has one image that is "cover" then it is relatively simple - assuming you are familiar with mysql and PHP. You get then in pseudocode the following: SELECT idimage AS myimage FROM tbimage WHERE cover IS NULL foreach myimage DELETE FROM tbimage WHERE idimage=myimage DELETE FROM tbimagelang WHERE idimage=myimage DELETE FROM tbimageshop WHERE idimage=myimage That is the database part. But you will also want to delete the images themselves. You can do that with Prestools (it is a paid addon) or you can program it yourself in the loop above. If there is not a cover for each product (what means that all cover values are NULL) then the loop will become a bit more complicated. So it is important at the start to check that all products have one image where the "cover" field is '1'.

@kleijn36 Prestools cannot edit warehousing data. That is a limitation of the software. It only gives you a passive overview of what you have in stock.

Hi Kleijn, Sorry to hear you found some problem. I have uploaded an improved version that should solve the problem. Can you download it from your user account?

Recently Prestools had some bugs due to a few structural changes. Line submit had been changed to make virtual product edit work and to increase security the cookie format was changed. It should all work now again. Please notify me if you find any remaining problems. Recent improvements in Prestools: - problems with the mini-module were fixed. - product-solo was fixed. It had been dysfunctional since the line submit fix. Now that has been repaired and also a few improvements have been made. - Integrity checks has been improved and offers now the possibility to repair some problems. - Some minor additional functionality: attribute sort, statistics on categories - Some minor bug fixes

Today I found the same problem in my shop: one product had the url of another. I never used csv import. Maybe something has gone wrong duplicating a product.

One possibility is that for some reason they have all the same link_rewrite field. You could test for this by disabling pretty urls.

Everyone a happy 2018 with good sales!

Prestashop has announced multiple features for 1.7.3. I haven't checked out how they will do it but I would prefer to keep compatibility with them. http://build.prestashop.com/news/prestashop-1-7-3-0-beta-1/

From an user point of view it would certainly be more pleasant when Prestools would use the TB login. However, it is not as easy to implement as you suggest and it might have disadvantages too. Prestools operates outside the TB engine. Only that way can it have complete control over the screen and achieve adequate speed. So in order to use the TB login - that is tightly integrated with the rest of its code - the code must be replicated without that context. That would require a deep understanding of how the TB login works (the shop password is stored encoded and you also need to deal with the cookies that keep you logged in). So this is quite a tough job and I have never found the time and motivation for it. Maybe somewhere in the future, but this has not a high priority. I believe Prestools is quite secure as it is. But of course suggestions for improvement are always welcome.

There are many different ways to get products with specific field values: - you can search for it - you can use the Sort By field. Even fields without a value will appear somewhere either at the top or the bottom. - you can also sort by clicking a column header - Just setting the field in the Search field is sometimes enough. If you search for example for discounts (without filling in a specific value) you will see all products with discounts. And by using the Not operator you can also see all the products that do not have a discount

Any insights from the file timestamps in the modules directory?

It would be great if those Ajax error messages became a bit more explicit - specially when DEV_MODE is on.

Looks ok. One addition for db.php: The function executeS() contains the Tools::displayError() too. It too should be replaced with echo. Contrary to its name Tools::displayError does not display anything. It just returns the value that you give it after processing it with htmlentitiesUTF8(). Elsewhere in the code you see things like "die(Tools::displayError($msg))". It is used in several other places in Db.php too and I propose to replace them all. Note that the main db.php (not of the tbupdater module) uses the throw command. Unfortunately it is not easy to use the main classes in the updater module as the updater module uses a special namespace.

Thank you, Lesley, that worked. The site was migrated from Prestashop. Initially I kept the PS theme. When I later tried to migrate to the TB theme I got a crash and had to copy the theme files manually. Obviously something went wrong in that process. See also my error report about my problems when I tried to switch to the TB theme: https://github.com/thirtybees/community-theme-default/issues/28

On category page of my Prestools webshop I still don't get images - except for products from which I just visited the product page. But that effect lasts very short: minutes at most. This problem is specific for Chrome. There is no problem in Firefox or Microsoft Edge. When I look in the console I see error messages like: Failed to load https://www.prestools.com/39-homedefaultsmaller/discounts-plugin-for-triple-edit.jpg. This stuff with "smaller" and "smallest" is new to me. What does it mean? Why are these not predefined image formats? How is this supposed to work?

It is starting to become controversial. See this article: https://www.trustwave.com/Resources/SpiderLabs-Blog/%E2%80%9CDon-t-Mine-Me%E2%80%9D-%E2%80%93-Coinhive/