Core Update: new version

[datakick]

Hi everyone,

I would like to ask your for your cooperation with testing new version of core updater module. The module had an extensive overhaul in order to support multiple php builds, initialization callbacks, new server api, improved logging and error handling, etc.

This new version allows you to update to latest bleeding edge (current core update does not allow this), and latest stable version (currently 1.2.0). 

Before I release the module officially, it would be very nice if somebody could help me test the functionality. If you have test server, local installation, or similar, please download this version of module and try updates. Please report any issues here, or via email.

Thanks in advance

coreupdater-wip.zip

 

[Mark]

I got this ajax error when updating database ....

 

There were hundreds of files that needed updating.... A bit daunting to do that... Maybe a "don't worry" about it comment?

Edited October 8, 2021 by Mark

[datakick]

17 minutes ago, Mark said:

I got this ajax error when updating database ....

 

There were hundreds of files that needed updating.... A bit daunting to do that... Maybe a "don't worry" about it comment?

@Mark thanks for the info. Could you copy the error message and send it to me via PM. Or, alternatively, give me back office access so I could test?

Thanks 

[wakabayashi]

When using "clear cache"...

No idea why it's missing on my side and not on others.

 

Edited October 8, 2021 by wakabayashi

[wakabayashi]

Ok uninstall and reinstall does fix it. Maybe it's worth to write this in the error message. Cause I got an error also when accessing the BO controller AdminCoreUpdater.

[datakick]

2 minutes ago, wakabayashi said:

When using "clear cache":

This table is created during module update / installation. Thirty bees automatically executes module update sql scripts/php scripts when the newly uploaded version is higher than current version.

My guess is that you had merchantsedition version on core updater installed previously. That module has version 2.0.0. When Overriden by tb version 1.4.0, thirty bees decided no to apply update scripts.

 

[wakabayashi]

9 minutes ago, datakick said:

My guess is that you had merchantsedition version on core updater installed previously. That module has version 2.0.0. When Overriden by tb version 1.4.0, thirty bees decided no to apply update scripts.

That's my guess too... Now I have this:

I am not at all sure, how I got this modules again. They aren't on my live server and my test server is a copy of it. Are they readded somehow if you change the template? It's probably not a topic that is related to the new core updater, but the "theme <=> module" handling while installing is very unclear to me... Even if I let the config.xml empty in themes it does activate and deactivate all kind of bull****. 

EDIT: This modules are not even installed. I don't have any such folders in "/modules". But in ps_module there are these modules listed... 🙄 Ui, this shows again how many things can go wrong for noobies. 😕

Edited October 8, 2021 by wakabayashi

[datakick]

40 minutes ago, wakabayashi said:

That's my guess too... Now I have this:

I am not at all sure, how I got this modules again. They aren't on my live server and my test server is a copy of it. Are they readded somehow if you change the template? It's probably not a topic that is related to the new core updater, but the "theme <=> module" handling while installing is very unclear to me... Even if I let the config.xml empty in themes it does activate and deactivate all kind of bull****. 

EDIT: This modules are not even installed. I don't have any such folders in "/modules". But in ps_module there are these modules listed... 🙄 Ui, this shows again how many things can go wrong for noobies. 😕

Yeah, that's unfortunate. 

I'll extend the core updater module to automatically remove reference to these non-existent modules from db. 

 

[wakabayashi]

1 minute ago, datakick said:

Yeah, that's unfortunate. 

I'll extend the core updater module to automatically remove reference to these non-existent modules from db. 

 

No problem. That's what tests are for 🙂 Do you have these entries too? I wonder why I have such stuff and others not. I believe some don't have theme, as they use new installs when the new stats module was already introduced...

[datakick]

13 minutes ago, wakabayashi said:

No problem. That's what tests are for 🙂 Do you have these entries too? I wonder why I have such stuff and others not. I believe some don't have theme, as they use new installs when the new stats module was already introduced...

Nah, theme switching will not create such mess.

If I remember correctly, back in the day when we were updating from 1.0.3 to 1.0.4 manually, the instruction was to remove these modules from filesystem. But that did not remove references in the database, obviously.

I had problems with these modules once, so I had to create consistency check module. That can help you to get rid of these easily. 

[datakick]

I have uploaded new version of module (attached in the first post), which fixes some issues with 500 errors logging, and also with the incompatible modules 

[wakabayashi]

💪💪💪 no issues during the update. 
 

In my case a I had a bit too much warnings about edited files. But I guess it's working with time stamp right? Cause i had some files, that are 100% equal to original class, but maybe were uploaded again trough FTP. I guess it leads to a warning. Probably almost not possible to change this behaviour.

[datakick]

44 minutes ago, wakabayashi said:

💪💪💪 no issues during the update. 
 

In my case a I had a bit too much warnings about edited files. But I guess it's working with time stamp right? Cause i had some files, that are 100% equal to original class, but maybe were uploaded again trough FTP. I guess it leads to a warning. Probably almost not possible to change this behaviour.

This is actually a first time issue only.

This was always a problem with bleeding edge. When you updated your store to bleeding edge, we never actually saved information about the exact git commit that 'bleeding edge' referred to. 

Without that information, core updater couldn't really check what files were modified. It always used files from latest stable version (1.2.0), and compared files on your server agains them. Obviously, any and all modifications to core files performed between 1.2.0 and git commit that was used for bleeding edge would be marked as 'modified by user'. Which is not correct.

From now on, core updater will store the exact revision inside _TB_REVISION_ constant. _TB_REVISION_ can contain either specific tag (1.2.0), or exact git hash like a09146c3db421e1604dd45dc8d63925c4aee7c4f. Core updater can use this information to compare your files with proper git commit.

 

[musicmaster]

Is it really necessary to declare this kind of stuff as "critical"?

It seems to me that that word should be reserved to things that are likely to cause errors in your shop.

I also found the buttons at the top right hard to find. 

[musicmaster]

It looked like CHECKING YOUR INSTALLATION stayed forever at 42.86%. I did it on a bleeding edge webshop that probably already was up-to-date.

[datakick]

20 hours ago, musicmaster said:

Is it really necessary to declare this kind of stuff as "critical"?

It seems to me that that word should be reserved to things that are likely to cause errors in your shop.

I also found the buttons at the top right hard to find. 

In my opinions these are indeed critical. System expects that database columns can store more data than they actually can. There are two possible things that can happen when system tries to store longer strings

1. data truncation -- entered data will be silently truncated by the system. Loss of user entered data is a serious problem, imho
2. an error can be thrown -- sometimes data are not truncated, but an actual exception is thrown. For example, see this issue: https://github.com/thirtybees/thirtybees/issues/1056.

Yes, these are serious issues, hence the critical flag

[datakick]

11 hours ago, musicmaster said:

It looked like CHECKING YOUR INSTALLATION stayed forever at 42.86%. I did it on a bleeding edge webshop that probably already was up-to-date.

Did the ajax request failed, or just took a long time to process?

[toplakd]

Tested the module today on my spare installation.

So far everything went through without any issues except those warnings about edited files which was already explained as first time issue only

[musicmaster]

2 hours ago, datakick said:

Did the ajax request failed, or just took a long time to process?

I had it once again running and got this.

I am afraid it is not a good idea to have so many ajax calls (the counter is here at 1684). On Windows computers they attract anti-virus checks and as a consequence they are slow.