Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.


  • Content Count

  • Joined

  • Last visited

  • Days Won


Raymond last won the day on September 7 2019

Raymond had the most liked content!

Community Reputation

4 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. 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
  4. Hello Everyone I was curious to know at which point is the development of the new version, any news about? Thank you Best regards
  5. 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
  6. 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
  7. 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.
  8. 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
  9. 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.
  10. 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 (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
  11. 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
  12. 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
  13. 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
  14. 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.
  15. 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.
  • Create New...