musicmaster

I am waiting for an upgrade of both the migration module and the main package before I make another try. I never heard any serious explanation after I reported my previous disastrous attempt to migrate. I am getting increasingly pessimistic about the future of TB. The focus is too much on implementing new ideas and celebrating every little new success. Any bad news is ignored. This reminds me of what is going wrong at Prestashop. To get traction there should be much more focus on solving any little problem that is reported.

@mdekker said in Database differences: Can I copy some of the texts for the documentation? Sure, no problem.

I made a comparison of the database structure of Prestashop 1.6.1.11 and Thirty Bees. For those interested here a summary of the conclusions: A lot of field size differences. Most interesting is password going from 32 to 60 positions. For the rest mainly id sizes increasing from 10 to 11. Both changes happened also in Prestashop with the change to 1.7. CHARSET changed from utf8 to utf8mb4. This is accompanied by a lot of COLLATE clauses in the database. With COLLATE you can declare that with search or sorting a different charset should be used. Different character sets have different ways to deal with accented characters. quite a few tables were dropped: psadvice, psadvicelang, psbadge, psbadgelang, pscondition, psconditionadvice, psconditionbadge, pscronjobs, pstabadvice All the tables that are dropped in PS 1.7 (pscompare, pscompareproduct, pstheme, psthememeta, psthemespecific, psscene, psscenecategory, psscenelang, pssceneproducts, psscene_shop) are still present in TB. one table got an extra field: displayfromsub in the ps_category table a few tables got extra keys: psconfiguration (name), psconnectionssource (httpreferer and requesturi), pspage_type (name) four new tables: pscurrencymodule, psmodulecarrier, pspagecache and psredisservers. pscurrencymodule is a bit puzzling as there already exists a psmodulecurrency table. psmodulecarrier has three fields: idmodule, idshop and idreference. Missing is an idcarrier: maybe this is id_reference. This table - with the same fields - can also be found in PS 1.7. Prestashop 1.7 has a few new fields in the product tables: isbn, show_condition and state. They are not present in Thirty Bees.

A little more research: if I copy the full community theme from a fresh TB install it does show up in the backoffice. However, it still shows with a missing image. And my front page remains as empty as it was before - even after a cache cleaning. It is a pity that I cannot place images or file attachments here. You need that for bug reports.

@Traumflug I am working on a Windows 10 computer. I haven't tried it yet but I would expect that the problem can be reproduced with - a Windows 10 computer with Xampp (=mariadb) - a fresh PS 1.6.1.11 webshop in a subdirectory of the localhost root. - choosing for the new theme when the option is given during the upgrade I did a little more research on why the new community theme didn't show in my backoffice. My converted shop has both themes as subdirectories below the themes directory. So I checked the community theme and compared it with a fresh TB installation. I noticed that two directories (cache and pdf) were missing. However, adding those directories (by copying them from the fresh TB installation) did not fix the problem. I also checked the database, but I couldn't find any problem in the psshop* and pstheme* tables. Except for the fact of course, that in the database the shop is assigned to the community theme but that in the backoffice the community theme doesn't exist and the shop is assigned to the default theme.

SEO&URL's is correct. Below you find the full html of my frontpage - from the body tag downwards (I have removed empty lines): Toggle navigation Prestools - The Prestashop tools shop

"thetexts.php isn’t a file coming with either PS or 30bz" As I said: this index.php file in the root does not belong to PS or TB. The shop is in a subdirectory. So the problem is that TB is somehow including this file. "Solution is to either return file Shop.php to its original state" As I said the only file that is changed outside the template is Cart.php. So Shop.php was not changed

The root .htaccess is not changed. Nor any other file. The way that see that it opens the root index file is the error message: Warning: require_once(../thetexts.php): failed to open stream: No such file or directory in C:\xs4ampp\htdocs\index.php on line 6 I have one error in the TB log file that is repeated twice: ERROR 2017/03/19 - 12:38:08: Shop not found at line 404 in file classes/shop/Shop.php ERROR 2017/03/19 - 12:44:06: Shop not found at line 404 in file classes/shop/Shop.php This is NOT a multishop shop.

1.6.1.11. The only non-Prestashop module is Michael's Stripe module. And Cart.php has been adapted.

I tried to update my Prestools webshop to TB. Luckily i worked on a localhost copy. The update itself went without problems. I chose to use the new TB theme. But when i was finished and I looked in the backoffice at the themes, there was only one theme - the Prestashop default theme - and that was set as my default theme. At the front side things were even worse. The home page displays only my logo and a black bar. When I switched MOV-DEV on I don't see any errors. And when I look at the source code it is very short, but it correctly ends with a html end tag. The page of a subcategory was just as problematic. I got an error message indicating that it was trying to open index.php in the root. (I have different software in the root and the error message I got war clearly generated by that software) But as this shop is located in a subdirectory it shouldn't try to do anything in the root. 

A lot of improvement can already been achieved by having a good look at how indexation works in Prestashop. If you look in classes\search.php you see that for supplierreference the field of the psproduct table is used instead of the fields of the psproductsupplier table. Also - when a product is in more than one category only the name of the default category is used.

As a small contribution to the development of TB I have made an overview of the type of products that are not or not well supported by Prestashop. I hope that a bit of discussion and the input of different people with experiences of different webshop software can contribute to build an overview of the options. The most important problem is probably the “million –combination problem”. When you have a product with many attributes (computers and cars are good examples) the number of possible combinations can easily explode into the millions. As a consequence the product will get stuck in both the back and the front office. A related problem is that stock keeping doesn’t work: if you sell a car with or without radio it is still only one car. If you analyze those cases you see a few scenario’s that don’t fit in the Prestashop cookie cutter solution: - Some attributes are in fact separate products. They might be considered as accessories but you want to sell them on the same page. The car radio is a good example. This kind of attributes comes in two varieties: some are also sold as standalone products while others are only sold as a part. - Other attributes concern things that never get out of stock. If you sell furniture you may offer it in different colors. But as you paint them yourself and you have an ample supply of paint this will never be a restricting factor. In this category fall also work-related attributes like when you sell a product in a rude and a polished version – the latter involving some processing by you. Then there are the products that don’t fit. One category are the “fractions”: products sold by meter or gram or other linear unit. Say you sell cheese for 10 euro a kilo. You have a piece of 485 gram and you would like to receive 4.85 euro for it. The only way to achieve that would be to set the price per gram. But that would mean that you list it as 0.01 euro per gram. That will result in rounding errors and it goes also against industry practices that dictate listing prices per 100, 500 or 1000 gram. Also it doesn’t give the customer a quick impression of whether the product is cheap or expensive. Another category are the “standalones”. These are a kind of customizations where you want to set the price. It might involve work. If you sell floor coverings you typically bill carpets and work to install it. But you don’t want to make a new “work” product for every new customer. I sell fancy boxes that can be filled with candy. I would love to give the customers the freedom to choose which candy they want in it but that is impossible under Prestashop. Candy sells by weight and different types of candy have different weights per liter. It would be easy to write some custom software that calculates the correct weight and price but I can’t store it at the moment. So what are the possible solutions? In the case of the attribute combinations my favorite would be to allow more than one product on a page. They should be in the same html form so that you can order them with the same Buy button. This means that you will need to mention somewhere the number of different products on your page and give them numbers to discern them. You need also to indicate which is the main product and which are the options. For attributes that don’t affect stock there are two possibilities. You might create a new kind of attribute for that. You could also create a kind of pseudo accessories for them. You might for example have a “product” colors that cannot be sold alone for this purpose. It is a rather convoluted solution but it may be easier to implement than a new kind of attribute. In the case of the fractions the cleanest solution is probably to indicate somewhere that your price is per 100 units (or whatever number you want). In the case of the standalones the basic point is that there is no standard price and that the shop owner must somehow provide a price.