Pedalman

Hello the orders page in the back office is loading too slow. Sometimes this is not the case but since days I notice an annoying delay. So, I assumed that there are some scripts running that have difficulties to to run or are slowing down the order pages and I started network traffic analysis in the browser tools. I have no real clue how to use these browser tools but I see that there is a 404 (Ganalytics ?) and a https://maps.googleapis.com/maps/api/js/QuotaService.RecordEvent?1 .... ? Mh, reading "reacorded event" gives me a goose neck :) but anyhow I would really appreciate if TB would give us an option to use Gmaps service or not. => I vote for a TB exclusive tab in future ThirtyBees version with options like this that might increase priovacy a bit more. Until then, I would like to ask where I can block the Gmaps call (edit file) and what causes the 404. Thank you

Migration of existing reviews / data is very important I think. And I do not think only about PS1.6 reviews but also other review systems like Yotpo, Ekomi, TrustedShops whatever. Any trustworthy external review provider^^ should offer an export option of customer reviews a shop has gathered. I am not to much into this but I think at least there should always be the email. May be name and product ID, cart ID, date also? The more data the better since a nice import function could allow to map these data to data stored in the shops DB, right? I have never heard of such an import function but it should be not too complicated, or? If possible we could quit all these external review providers and run exclusively ThirtyBees with an exclusive review system and do not loose any reviews we have already.

Ehm, you are talking about this one: https://addons.prestashop.com/en/customer-reviews/17896-store-reviews-product-reviews-google-rich-snippets.html ?` you once have to make a connection to the author of the module to get your product_comments migrated and then you can run it on your own without script connecting to their server?

Hello I was one of the first users of rockPOS. I even got a nice postcard from the dev out of the Vietnamese ? jungle :) All I can says there were very helpful then. Some years ago the moved away from Codecanyon and lost my "invoice" ... So, I cannot say if the same team is on board but first I would try with them.

I have both changed files and translations. What I knew about the error before was that when it occured it occured on all occasions where AUEC hooked into price display. In this case it was not so. I would have noticed it earlier. That is the reason why I pointed it out, especially since I noticed it the first time when using a mobile device. I thought that there was not only the chance that I had missed conversions for weeks but also other shop runners. But there comes something more to my mind since I have another thread open about APC not working. There I switched for testing purpose from APC to "File System" and suddenly the APC module showed me that it is working?! And yes I doubled checked everything. Then I went back and reactivated APC again! And the APC dashboard shows hits/misses until today. Something it did not for the time I am running TB (8 weeks?). This I could not explain. Anyhow, I was and am happy since I had the cunsumption that myy Host hadn't activated APC on shared hosting despite showing the PHP configuration in their 'console'. So, I could now think that switching APC in TB on/OFF or via switching to "FileSystem" cache and back somehow APC was triggered and started working. A lot of somehows's, thinking, assumptions... and that is something I do not like to post on a forum since it is very hard or impossible for others to retest. But it may be that due to APC working now SmartyCache stopped working?! But perhaps there is abolutely no interaction cor correlation. Fact is I could reproduce the error now (via waiting, as you wrote correctly, since it sometimes appeared and sometimes not - twice I could reproduce it via doing a search on the shop's frontend on a mobile device - which is propably irrelevant) and it seems to be all ok now with APC ON & Smarty OFF. PS: And shame on me I did not know there is a German subforum here. Though I thought this might relate to all.

The whole day I could not reproduce this error. I did not dare to post since I was sure I did correct testing yesterday. Now, ca. 20 hours later the error appears on my desktop! I am using latest Firefox. I could see it on a subcategory. Funny thing is I just went to the mobile device and noticed that there all was ok?! I am giving up here since this is far beyond my understanding. FYI in order to reproduce the error I had today of course Smarty Caching ON (with no recompilation) and APC caching with Page Rendering. Only setting Smarty Cache OFF and clearing the cache in TB/performance made the price fields (AEUC) look normal again. Bottom line. I am sure it is linked to AEUC. Why it could appear on my PC and not on the mobile smartphone this time is a mystery to me. I also know how to bipass this error by using {no smarty cache} tag in AUEC file. Also notable is that it did never appear on homepage.

Mh, had I read that before I would have saved some time. Thanks guys.

Nine dayz before Xmas I become aware that mobile users were not able to use our shop :( :( :( I always tested mobile UX via browser dev tools. Had I used a real smartphone/mobile earlier I would have made thousands more income (Ganalytic told me that 60% are mobile users but that there was an issue with conversions) since I might! have become aware of the smarty error thrown at my customers. The problem is that product pages are 'destroyed' by listing enmasse of smarty errors. I assume due to experience that this is linked to the AEUC module. I noticed that when you do a search on the shop (running Warehouse theme and TB1.3), results have these "smarty caching" errors. Also if you browse products via the modules "other customers bought also" and "other a. from manufacturer". Perhaps there are other ways to render this error. I was happy that the homepage worked with TB's smarty caching active and the AEUC module. Especially since I knew there were more or less unsolved problemd for at least since 2015 I guess :( with Prestashop 1.6.x and the AEUC module (for me the best prove how much Presta devs cared for shop runners. I had the strong impression they cared more for there so called GOLD and Silver agencies and for the same reason for Presta V1.7 - the golden agencies doing the migration and adaption of modules already paid by Presta 1.6 users). Back to topic: I had never the idea that other parts of the shop system might be effected by this smarty caching flaw. The only solution for now is (at least for me) to deactive smarty caching in TB if AEUC is used. Therefore I urgently suggest to clone techniques form Presta 1.7 concering the interplay with this module (I am told that PS 1.7 works with AEUC finally due to some other integration of it), or to enhance the module so it is compatible with modules/search and other unknown parts than the homepage or to really warn European users of this glitch since we are shop runners who depend on a mobile conversions. PS: I was also told many time though I could not understand it that the "smarty caching" would only work on the homepage. Anyhow I learned today that this seems not to be the case.

Mhh I switched advanced php caching methof from APC to "filesystem" in TB and let the php setting remain in host Hetzner's console as shown in the screenshot. Then suddenly APC modules' dashboard shows hits & misses?! I can swear that I tested the APC dashboard as explained by Lesley and bzndk. And did this several times before that and it never seemed to work. Funny is that after switching back in TB to APC caching method the dashboard seemed to on. ! google page speed test jumped from ca. 60 to 89! AND yes I doubled checked settings before. And it does not play a role for Google's page speed if I use filesystem or APC as PHP caching method?! I thing TB need to have a compatibility check for caching method build it (even if is just a link to Google's page speed form or what ever). I do not get it and very much hope that things are set more or likely fine now. PS: OPcache module show 404 even after reset

Hello I just became aware that the pages of our manufacturers rank very very very bad in comparrison to other sites who are by no means really sites you would say, wow, they must have a superb seo agency and lots of ressources. So, I had a look at our manufacturers' sites. As you now you get to them via calling the tpl that lists all manufacuters and their description. So, yes, here you can seotize:second_place: But if you call the link there that says "Coca&Cola has 3 products" in shop or similar then you come to the page I mean. All products of one manufacturer. This site is actually in our case the list of all products of the supplier. Is this correct and meant to be so? PS: TB1.3 and Warehouse theme

APC in TB performance settings is ON Page Rendering is ON but no cache hits/misses or anything in modules dashboard

Hello in the hope to benefit from caching I have APC activated on my hosts console (shared hosting at Hetzner) since it is avaible. I also have it on in TB's setting and page rendering is on with default settings. All seems to be fine as far as I can see and say. But I also installed the APC helper module so to speak and get the information that there is no chaching. Two things come to my minde. Either my configuration is set wrong since I do not know what I am doing or my shop is abosutly not stessed since I have too less customers at a time online and Hetzner has ressource in abundance for my shop (and the others on the shared host). Xmas time or not :) and the php config:

Update for community. I am still in the process of observing the issue. I think tomorrow I will know for sure and edit this post.

from folder: www_logs I guess you meant not. Then there is on the console of Hetzner a link called "Error Logs". I had alook at it and saw nothing interesing besides something that makes me curious. I am going to send you chat via chat :airplane:

Only this log but that may be cause I pushed the button twice since there was no feedback: 5 -- 1 Frontcontroller::init - Cart cannot be loaded or an order has already been placed using this cart Cart 13953 0x 0 12.12.2017 17:42:26 Server logs? Okay, take a sec longer. I hope I find the rights ones (HEtzner shared hosting)

Hello Lesley, just a minute ago I had to make an BO order for a customer. I choose bankwire as payment option and the status "waiting for payment". Guess what? ==> not status set in new order ... I am taking a look at BO logs

Problem continues. I have not done a thing the last days concerning modules or updates or anything BO related and out of a sudden PayPal and Bankwire module stopped setting the status "payment received". This is very annoying since customers are getting confused and it is Xmas sale.

UPDATE Today also the bankwire module did not set any status anymore in BO. I did not notice this early in the morning and was fixed only on PayPal module. Sorry for that. So, this is not PayPal module reltated but something else I assume. Propably the server Hetzner and/or caching in TB? Of course the PS quetions/request are still valid.

Hello Earlier only 1-3% percent off all PayPal orders had a mismatch between the status in PayPal' gui itsself and TB's. To the point, in TB there is no status set at all. Now, in the last 24hrs this phenomena increased drastically. Assumption is that there could be a connection between this and hightened stress on PayPal's servers due to Xmas sales or slowed down internet in general (backbone being attacked by... I won't speak it out ;) Anyhow, since I do not know how successfull PayPal beta is running or if other stores run it at all at the moment we use the stable V5.3.2.  and PS: Best would be if I knew that switching to PayPal V6. beta is safe. Else since V5.x does not use webhools I wonder if the time windows in which the module accepts a return of PayPal server is to tight? PSS: We need a form to customize the "custom shop" logo that is display in PP Express. As it seems to me this is loaded directly from DB but in our case this does not look nice since of resolution issues. Moreover a custom "return after success page" could be also handy since I plan to hook some custom info like newsletter and shop/article review ads. Thanks alot for looking into. cheers Boris

Hi Raptor, I agree with your points. And by chance, I had altered the issue with the button at bottom myself. I use an product export/listing module that list all! products in csv style and at the very bottom there you will find the "action" button (to regenerate the list).... Very annoying and something that made me think.... I am no coder. I am very sorry about that and I would really like to learn (vote for video tutorial section here on TB. Looking live over Lesley's and Michael's shoulder. ;) But I think I am an UX guy if there is something like that :) Anyhow, I hit the "inspect" button (F12) in my browser and looked for the CSS of the button. Found it and made a text-search for the more or less unique CSS in the modules folder and found nothing. Then I searched the admin theme folder and voila. Module's css is based on admin theme. So, coming back to your request. I just edited the tpl in question (actually I only copied the button code that was wrapped in a DIV at the top where I needed it)... Perhaps you can do that too. More on UX BO improvements: I would like to have the option to "live" arrange the sections in /bo/orders. Changing the responsive width and height and position in an order the shop owner/user likes. I think this is something that is overdue and needs to be added to TB as Prestashop alike.

Me, too. And now I am off to my bathtub :) - exhausting xmas business

Hello I just bought module for image optimization via Kraken on www.presteamshop.com. When logging in / creating the account I noticed the nice AdressValidation / Prediction powered by Google. I wonder if someone has experiences with this. If it slows down the "general" shop due to JS calls or other nasty sideeffects. Any moreover, the most interesting is of course if some one uses it if it really works. I just found a Prestashop module that seems to do the job and I think it should work with TB, too, of course.wondwer

I can imagine that and will make some time a request for that. But I am a fan and strong believer in Thirty Bees cause it is the first time in half a decade of ecommerce that I got the feeling that one of the main concepts of the shop system is to get rid of errors/issues and bugs. So, before posting anymore fearure requests I want to give the developers the time to build a strong basis. I like to cite Michael Dekker here who constantly focuses on coding standards. An altered citation of a now famous German politician could be: "it is better not to code than to code with flawls". So, first TB project itsself and we shop owners should focus on a flawless ecommerce basis. And TB is best I know of :)

Remember please that in TB's backoffice the order was listed with final sum: 108 EUR and no delivery fee PS: I went to the DB to get rid of this for now though it is a dirty solution. So I am voting for an OrderEdit function in TB.

This mistranslation seems to be related to a wrong assignment of delivery tax and process fee on PayPal's side. I could dig that the process fee listed at PayPal is excatly the tax fee on the delivery service sum: 19% from 22EUR = 4,18 EUR ! but this tax is already included in 22EUR due to TB BO settings for delivery service! So, I assume API is lost... Please check two screenshots: Close scrutiny to delivery tax. In Germany it is 19% included. https://i.imgur.com/oNVsXyj.png This is PayPal in German :) sorry for that but notice "Versandkosten = delivery fee" & "Bearbeitungskosten = process fee"