Jump to content
thirty bees forum

GitUpdater preview


Recommended Posts

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.

  • Like 1
Link to comment
Share on other sites

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. 

  • Like 2
Link to comment
Share on other sites

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

  • Like 3
Link to comment
Share on other sites

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.

1250494781_Screenshot(14).thumb.png.78d764ab3a054323c90ec4606d098012.png

Link to comment
Share on other sites

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.
  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

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?

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 1 month later...

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 by ukclearance
found solution
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...