Jump to content
thirty bees forum

Pedalman

Silver member
  • Posts

    435
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Pedalman

  1. Update: Firefox Quantum and an extension (LastPass) seem to be partly responsible for the delays. After editing the files above in order to stop the Gstatic/Gmaps ... calls all seems to be pretty fast with Chrome! That is really weird but now I can work again in BO without building up frustration :) PS: still a problem with ganalytics in BO: https://i.imgur.com/vOom7ss.png
  2. Another guess would be to check whether APC is active and to deactivate it. I am hosted at Hetzner Europe but with APC activated in the console of Hetzner and in ThirtyBees as caching method (for page prerender cache) I have irregular problems that are similar to the one you describe. Perhaps deactivate it, make your changes and see if all is fine. Let it run that way a time and perhaps go back to APC. Just a thought, I am no expert only a troubled shop runner.
  3. Well, I have to pick up my complain and question again. I upgraded to 1.0.4 latest repo in the meantime in order to exclude any issues or old bugs with the bo controller etc. But the backoffice orders page still hangs about 5 seconds due to loading google maps ? I have entered an API code in bo for gmaps but this does not help. This is more than annoying and really makes no fun to work in Thirtybees BO. This behaviour started in January so I still believe this is due to some Google servers but I also still believe a free Prestashop for should give us the option to use GoogleMaps/GoogleFonts etc. in Backoffice and elsewhere! But in I am willing to calm down :) and want to ask other European users if they notice or do not notice this delay in bo/orders ? This would be very helpful.
  4. Okay, I see that the tag 1.0.3 dates back to 18th August 2017... So, all committments later than that are part of upcoming 1.0.4. What isn't optimal now for me is that I believe that there are fixes and also improvements that might be related to 1.0.3, too. You know what I mean, everybody wants a flawless and fast as possible core. For me as normal shop runner it is now difficult to stay tuned :) E.g. I have issues with productcomments module. If there are newer committments how do I know if they only work with 1.0.4? What about e.b. latest PayPal module? It is out for months and meant to fix known issues with V5.x. But V6 is still beta or does only work with 1.0.4? So confusing for me that I think best is not be concernced with all that anymore.
  5. Wow, thank you datakick. That was more information than I can dig at the moment but I get a good understanding of the complexity and how I might have to procede. Perhaps I can retrace your examplatory steps in Sourcetree but I see that the need has gone and I am best to wait for stable 1.4. Thanks alot
  6. Hi. I know about that one. Anyhow, my question was not about how to upgrade to 1.0.4 but how to maintain a running 1.0.3 best. The normal shop runner would just wait until the ecommerce system tells him that there are core updated or module updates and would update. That is what I would do too, since I am no expert in all things. BUT I on GIT you see that there are dozens of fixes related to 1.0.3. I am asking what the best method is to get 1.0.3 up to date. Do I have to monitor the GIT and then download each fix --> I <--- might concern important? I think that could certainly cause more problems than solve. Should I download the repo zip (that is also linked in your cited tutorial) and copy it over my 'older' files?...
  7. Hello on GIT we can find the stable TB 1.0.3 and the ReleaseCanditate in development. The latest takes the most horse power/developer ressources I assume but there were of course also some fixes to the TB1.0.3 I have downloaded and installed in OCT2017 or so. How can I make sure I have all these fixes running on my livesystem? I guess I need to monitor the GIT repo. So I installed Sourcetree and cloned the TB repo. Anyway, I need to know how I can make sure that 1.0.3 and 1.0.4 or what ever do not get mixed up when I download... Can some be so nice to take some time to explain this to be in words or screenshot with whatever GIT client he uses (except bash :D). PS: I just stumbled in BO over system information and saw that there are three files listed that are supposed to be different from the source (which ever version (date) is meant and referred to here). Two I could reconize since I changed contend(edited them. But one I did not. The ContactController.php. So I did a file comparisson with the ContactController.php online and the one of the 1.0.3 I once downloaded. Well, they differ very much. => So, in a nutshell, I just want to make sure my V1.0.3 is up to date and I do not post issues and problems in the forum that might be already fixed a long time ago.
  8. Ah, I misunderstood the term RC. Sometimes difficult to stay on track when there is information on the blog, forum, wiki and git... So, I will wait until there is an official release and press thumbs.
  9. Sorry for having doubts about 1.0.4 :) but I am a bit curious why I can not find any bug reportings or issues with 1.0.4 (after upgrading from 1.0.3). I read about adapting themes to the new RC for example but no more. I use the IQIT Warehouse theme and wonder if I have to add 1 1 1 to the theme's xml. And I would normally expect several more issues but all looks to be fine judging from this forum. Do I need to check GIT TB repository issues, too? Or is 1.0.4 still not recommended for a productuve site?
  10. Can this be related to a slow loading BO/orders page? It takes about 7 secs to load and the Ajax circle is spinning. Very annoying. I already posted related to this but to no avail so I wonder that GA Optimized might be the reason? Anyway, after deactivating the module the hickups were not much better. Browser tools name Google related stuff but I have no clue that all: And btw what does "UserID tracking" mean? Thefunction of the module is not very clear to me. Sorry
  11. Today I was in need to give a customer a refund. I clicked in bo orders the related button and Ajax jumped to a certain point downwards on the viewport as usual but the form did not change in order to make a (partial) refund. Well,... what could I do to get things working again? I already flushed cash and and let it running with recompile on for a certain time but to no avail.
  12. I see. I did not know that it would be that complex and time consuming. So, yes it is better development time is used on the really important improvements and enhancements.
  13. Mh I never learned how to programm so I had a look at the Terms&Conditions check during checkout and tried to edit the controller in question - but without luck :) if ($this->tabAccess['edit'] == 1 && $this->display == 'view' && isset($checkedMAP) && $checkedMAP checked=='checked' ) That was meant to be the first step. The second would be to have a button that sets checkedMAP. Anyhow syntax is wrong and all what I could do was to set the display condition to something else that does not exist... if ($this->tabAccess['edit'] == 1 && $this->display == 'view2'
  14. Actually, in order to satisfy both types of shop owners - the ones who care about Google connections and those who do not - best would be to have an "on demand" look up Google Map adress button. I think this goes with Thirty Bees concept and should be build in. Thank you alot
  15. Thank you Datakick for the hint with the file. I do not see any reason at the moment to tell Google who I am shipping to. Moreover, this adress validation is done by my delivery service... Any tips on the 404 Error?
  16. 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
  17. 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.
  18. 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?
  19. 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.
  20. 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.
  21. 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.
  22. Mh, had I read that before I would have saved some time. Thanks guys.
  23. 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.
  24. 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
  25. 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
×
×
  • Create New...