GitUpdater preview

[FooLab 37]

2 hours ago, datakick said:

Unfortunately we don't have ps17 template inheritance functionality yet

OT: and please please take a look how template inheritance works in xenforo because is awesome!

[Traumflug 553]

6 hours ago, datakick said:

Works very nice and fast. Congrats on this release! I tested it a bit, and here are my notes: 1. my locally modified files are correctly listed in Files to get changed, but are not marked as M (this worked when I updated from 1.0.8 to 1.0.x, but when not when downgrading back to 1.0.8)

Uhm, it's not a release, yet 🙂

As you noticed, Bleeding Edge versions mess up the file comparison. To make functions like version_compare() work, Bleeding Edge versions set the shop version to something like 1.0.8-1.0.x, where the part before the dash is the version found in install-dev/install_version.php and the part behind the dash is the name of the Git branch. This doesn't get resolved backwards, yet. It's on the TODO list.

[lesley 606]

After writing an article for the blog about the Git Updater tonight I really got to test it well with different versions upgrading, downgrading, and comparing files. It works really well. Honestly, I have not found any bugs yet in it and I did just about every version combination. 

There are a few small changes that I think would be good for the module though, nothing major.

I think for the Bleeding edge, if another version other than the latest is selected, it should be removed. Also, I think we maybe should follow the naming convention of other software and call it either the nightly build or daily build. 

 

This one is going to be tougher than those. I think we also need to scan the modules for version compatibility and at least warn users. Like if we are trying to downgrade from 1.0.8 to 1.0.3 and there is a module that require 1.0.4+, there should be a warning. Maybe even an option to set the module aside. 

 

The last thing, is small, It would be good UI/UX if the message detected what is being done, like "Process downgrade" or "Process upgrade".

 

Really, those are the only things I found and they are pretty small. 

 

One thing I would like input on from everyone. What about adding a requirements file to the main repo? That way we can compare the version system requirements against the current settings on the server. This would be useful for growing past 1.0.x. 

[Traumflug 553]

Glad to see this module works for others, too. Y'know, operating it as the developer, who knows every detail, is a different thing than handing it out to people just trying intuitively.

Give me another day or two for getting this module ready for release. Over the recent days I tackled all the smaller details, like actually removing marked obsolete files, like backing up manually edited files, like reviewing update script execution to avoid this CORS problem, such stuff.

Also a new thing is a class for requirement checks. Not much inside, yet, because requirements didn't change between 1.0.0 and 1.0.8. Still it should meet this suggestion of "adding requirements". Having it in the update module means that it's also there for older versions.

 

Nah, instead of talking so much, here's another preview:

gitupdater-2019-01-29.zip

[Brian 1]

I installed this latest preview but when I click "Compare" it says

 request failed, see JavaScript console

Also when I select updater from the preferences menu I quickly get an  error that disappears but that I was able to screenshot.

[Traumflug 553]

D'oh. That's debug code and fits my local installation only. You can delete this line or wait a few days for the release.

TODO list has become short:

• Find, report and uninstall known incompatible modules (which should solve the problem with statistics modules).
• Add a switch to ignore the community theme.

[FooLab 37]

If I launch the core updater it say that I have 24 not compatible modules... I think that they are the modules merge in a single one some versions ago:

graphnvd3

gridhtml

pagesnotfound

sekeywords

statsbestcategories

statsbestcustomers

statsbestproducts

statsbestsuppliers

statsbestvouchers

statscarrier

statscatalog

statscheckup

statsequipment

statsforecast

statslive

statsnewsletter

statsorigin

statspersonalinfos

statsproduct

statsregistrations

statssales

statssearch

statsstock

statsvisits

why they are still there? I followed upgrading instructions deleting them in past upgrades... maybe they are still (but not active) in the DB?

[datakick 593]

1 hour ago, FooLab said:

If I launch the core updater it say that I have 24 not compatible modules...
why they are still there? I followed upgrading instructions deleting them in past upgrades... maybe they are still (but not active) in the DB?

 

You are correct. Those modules were not marked as uninstalled, so thirtybees still think they are there and active. You can delete them directly from db, if you are not afraid. It's table tb_module. (and possibly tb_hook_module)

It would be nice to have some consistency check for these system records.

[toplakd 72]

If module was deleted directly from folder and not deleted through Modules section, than this are leftovers in database as datakick said.

Such future would be nice - that check database for modules that are "installed only in DB" but not available in modules folder as someone has deleted them manualy.

That would also solve the issue when migrating, where there are leftovers from prestashop modules which were not installed.

[FooLab 37]

I think I'm not the only one that is going to notice that as in the 1.03 to 1.04 upgrade article/instructions there's no mention of cleaning the DB.

I see references of them in multiple tb_module* tables:

tb_module
tb_module_access
tb_module_group
tb_module_shop
tb_hook_module

but maybe there are more in other tables too.

[Traumflug 553]

2 hours ago, datakick said:

You can delete them directly from db, if you are not afraid. It's table tb_module. (and possibly tb_hook_module)

Running the updater should correct this. If not, Core Updater needs improvement.

And yes, I'm dreaming of consistency checks as well. Probably happens not before v1.2.0, though.

[jnsgioia 83]

2 hours ago, Traumflug said:

Running the updater should correct this. If not, Core Updater needs improvement.

And yes, I'm dreaming of consistency checks as well. Probably happens not before v1.2.0, though.

I ran the updater and it did not remove these files.  The processing report said the removal failed and to remove them manually.

[DaoKakao 59]

gitupdater/controllers/admin/AdminGitUpdaterController.php, line #287:

file_put_contents('/var/www/html/thirtybees/config/debug', __METHOD__.' '.__LINE__.' $value '.var_export($this->redirect_after, true)."\n", FILE_APPEND);

The path to a file is hardcoded, so i've got a error during script execution because my site has a different location.

Is it safe to comment out that line?

 

Tnanks in advance

[datakick 593]

@DaoKakao you must be using old preview version. This module is now called coreupdater, and this line is no longer part of it

[ukclearance 7]

I tried to install this module but I get this error message when I do so:

[PrestaShop] Fatal error in module file :/home/30bees/vendor/pear/archive_tar/Archive/Tar.php:
Cannot use result of built-in function in write context

My server is ubuntu 18.0.4 and the shop is running 30bees 1.0.7  upgraded from Prestashop 1.6 everything appears to be working ok but this module shows the error when trying to install and no menu entry is put into the preferences menu so unable to access it.

Solution update

After doing some googling it looks as though this is caused because of a PHP issue rather than a 30bees one. Ubuntu 18.04 uses PHP 7.2 but i noticed that 30bees only says it supports upto PHP 7.1.

I found a solution on the prestashop forums which worked for me. So thought I would update it incase others are having the same issue

Edit the file on your server /vendor/pear/archive_tar/Archive/Tar.php

And replace this code

$v_att_list = & func_get_args();

with

$v_att_list = func_get_args();

Then save the file.

This fixed it fixed the problem for me.

Edited April 11 by ukclearance
found solution

[Traumflug 553]

1 hour ago, ukclearance said:

i noticed that 30bees only says it supports upto PHP 7.1.

Where? thirty bees officially supports PHP 7.2.

Also, module GitUpdater is abandoned in favor of Core Updater. Not only a rename, but also latest fixes. It should appear in the module list in back office.

[yaniv14 94]

I can confirm @Traumflug replies that TB fully support PHP 7.2

I've upgrade a shop last week from TB 1.0.2 / PHP 7.0 to TB 1.0.x / PHP 7.2 in less than 5 seconds with no errors at all.

[ukclearance 7]

Apologies if I said that 30bees didn't support PHP 7.2 and it does, I assumed it was a PHP issue

FYI I tried the core updater module as well and this also threw the same error:

[PrestaShop] Fatal error in module file :/home/30bees/vendor/pear/archive_tar/Archive/Tar.php:
Cannot use result of built-in function in write context

I am no coder so don't know what caused the error, but I know it would not install either the git updater or core updater modules until I made the change in the Tar.php file

 

[Traumflug 553]

No need to apologize. Looks like I overreacted a bit.

You mean this error happens when trying to install the module already? Then there's obviously something wrong with the code installing modules.

In back office -> Advanced Preferences -> Configuration Information is a list of changed files at the bottom of the page. Does this list any changes?