hubbobubbo

Perfect, yeah, retina images would be a must. Will check out your thread.

Cool, thanks. I am planning a migration as well and I am unsure if starting from the default or a paid theme is the best way to go. I really do not need a lot of fuzz, prefer simplicity so maybe tuning the default theme is a good option. If you have any lessons learned to shared from that work it would be super interesting to know. Something that caused you issues, or was easier than anticipated.

Nice shop, well done. Which theme did you use as base?

@MockoB I share your concern about this. Having a strong base theme to work from if/when moving to TB is the most important thing for me and missing core features such as lazy loading, infinite scroll, (retina?) is very concerning.

Wow, was not aware of that module. It looks really promising. If anyone has experience using it with a TB migration it would be very interesting to know. Another thought, is there any advantage potentially lost when not using the update module? The only exception that comes to mind in my case is really the data from the review module that I do not know how to migratate but apart from that, I see no reason to use an update module over this migration tool. Am I missing something obvious?

I am returning to investigating TB after putting it on hold for some time. The thing that caused me to give up was that while a clean install performed well, the migration caused me loads of issues. Even though I did manage to get the shop almost running, I had problems with urls that I could not reproduce with a clean installation (my PrettyUrl module with overrides was nuked already). So, my question is similar to what other have been experimenting with: Would it be possible to have a migration module that only focuses on an export-import of Products, Orders, Categories etc in order to carry over all relevant information from an existing shop into a fresh TB installation (not a migration). I am aware I would have modules that has stored data in the DB that I may loose bu in my case, the main non default tables are from the review module and I guess I could figure out how to port them manually if I get all the standard Prestashop stuff migrated. I have no clue on the feasibility of this but reading other posts from @mdekker etc it seems as exporting-importing csv files is something you frequently do. So, is this something that could work? Supporting a TB migration not through update but from a 100% fresh install and ONLY migrating standard Prestashop tables using export-import? I just have a gut feeling that would give me 95% of my shop functionality up and running with a TB installation that is guaranteed to not contain any junk in the db, old overrides, deprecated module not fully uninstalled etc. My shop is not complex afaik but it still has a 4 year legacy that I assume can cause all sorts of issues. A fresh installation just sounds so nice :-)

I had one concerned on this topic. Having infinite scroll on category pages is a feature I would really like to have but have been struggling to find a good solution for in the past. I noticed that while the 1.7 compatible version of the Transformer theme includes infinite scroll, it seems as the 1.6 and TB compatible 3.x version does not. I am concerned that the 1.6 compatible version of these themes since branched out from an older release will be less feature rich than the 4.x series targeting Prestashop 1.7. wdyt?

I had the issue still in 1.0.3. My hosting is a shared one so I guess they have some basic packages which are available to all users whether you want it or not :-)

@bznk Well, I had to comment out the offending code but the experience was not good. I mean, I have some development experience so I could smoke it out myself but others finding themselves with a 500 error after installing TB might just give up. Also, I think the next update of TB might overwrite my patch so each update could potentially cause problems.

I faced the same challenges a couple of weeks back. Still cheering for an official solution for this since also my hosting provider refuses to touch geoip on the server.

Hi One irritating thing with Prestashop is that once you set an order to preparation in progress you can not modify it. It happens quite frequently that customers make last minute changes and it is a mess if the order has already moved to Preparation in Progress state. This thread explains the problem as well: https://www.prestashop.com/forums/topic/299590-cannot-edit-or-delete-product-from-order/ I just patched the database in my 1.5 installation as per the link above and it seems to work ok just changing in the psorderstate setting delivery to 0 for the preparation in progress state. It seems however from other posters that it might work differently in 1.6 (I did not test). I think it would be great if TB did this in a more flexible way out of the box, allowing you to edit the order until it is actually set as shipped.

My two cents: - Guest checkout has little to no use at least in our case. It only caused confusion, less options better. - Key is to keep checkout page as simple as possible and mobile first. - Checkout coolstuff.com for another shop I think has a great and straight forward approach for the opc. - Gift wrapping is something that was never implemented in a good way in Prestashop. Our shops focus is partially gifts but we had to deactivate the gift wrapping option since it has never been possible to choose gift wrapping per product, only per order which is completely useless. Having a gift wrapping option that actually works at some point would be accomplishing something Prestashop has failed to do for years. - As for the actual registration. Having integrated Google and Facebook login would be a huge plus. Like Airbnb and the other large sites implement it.

Cool, please put a note here once that is ready and I will make a clean migration again to check that it works with my hosting. Thanks for the help

Ah, I just found the "Disable all non thirty Bees modules" under Performance.

@zimmer-media Sorry for not being clear. It was when installing tbupdater from a TB installation (I had already migrated to 1.0.1 and wanted to update to 1.0.3)

Then I guess it would have to be solved in the application side. This is really not a big deal, I am marking as solved and leaving it as a reference if someone else has the same problem in the future.

Hi I just got the community theme running but I have some getting started issues: The first one is that none of my modules are visible. I have some pretty simple ones like a footer and a Content-Box just showing some html etc. Nothing strange at all but none of my modules are visible with this theme. They all still seem installed and they are activated. They are also positioned as they used to be when I check under Modules/Positions. Nothing indicates they are not active. Is there anything I should do to enable them explicitly for the theme? Thanks in advance

I was just about to post about this as well. The cart summary needs some love since it is completely non-responsive. Cart Summary screenshot

Ok, downloading the file lesley provided worked. I have some issues with the theme but for me this issue is solved for now.

@mdekker I think we are misunderstanding each other. Let's see if we can take a step back and get to a solution for this. I am on a shared hosting, the largest official Prestashop host in my country. They have geoip pre-installed on their servers and it can not be disabled on a per account basis. The conflict must be solved on application level, i.e. we must fix it or anyone wanting to install TB on a similar setup will fail if the hosting provider has geoip pre-installed. This appears to be a common issue affecting not only Prestashop but Drupal and other PHP applications as well. Again, I am not an expert but solving this seems fairly straight forward. In ThirtyBees we must prevent that these function clashes with a pre-installed version of geoip on the hosting. As far as I can see, this can be solved in two ways: You provide a way to turn off geoip support in TB. Maybe with a define or something else. You fork the geoip repository and wrap these functions inside a if (!function_exists(‘)) check so that they are not exposed if they are already available on the hosting. Based on this post https://www.akeebabackup.com/support/admin-tools/Ticket/9904-php-fatal-error-cannot-redeclare-geoip-country-code-by-name.html it seems as it may be even simpler to wrap the require call to check if geoip already exist rather then changing the geoip.inc file. Maybe you just have to do something like: if(!functionexists('geoipopen')) { requireonce JPATHADMINISTRATOR.DS.'components'.DS.'com_admintools'.DS.'helpers'.DS.'geoip.php';[/code] in the right place and the warnings will also go away? Sorry for pushing so hard but this seems a very common problem and without a solution in TB my installations or updates will always break until I manually hack the geoip,inc file and this will likely happen to others as well. It seems the fix is not that complicated.

@mdekker my hosting provider confirms that geoip is available by default on the servers and this is not something that is configurable. They say to simply disable the module using it. So, I really do not know what geoip offers to ThirtyBees but it does not seem that impossible to get to a solution for this? I am no expert and I do not know how and for what you use geoip but I have never missed not having it so maybe it could be considered that TB either: - Forked the geoip repo and add if (!function_exists(‘)) protection so your clone works even if the hosting has geoip as well. - Makes the dependency of geoip optional for TB users so the system does not break if the hosting provider already has geoip installed.

Hi I have a fresh migration that is updated to 1.0.3 and I am trying to enable the community theme but when I click on it in the backoffice it just says "Bad Configuration File" I have also tried to download the theme from github but the same thing happens when trying to install it. Selecting the default PS 1.6 theme seems to work, at least I get to the second page where I can select modules etc. Any suggestions?

I found the reason for the changes not working. In 1.0.3 you have changed the geoip folder from vendors/geoip to vendors/thirtybees/geopip so I had 2 instances of the geoip code and I changed in the old location. I will ask my hosting provider what can be done but are you really sure that this is not something that can be improved on the TB side? Several other posts have had the same type of problem with other applications than Prestashop and it mainly seems to affect function geoipcountrycodebyname and geoipcountrynamebyname Some posts suggest wrapping these functions in something like this: if (!functionexists('geoipcountrynameby_name')) { } taken from this site: https://www.drupal.org/node/2221205 I guess that might be problematic if you fetch from github but given that this project has not been updated in years you might just be ok with your own fork offering the extra protection for your users? Just trying to ensure a smooth process since right now any updates will probably break by shop if my local changes are overwritten. Having this protection by default or a way to enable the geoip support only on demand from TB would remove future issues similar to mine (I hope :-)

@mdekker thanks for the fast reply. I am making progress so lets see if I can make it happen. Let me ask two things: When you say disable geoip. Do you mean from the side of my hosting? Or can I do it somehow in TB? Can you give any advice on why it seems that changes to geoip.inc are not detected even though I have removed the offending file the error keeps complaining about the same line as before. Do note that in 1.0.1 it started to work when I commented out this function but now after updating to 1.0.3 even if I remove the function again, the change is not detected. It is like the php file is cached or something? I really do not care about this geoip support so if there is a simple way to remove it from TB I would love to try. As you say, it is a super old project and if it causes problem I rather purge it.

Update2: I have asked my hosting provider if they have an installation of geoip running by default. That might explain the duplicated defines and functions. However, I now am back to the previous problem. I did the update to 1.0.3 and now I have the same error. The problem is that even if I remove the function, the site keep complaining about the same problem on the same line, like this: Fatal error: Cannot redeclare geoipcountrycodebyname() in /var/www/vhosts/myhost.com/update.myshop.com/vendor/thirtybees/geoip/src/geoip.inc on line 1602 I have removed the function on line 1602 but it keeps complaining about the same thing. So, again, Plesk has caching disabled. Is it possible that the php file is cached somehow by TB? If so, how can I clear that. Right now even if I change the geoip.inc file, the changes does not bite, it keep complaining about line 1602.