hubbobubbo

I downloaded the Upgrade module from github and had some minor issues installing it. The error message was not 100% clear but basically it came down to that having a name of the zipfile such as tbupdater-x.y.z.zip was not liked by Prestashop. However the culprit was that the folder was still created and that caused additional confusion. I had to unzip the tbupdater-x.y.z.zip rename the folder to just tbupdater and the recompress it again so the folder name did not include the - and the version. Then the module installed ok. Maybe not using the version tag in the folder name for the github zip could save some time for the next guy downloading the module.

Update: I removed the second offending function from geoip.inc and now the site loads. It has a bunch of warning like: Notice: Constant GEOIPREGIONEDITION_REV0 already defined in /var/www/vhosts/myhost.com/update.mysite.com/vendor/geoip/geoip/src/geoip.inc on line 35 which seems exactly like this old issue: http://forge.prestashop.com/browse/PSCFV-4190 Could it be that these functions and defines are used somewhere else as well and now they are seen as duplicates? I will continue to troubleshoot but if anyone already has ideas please share.

I understood the comment. However I do not think that is the problem. It should be possible to complete the migration. In the system logs I see a lot of this print: [Sun Aug 20 16:41:50.205393 2017] [proxyfcgi:error] [pid 15580] [client 91.126.108.173:62651] AH01071: Got error 'PHP message: PHP Fatal error: Cannot redeclare geoipcountrycodeby_name() in /var/www/vhosts/myhost.com/update.myshop.com/vendor/geoip/geoip/src/geoip.inc on line 1602\n' and now I found lout how to enable PHP error reporting in Plesk as well and the same error shows instead of just a 500. I think this is where to start. So I looked at vendor/geoip/geoip/src/geoip.inc and indeed geoipcountrycodebyname is declared twice. My problem to get to the next step is that even if I have removed the duplicate function, I still have the same error. I have caching disabled in Plesk but it seems there is something cached by ThirtyBees since now the function is not duplicated but I still have the error. Can anyone advice what might be the issue? Anything I can do to enforce that this change to geoip.inc is detected. It seems like it is still using the old version of the file.

When starting the migration I choose to disable all overrides and non default modules.

I doubt doing a full manual migration is a viable option for many merchants. I just did an auto update from 1.5.x to 1.6.1.2 without any problems and I have almost no additional modules installed. Somewhere there is probably a logfile or information on how to resolve this so others can have a smoother process. I am happy to troubleshoot but I will need assistance on what to do.

Ok, so I ran the migration module and it reached the End of Process step. I did not check the complete log but it seemed like it terminated ok. Now however both frontoffice and backoffice just answers HTTP error 500. Any suggestions :-)

Ok, no problem at all. But either way I should be fine migrating to 1.0.1 and then updating or is it still recommended to wait for the 1.0.3 support directly in the migration module?

@yaniv14 I noticed 1.0.3 is now released but the migration module still says it will install 1.0.1. Is the recomended way still to migrate to 1.0.1 and then update or should it be possible to migrate directly to the latest stable release?

Hi I am trying the demo store and while backoffice is configured to 1 step checkout, the front office is still running 5 step. Are they not connected?

@lesley would be awesome to get microdata in the mails so our Prestashop emails have tags like tracking link etc directly in gmail. Looking forward to that feature going into the core templates.

Cool, I will wait for 1.3 then. Thanks

I am about to press the button but my newly installed migration module says it is going to install 1.0.1. It should say 1.0.2 by now right?

The same thing happened to me as well. Enabling file system caching and then turning it off again got me through the problem. Maybe something that can be improved in the future since it is very confusing to get an APC error when the caching is disable. The reason I assume is that even though caching is off, the mode selected is still APC by default so it seems as somehow the setting for cache on/off is not respected when configuring the migration module.

Excellent. Looking forward to testing more. Maybe cron job support for the cache warmup/refresh could make it into the future roadmap :-)

So, in order to completely close my initial question. Lesley, what you are saying is that functionality similar to ExpressCache or jpresta modules is an integrated part of ThirtyBees. Just like @DavidP my experience from ExpressCache is that it provides a notable improvement in user experience because of the pre-caching so I am really interested in testing that with TB as well. My initial question actually come from the 1 sec response time on the demo site which surprised me if this kind of caching was enabled but perhaps it is because I run my test from Europe and your page is in the US and Google uses a European test server or something. I will let you know once I have thirty bees installed. Thanks again

Thanks Lesley, very informative article. When I have a little time I will setup a TB clone on my server so I can do a fair compare using Lighthouse under the same conditions.

Hi Lesley Thanks for the detailed feedback. I was not familiar with Lighthouse and indeed it shows the numbers in a different way. I will spend some time looking at the results to see what I can learn. Thanks for all your efforts on TB, I do look forward to migrating.

Sorry, maybe I was not super clear. I am just putting your front office demo through Google Page Speed. I have not installed it on my hosting or anything. I just compared the metrics with the demo here to what I have today and the demo server response time was significantly slower that my current installation that is currently not using any external caching plugin. However as I mentioned, if I enable the ExpressCache module, my shop has a server response time of around 100 msec while the TB demo is at over 1 sec and you previously indicated that you are using a caching module that should be faster than Express Cache. So to summarize: - My shop on Prestashop 1.5.4.1, no caching module. Server normally responds in around 300->700 msec and I have a lot more things on my page than the TB demo. I am running on a cheap shared hosting. - My shop using the Express cache plugin has a server response time of less than 100 msec (I had some issues with the module so I can not run it live yet). - https://front.thirtybees.com/ shows server response times around 1 sec and the index page is very lightweight compared to many Live shops. I am just pointing this out since speed would be one of my main incentives to migrate and I was having high hopes for an embedded caching module that works out of the box and could produce as impressive results as for instance ExpressCache. Happy to help with anything I can contribute with in terms of testing or feedback.

My 1.5.4.1 theme uses bootstrap and it is responsive. Don't you think 1.1 sec is a very long load time?

Hi I use a module called Pretty URL from BVK Software, I think it is quite common. Did anyone run any tests to confirm that the rewriting in ThirtyBees produces the same results? Otherwise I think Google would freak out completely :-) I have not tried to run a test installation myself yet but I did notice that the SEO settings for products in my Prestashop installation said: {id}-{rewrite} while in TB it says: {categories:/}{rewrite}-{id}.html I assume {categories} could be removed but then {rewrite}-{id} is in the reversed order and you also have .html at the end but for the products in the front office demo, .html is not part of the url (the way I want to have it as well). I think it is great that the url rewriting is finally integrated but since not breaking the existing link structure is mandatory it would be very interesting to know that the url schema can be flexibly configured so when migrating my links will remain the same.

Hi From what I understand tb has integrated caching support. However when running a test on the Front office demo with Google Page Speed insights the server response time is 1.1 seconds. My 1.5 installation on a shared hosting is 4-5 times faster than that and when testing a caching module in the past I had around 150 msec response time on a standard shared hosting. Does this mean that caching is not enabled by default or still in development?