Migration module wants to install 1.0.1

[hubbobubbo]

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?

[yaniv14]

no. we are skipping migration to 1.0.2 with the ps migrations module. you will be able to update to 1.0.2 after you've done migrating. I recommend you to wait few days, because v1.0.3 should be out real soon and most likely it will be upgradable via the ps migrations module

[hubbobubbo]

Cool, I will wait for 1.3 then.

Thanks

[alwayspaws]

@yaniv14 said in Migration module wants to install 1.0.1:

no. we are skipping migration to 1.0.2 with the ps migrations module. you will be able to update to 1.0.2 after you've done migrating. I recommend you to wait few days, because v1.0.3 should be out real soon and most likely it will be upgradable via the ps migrations module

Oh, you guys are fast workers! I'll have to update my reply to @rubben1985

[Traumflug]

because v1.0.3 should be out real soon

I believe this when it happens :-)

Regarding the topic here, as one has to migrate to 1.0.1 before upgrading anyways, it doesn't matter much whether one migrates now and upgrades in a week or two or whether one does all this in one chunk. Amount of work is the same. Still, doing a migration now gives some headroom to deal with the issues coming up during the migration.

[alwayspaws]

@Traumflug :) Thanks for clarifying this. @rubben1985 - I hope you see what @Traumflug just said. :)

[yaniv14]

@Traumflug the only problem is that there were quit a lot of small dbquery bugs in v1.0.2 that have been fixed after it was released and it can be frustrating for some users to start working on a migrated shop with those bugs. I know that there is no release date for v1.0.3, but I really believe it should be soon.

[rubben1985]

Agree with @yaniv14 . I do not have time right now (i would really like but day has only 24h) to correct bugs even if there are corrections available. That is the reason I ask for 1.0.3 in the other topic (https://forum.thirtybees.com/topic/555/1-0-2-has-been-released/5).

I think minor versions should be very frequents (at least now that TB is borning). Not talking about improvement, just bug correcting (for that I like your values of non pressure :) )

[vzex]

We want to be :bee: up to developers speed :)

[alwayspaws]

@vzex - What we want 2 :bee: and what we can :bee: are two different things! lol!

[rubben1985]

@alwayspaws said in Migration module wants to install 1.0.1:

@Traumflug :) Thanks for clarifying this. @rubben1985 - I hope you see what @Traumflug just said. :)

I saw it now ;) Thanks

[hubbobubbo]

@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?

[yaniv14]

For now Michael marked this as delayed https://thirtybees.com/new-releases/thirty-bees-1-0-3-has-been-released/ I am not sure when exactly it will available.

[hubbobubbo]

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]

yes, you can do migrate to 1.0.1 and than upgrade to 1.0.3 and you will be just fine.

[yaniv14]

The only recommendation was to wait for v1.0.3 because it was right around the corner.

[hubbobubbo]

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 :-)

[DaoKakao]

IMHO, this is a 'birthmark' of PS: there're a ton of parameters affecting migration process. It could be caused by external modules, or even PHP version dependency, et c.

The best migration way (IMHO) is following: 1. Install fresh and clean TB 2. Migrate the products and combinations/features/attribiutes manually, thru SQL manager, like phpMyAdmin or HeidiSQL. Here's possible issue, because some modules alters tables, adding extra fields, so you have to match all necessary info carefully by hands. 3. Then add necessary modules one-by-one

Also i've figured out one observation: As PS as also TB is better to install and maintain on dedicated server, so you become independent on hosting provider's will and have a freedom to configure your server as you wish.

[hubbobubbo]

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.

[DaoKakao]

@hubbobubbo If you have a DS of VPS with enough resources, you can easily organize new parallel installation of ecommerce as a sandbox, and aftrewards just move it to production if all updates/migrations/tests are pass. No risk, imho

[moy2010]

@hubbobubbo Try to disable 3rd. party modules and all the overrides, just to make it easy to debug.

[DaoKakao]

If a module changed a table (any) in a database, what will give you disabling it? It won't revert table alters, but could lead to migration errors due to table structure mismatch.

[hubbobubbo]

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

[DaoKakao]

I said about changes made by modules in a database. Disabling modules/overrides won't revert database changes made by it.

[hubbobubbo]

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.

[hubbobubbo]

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.