Raymond

Hi Lesley, thank you Yes, it works, I settled the customized universal payment module a time ago and did not remember that allows to choose a carrier, went back into that panel, and yes, the method you suggest works, so that is covered. What I could not do is to set a discount without a coupon that can be applied only to clients who chose to pay with bank wire. When creating a rule for the cart if no coupon code is created the discount is applied to everyone, if a coupon is created the problem is only half solved because the client need to receive it before placing the order, furthermore if that code is shared also clients paying elseway might try to use that same coupon code. So maybe could be good to add to the cart rules configuration panel the possibility to indicate that a discount is valid only with certain payment methods Thank you

Hello I did a fresh installation of tb1.2 and Panda, seems working fine so far, but some things do not, I did not contact sunnyto yet, however what I noticed is that editing the text in some display boxes in the homepage the background color does not work, the flash button to add html code snippets does not work and in general seems that the editor is crippled somehow. will do more tests in the next month... Bye

Hi I do agree about this possibility, why not make keep a list of enhancements and/or new features to be implemented in the standard installation and have a fundraising campaign to support the developers team?

Hello Another important feature that I do suggest is to add the possibility to assign specific payment methods to products just as already happens for shipping carriers. It happens that some products cannot be paid with credit card, or cannot be be paid with bank wire, the reasons can be many. Another particular case is when the seller want to simply have the client to send in a request or proposal to buy some goods but not to have the sale automatically approved and receive the payment nor send a request to pay until the deal is approved and confirmed but not allow this same procedure for other products. So far with your good "customized payment module" it is possible to create different forms of payment, using the options in the payment configuration (menu modules>payments) it is possible to decide a lot of things, but there is no way yet to tell to the system to show up only certain payment methods for each specific product... It would be really very useful the possibility to have all available payment methods assigned by default to every product or to be able to assign only one or more selected payment methods to specific products, just as it happens with the shipping carrier. In this new scenario the system would allow all sorts of operations, so for the simplest setups nothing would change, the seller would just add a few payment methods and specify nothing, for more complex setup instead the seller can create a more granular set of rules depending on the nature of the products and problems to be solved in order to perfect a sale. E.g. the seller on top of allowing only certain payment methods for some products can indicate that paying with a specific method the client can have a discount only with certain products and not with other. Why that? e.g if I sell a low price product, let's say a set of wrenches, or a 100$ loudspeaker, I might want to invite the client to pay with bank wire and concede a discount, e.g. "pay with bank wire and get 3%", for other kind of products, e.g. a 4000$ computer for which for some reason the credit card payment would just not be allowed the discount conceded when paying by bank wire transfer would have no sense, in fact in that case the bank wire would not be an optional payment method but the only way to pay. Thus a seller could create several kind of payments, e.g. pay cash with discount, pay cash (but no discount), pay cash COD (with a surcharge maybe on some product and not on others...), pay with bank wire, pay with bank wire with a discount, pay with whatever method the plain price or with a discount or with a surcharge depending on the case, or furthermore pay with credit card or other method defined with other third parties modules and for each product only selected payment methods will be available. In this more complex scenario, if the seller do create more versions of the same payment method (e.g pay with bank wire without a discount and pay with bank wire with a discount) the only thing that must be taken care of is to always specify which payment methods are available for each product, which in my honest opinion is a good compromise in change of great flexibility and ability to arrange all sorts of sales for particular products. Btw, this same last problem could be also alternatively solved with the optional possibility to assign payment methods to categories, so a seller could create special categories for the products that need to be paid with special methods... this would create another kind of incongruence, e.g. have products that belong to a category assigned to two different categories, however would still be another extra possibility to granularly arrange complex marketing scenarios... it will be up to the seller to find best ways for the catalogue that need to market, but at least will have a wider gamma of choices to do it. Thank you Best regards

Hello A needed useful feature that I suggest is the possibility to define remote areas for the couriers' fees. Some couriers in order to serve certain remote areas do apply a surcharge, there is no way in the actual system to show to the clients shipping options that take in account such surcharges to have the goods shipped in remote areas. Some couriers to deliver in certain areas that are considered to be hard to reach will add a 5$ or more as a surcharge on top of the regular shipping fare, not all couriers would do that, furthermore some will apply a low surcharge, others would apply a quite hefty surcharge. Both the client and the seller should be able to know that and the client should be able to decide which courier would deliver at which price in a specific area. In other words the possibility to choose among several couriers should be more granular. For the seller this is an important problem, especially for goods that have a low price loosing e.g. 5$ or the like on the the shipping might mean loosing all the revenue if not selling underprice. This problem could be resolved using the zip codes, the zip code during checkout could be checked against a table containing the zip codes that the seller indicates as remote areas and associated to a specific zone, if there is a match then in the cart the client will see the special fares applied by the various couriers that can be chosen for that zone. In other words as a practical example my idea is this: the seller do create new Zones, e.g. "UK remote areas", "Germany remote areas" and so on in the couriers configuration do indicate the fares for those zones in a new config panel do input the list of zip codes that are considered remote areas so that are stored in a table and respectively associate each list to the new remote areas zones, eg. as said above "UK remote areas" zone, "Germany remote areas" and so on the system during checkout control if the zip code given by the client in the delivery address match against the remote areas zip codes table if there is no match the regular fares for that zone do apply if there is a match then an override is done and the special fares indicated for the "remote areas" correspondent zone will be applied. I am not fond of coding, I do not know if this can be done at core level keeping the compatibility with modules and/or third party software to manage Tb or prestashop, personally I do use prestashop manager as an example and find it to be really useful, I would not like to not be able to continue to use it. So I do not know if it is better to have this feature as a module or as a core thing, sure is that according to me should not cause compatibility troubles. Finally, I am pretty sure that this feature would be very appreciated by many sellers and would make a very practical and noticeable difference in comparison to many other e-commerce platforms. I hope that you will consider implementing it. Thank you Best regards

I noticed that avatar picture for employees are to be set on gravatar.com, I do not really understand why this is not an option and the only way to set one... I suggest to add the classic way to upload an image locally and, presuming that is needed by some or many, keep the gravatar.com thing as an option In my opinion is not good to have the platform rely too much on third parties, especially if as only option, what if for any reason there is change on those third parties side? what when users do not like that third party? what about privacy?.... This is not a very important thing, one can just ignore it, or modify the core, but to me at least does not look good and also is not reassuring to have to rely too much on third party services and have no options by default to avoid those...

Hello I tried to set a image for an employee and saw that it is not possible to simply upload a image, one need to go on gravatar and set there a image. Why this? Would not be much simpler and safer to just upload an image that is locally stored? Personally I would settle this to use a local image by default, and use a gravatar avatar as an option (if this possibility to use a gravatar thing is there I guess is needed for some, however I do not understand the reason...)

Hello I just installed tb1.2 and begun to test it, I was curious to see what this HTML block is, I also got the "controller not found" error message, for curiosity I checked also on the other installation I am working on which is a tb 1.1, there too same thing, the error appear... What is HTML block? What is useful for? Why I do get this "controller not found" error message? Thank you

Hi Andy Nope, I haven't done it, however I do prefer to fix the problem checking the actual installation and see what causes this, I do use transformer, I am not sure that there are updates available for TB that have not to be tweaked again.... However, I just do not know if it is a issue due to the theme or else, that is why I do ask info to find the culprit... Thank you Best regards

Hello Colorful Ant I tried already, same result, besides that removing own IP address in the maintenance tab is enough to reproduce the bug. The maintenance page just does not appear, is blank. Thank you Best regards

Hello The website (tb 1.1.0) works fine if I add my IP address while in maintenance mode, I can preview it and test, no problem. However if I remove the IP address needed to preview the website instead of visualising the courtesy maintenance page I do get a plain blank page. I tried to activate the debug mode, however no error is shown, just a blank page, I have no idea about how to solve this problem. What should I check in order to fix that? Thank you in advance. Best regards Ray

Hello Everyone I was curious to know at which point is the development of the new version, any news about? Thank you Best regards

Thank you Traumflug and Purity This is clear and reassuring now, so that "rule of the thumb" I was toldI read somewhere and too by some, except for the H1 tag to be not used twice, is a hoax. Although maybe this was a pretty "noob question" I hope that my post and you answer can help everyone else me who had a any doubt about this topic. Kind regards Ray

Hello To start with I want to tell that I am very happy of Thirty Bees and I express my big Thank You to the Staff and Everyone contributing to the project. Sorry for my noob question here, I know that might be a silly one As far as I learnt, as rule of the thumb formatting any text, in order to not have SEO problems is good practice to use headings and paragraphs in a proper way, so the main title would be marked as Heading 1, the following text as paragraph, then the next relevant subtitle would be marked as Heading 2, the following text as paragraph and so forth up to Heading 6 and related text in a paragraph... An important thing doing this is to never use two times the same Heading kind, so never mark a title and one or more subtitles with the same Heading tag.. When I do use TB to create a new product page, blog page, CMS page, category description, in the GUI panel used for each, there are all the fields to be filled, title of the page, all the necessary metadata, short description, description, tags and so on... In the final resulting page at the end of the game what is shown in clear and in the metadata is given not only by the product page itself but also from the various blocks coming from all modules used, e.g. a reassurance block, related products block, accessories block and so on.... Using firefox debugger I analysed a typical product page, I found out that H1 was automatically assigned by TB to the text used in the title field when the page was created, therefore I think to have to use Heading 2 for a title in the short description, or in alternative use a paragraph in the short description and a H2 title in the long description and then assign H3 to H6 to all other subtitles in the long description. Is that correct? However, here comes the thing that most confuse me, looking at the various blocks hooked in the product page I analysed I found out that the reassurance block uses the tags H3 to H6, another block from a module showing accessories to add to the cart also uses H3 and then H4 more times, the related product block also uses the H4 tag.... and so on.... I do not use so far other modules, but as I have seen I can expect that using other modules more blocks with more doubled Heading tags might be shown.... Overall thus I see that apparently in a typical TB (or PS) product page this rule of the thumb to "never have double Heading tags in a page" is not respect at all.... I am not expert enough to understand well what all this mean... Is that rule of the thumb of not having double heading tags not true? OR If those double heading tags are in different blocks in the page, do maybe the crawlers do not consider it a problem? .... Does anyone knows well this matter and maybe explain for good how to avoid these kind of subtle problems that might affect the SEO? Thank you in advance for any help. Kind regards Ray

Hello Everyone I tried to upload products from Store Manager 2.57.0 build 2233 to thirtybess 1.1.0 and everything seems fine. The test included upload of catalogue from CSV containing products, then I tested creation of products and upload, upload images, specific prices, attributes, so far for that I noticed no problems, except having to clear the cache sometimes when I uploaded new specific prices. I do not know if the cache cleared was the solution, however it happened to upload specific prices, see it in the back office product and not in the front office, I deleted the specific price, created it again in the back office and then worked, out, I also cleared the cache and after that all other specific prices in other products worked normal, the created other specific prices in store manager and uploaded it and they all worked fine without having to repeat that test procedure of creating it form back office and or clearing cache... do not know how to explain this behaviour, however it works now after that first "thing". Hope this help. Again, I suggest to everyone to ask EmagicOne to support ThirtyBees. Bye R.

Hi Signut Yes, I renewed anyway the Store manager update license and I regularly update it, I am also pretty concerned about Store manager loosing ability to manage TB, it would a real bad thing. Right that the reason for which I advice everyone to write to Emagicone about how good is the idea to also support TB too, in fact for them should not be hard at all as it is already fully compatible with PS 1.6 and starting from there should not be a problem to collaborate with Thirtybees too so keep their old customers (as an example you did not renew the update period, if they realize that those who will do that are many they have to change their mind) but also get new clients. Also is good to spread around good words for TB, the more are the users the more are the chances to get on well and fine. @ Betty Nutz > I am working on my CSVs and will test soon, I will report what happens Thank you Regards

Hi I am going to use Store manager 2.57.0 with TB 1.1.0, I hope that will work fine I will let you know how the test goes So far as Signut wrote here above that with a previous Store manager version can work on TB 1.1 I imagine should be fine, at least partially. In fact by the way I am worried about the changes done on the database on the TB 1.1 version, surely are not taken in account in Store manager at this point and I have no idea if this is going to cause troubles. My questions is about those extra tables introduced in the DB, can anyone expert predict if Store manager is going to do troubles in this respect? I guess that at Emagicone they said that are not going to support Thirtybees as at that time they could not foresee how much people is going to use it. However of course they might very well change their mind, they do support several e-commerce platforms, they will support also Thirtybees if becomes popular enough, there is no reason why they should not do it in that case. Also would help much to let know Emagicone people that one switched to Thirtybees and ask to support it. I am going to write them about, furthermore I suggest to everyone to do the same, and also to spread a good word around for TB so to help increase the success of this project. Anyone who use TB and have already Prestashop store manager of course have full interest in achieving Emagicone to support it, but I would say also anyone else might like to support the TB success, even if is not going to use such a tool, in fact would be just a good thing to have TB recognized as interesting solution by more well known companies. As usual in this cases could also be good to join the forces and create a collective petition too to Emagicone. Who is going to support this action? Thank you Best regards to everyone R.

Hello Yaniv I also used this module in a old 1.5 prestahop installation, it worked very well as it eliminates that bulky thing the prestashop people thought (practically an automatic obstructor machine as it was originally conceived). I confirm that the AWP module eliminated all the attributes trouble in my old PS shop. I am very encouraged by your comment, is a pretty good info the fact that you already successfully tested it on TB. So far, coincidentally with your reply that I read now, I installed and tested the 1.8 version right today on TB 1.1 using the ST Transformer theme, but I see troubles in the FO To start with to fix this I think I really need to get the latest version 1.8.0.3 (it is the only declared by Presto Changeo to work with TB), secondly I found a bit hard recognize how to exactly modify all the files in the transformer theme. One thing that is a bit complicate when installing this module is to avoid errors adding all those lines in all those files, especially if the theme used if quite different from the default one... I am waiting now to receive the updated version, I will test it as soon as possible, I am pretty confident that should work well, I just hope to succeed to properly modify the transformer theme files. Thank you. Best regards

Hello Petr And Colorful Ant I guess that when the combinations are too much the same happens maybe for the same reason Petr explained for the features. So, for what is concerning the amount of combinations of a product, as too many are going to affect also the speed at which the Front office product page is shown to the potential customer, maybe the only solution is to keep the combinations at minimum necessary. Eventually a workaround is to create another similar product with the other combinations left, maybe adding a link in both the products page to see in each the other similar product with extra combinations (hoping that the potential customer see that link, often clients are very fast in dismissing pages). As far as I know there might be a module that solve the product combination generation trouble, but I am not sure that the FO slow page problem is solved. For the features I do not recall to have seen slow pages in the Front office, the trouble is confined in the BO as far as I know (to be checked tough). Also in the layered navigation system there should be no big problem in th FO, when I had it up with all those features everything seemed to work fine, maybe a bit slow, but, for who understand how much useful is that filter should not be a problem to wait some more seconds to have it ready (that was in prestashop 1.6, but I guess will be the same in TB1.1 if not better) That overall to me means that at the moment, due to the old prestashop architecture in this respect, a TB shop might not contain a great amount of features and/or products with a lot of combinations. Until one build a shop for own use knowing these limits helps to keep it reasonable, eventually the BO trouble is bypassed using some tools alike phpmyadmin, store manager or the like. The situation is different if one is preparing the shop for a client, in that case one have to warn that having a lot of features there might be troubles in the BO and troubles in the FO if products must have a lot of combinations, that is a different and more complicated scenario. It is always hard to explain to a potential client why a solution is good even if it contains special limits, besides that a client might be concerned about the possibility to be able to use the shop in case the need of using lots of features and combinations might arise in a future, (or plain simply need that great amount of features and combinations since start, case for which would be hard to opt for TB). Than you Best regards

Hello Petr Tired of prestashop continuous fails, very annoyed by the fact that a good amount of addons I bought for prestashop did not work out of the box, having lost a great amount of time, patience, money, trust... I ran into a real disillusion and stopped dreaming after prestashop. Prestashop is for me now only a big loss of time. I decided to leave it after I saw how bad is 1.7 version, how they could never ever end any project for good, how much I did not like at all their marketplace, how I do not like also their forum.... and so on. However I recognized the great potential of prestashop up to version 1.6. When I came to know about Thirty Bees I got very interested as in the meantime looking for alternatives sincerely I could not find something that overall is as much interesting. Considering the past experience and knowing how painful can be to have a decent shop this time I elected Thirty Bees and to deploy it I created a couple of TB clones to test in steps, one branch to do new things and a "step behind branch" to check and eventually revert, so I have a certain freedom into going forth and back while building up the platform I need. I can do that too and report, but I need some time, by the way, if Tb was not fixed to avoid that issue, very likely is present in TB 1.0.8 as well. However, if I discover that with TB 1.0.8 I can create all features that I want while in TB 1.1 the limits is a few dozens of features, in general that would be a very strong limitation either ways. So this test can be done for curiosity I guess, but discovering that version 1.0.8 is not affected won't solve anything for the users as would make little sense to get stuck into the 1.0.8 version. Tjis issue is nothing that causes a "no no" answer to the question "would you use thirty bees?", but, still, that kind of limit leads one to say for good in a bit emphatic way "for a big complex shop there might be troubles in certain circumstances". I think that statement in various extents is true with any platform, but surely it can have a different weight, for instance a big one if the possible circumstances are many and maybe due to some apparently minor things, alike a major page in BO using a script that gets clogged, busy and not responding. Products can be handled via database eventually using some very efficient tools, but, the point is that in the BO for obvious reasons everything must work well. Even if the problem can be circumvented and avoided with external/third party means, in general, having such a limit in the BO is not good at all for several reasons, licenses costs, clients needs, clients preferences, employees not having access to special tools but maybe needing to apply few changes on the fly and so on, there are many possible examples... One example is my own experience with this issue, I resume here what happened and what will likely happen: I hit this trouble not knowing why except remembering that happened already in prestashop sometimes, consequently did a search to guess what can be, wrote a post here and continued to investigate, got an idea about it and finally saw that is an old prestashop issue due to excessive product features, but also and/or maybe categories and/or attributes, so I reverted, clarified that in my case is the amount of product features, had to reason on it, wrote updates to the post here, now I am deciding to add again little groups of products features in steps to try to guess then which is the limit to not see issue again, after all that, if everything goes fine, knowing the eventual limit I will have to decide how the shop must be pruned to not have the problem.... I do not like the idea to have to guess a limit in order to prune the shop... is not good. However this is just what I will do as I am unable to solve the problem except try to see if anything good happen with some changes that are suggested or that I can random find on other posts with more extensive searches on internet That is surely not the convenient and desired workflow I would like to have, but very probably nobody would like to have such an adventure... This trouble as far as I understood is inherited from prestashop, in that post on github I linked ( https://github.com/PrestaShop/PrestaShop/issues/9809 ) presta people admit it and in many occasions apologize to persons writing heavy complaints about this issue, mainly spotting out how it is a strong limit impeding having things right in a growing shop or anyway a big shop (as I read because they feel alike being ignored, a feeling that in general is not hard to recognize in the prestashop thing) While developing any project being continuously stopped by some little stones in the shoe is really not nice, especially if one find no easy way to remove it... In general one want to just go on and publish at least having the basic things well done right, the rest can be done later on. As anyone can imagine even working onto a perfect bug free platform there is a lot of work to be done to have a working shop. My greatest wish giving trust to the TB project is to become able to concentrate much on that commercial part and not have all kind of technical problems meanwhile I do work on selling products. That in the latter sentence might be a reasonable goal also for developers of an any business software platform as when micro and small business find a lot of difficulties to start or to grow a HUGE amount of potential future customers are cut out of the game while the few notorious big and monster giant companies gather everything at faster speed. This is not a critic, I just wanted to describe what/how it all happens and why things alike these can be very frustrating. That said while I try to fix my thing here, within my limits, I am very keen on helping, ask me anything and I'll contribute as a final user tester as much as I can. Thank you for the help Best regards Ray

Hi Petr I remember to have read about the smarty engine version change, due to my ignorance I did not get immediately that this is the culprit for those minor changes now necessary in the third parties themes, or simply I forgot about that right after reading it, but I kept as true in my mind that changes were necessary. Thanks to your precise explanation written in perfect divulgation language style I now I fully understood the whole case. I am very happy of the work done by the Thirty Bees team, according to me as a final user is very good and reasonably I am pretty keen on accepting changes when really needed, we must be very reasonable in this respect. Thank you. Best regards Ray

yes, I got it, I will try that, thank you However, as far as I understand, maybe that modification is going to avoid the long response and the error message, I do not know if it is the only trouble... however, I will test it and report. Variants... you mean product attributes? Yes I have many and maybe will add more in future, is very useful function to avoid a lot of product pages and/or avoid confusion to clients and search engines. However at this stage I am testing with the sample products present at installation time, so a few combinations are in use.

Alright, yes, I got it, it should be that way, logically retro compatibility should be maintained. I do not know if this is a strict guideline in the TB roadmap and constitution, as I hope it is, in fact I feared that event of retro compatibility breach and it happened, that was not good to be seen. However, I can understand that some changes might be unavoidable at times and some exception might be justified if the advantages obtained are really important and great. Overall I truly hope that is possible to strongly enhance the system without throwing in the trash the whole addons/themes catalogue, would make no sense at all and would reproduce the Prestahop 1.7 "disaster". Now, as not expert, I am not capable to discern if in this case this incompatibility is due to just something missing/erroneous in TB 1.1 or because any major change imposed to break something, from what you wrote I understand now that this is very simply some error or missing thing in the TB 1.1. All what I understand of this is a derivation of what I can read here in this forum and other sources, + my non expert reasoning, reading that "a new version of panda, compatible with TB, will be released... " lead me to think that in TB 1.1 there are some unavoidable changes, if that is not the case, well, I stress on the concept of retro compatibility. I am here because I found the prestashop policy a total failure (almost an insult to everyone, developers and end users). I do not like that kind of scissor used in such not careful, senseless and lousy way in a development line (especially if the result is a tasteless buggy sort of soup alike just as prestashop 1.7 looked to be to me...) Either ways, I hope that in future this is not going to be a problem, retro compatibility is too important to avoid serious troubles.

Hello Occam The action and consequent error that comes out exactly is this one: 1) I click on Catalog menu and open the Product list tab, there I click on a listed product edit button to edit it 2) the product edit page is loaded, but is soon halted, I cannot navigate in it, after some more seconds (10 or alike) the progress spinner goes on again and is possible to scroll the page, this already take alike 20 seconds or more, however the page at this stage, still, is unusable. 3) After some other 10 to 20 seconds a popup error message appear telling exactly the message I posted: jquery-1.11.0.min.js:3 script busy or not responding This popup error message allow to "Stop the script" or "Continue", if one stop the script cannot use the page, of course it becomes useless, if one click "Continue" the script is further processed, so after more dozens of second finally the page becomes fully available. If the debugger (in firefox) is opened, that same message allow a third option, "Debug the script", if that one is chosen a lot of info comes out, however I am unable to interpreter it correctly. By the way I have seen that there are quite some warnings about CSS problems, a couple of scripts in which the character encoding is not declared so if used out the frame in which are inserted might show odd stuff, and more stuff, I can post it all if useful... However, as I am not expert, I am not sure to have searched well in the debugger in order to get the most relevant info for this specific problem, I have the feeling that I saw quite many errors and warnings that might be unrelated. If you can suggest me what to exactly do with the debugger I can reproduce again the problem and post a full report. Thank you

I am sure that Transformer and Panda can become fully compatible with TB 1.1, however as we saw a few fixes are still necessary, would be very nice of Sunnytoo to fix it all and include it in their releases for both themes (I guess that they are going to do it hopefully). I am testing ST Transformer under PHP 7.1, TB 1.1, it works fine apparently, but still I did not test many features, alike layered search, combinations, specific price reductions, bundles and so on. In fact after adding a lot of features , lots of attributes, some suppliers and manufacturers, wanting to begin to test related products, combinations, specific prices, and layered navigation I got stuck because of a Jquery problem, I opened a post for that: I am going to revert step by step hoping to find what where the changes that lead to it. Btw, this halted my tests, I am not keen on waiting minutes each time I attempt to edit a product and in general to ignore this issue, need to have it fixed and understand what causes it. Because of that I still have to see if everything else works fine with Transformer (and would really like to, I am a bit in a hurry to publish the new website).