FooLab 36 Posted January 22 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! Share this post Link to post Share on other sites
Traumflug 542 Posted January 22 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. 1 Share this post Link to post Share on other sites
lesley 606 Posted January 29 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. 2 Share this post Link to post Share on other sites
Traumflug 542 Posted January 29 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 3 Share this post Link to post Share on other sites
Brian 0 Posted January 29 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. Share this post Link to post Share on other sites
Traumflug 542 Posted January 29 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. 2 Share this post Link to post Share on other sites
FooLab 36 Posted February 20 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? Share this post Link to post Share on other sites
datakick 582 Posted February 20 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. 1 Share this post Link to post Share on other sites
toplakd 62 Posted February 20 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. Share this post Link to post Share on other sites
FooLab 36 Posted February 20 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. Share this post Link to post Share on other sites
Traumflug 542 Posted February 20 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. 1 Share this post Link to post Share on other sites
jnsgioia 83 Posted February 20 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. Share this post Link to post Share on other sites
DaoKakao 59 Posted February 23 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 Share this post Link to post Share on other sites
datakick 582 Posted February 23 @DaoKakao you must be using old preview version. This module is now called coreupdater, and this line is no longer part of it 1 Share this post Link to post Share on other sites
