Jump to content
thirty bees forum

datakick

Administrators
  • Posts

    3,035
  • Joined

  • Last visited

  • Days Won

    465

Everything posted by datakick

  1. There are no 'known' problems with core updater. All reported problems were fixed and new versions were released. You can download the latest version here. @jmeca did you try my suggestion about updating /tools/cacert.pem ? That should fix your certificate validation issues, and you should be able to update the store.
  2. What does that mean? Did you deleted all core directories (vendor, classes, Core, Adapter, controllers, admin*, tools,...) ? Might be corrupted cache/class_index.php. Delete this file.
  3. do you have ssl option enabled in settings?
  4. The ajax problem will be, most likely, caused by mixing http and https. Browser might block ajax requests from http to https. Make sure you are logged in to your back office using https:// protocol, and then try update again.
  5. Looks like this commit is the culprit: https://github.com/thirtybees/niara/commit/6abc6b7e555caadb48b02e662ffd8da105a927f8#diff-25beb89b157fe43848421e7b4cf456c7fa1a603879047d3c1e5c636aa5dff62e For some reason the working templates were overwritten with this mess. Probably not an intention. I will revert this commit
  6. Yes, that's the advanced functionality that we plan to put back there in the future, very well hidden so that nobody will use it 😉
  7. Yes
  8. I believe the easiest solution for you is to just tall your store to use old prefix. To do that, edit file /config/settings.inc.php and change value for define('_DB_PREFIX_', 'tb_'); for example to define('_DB_PREFIX_', 'ps_'); Then go to core updater and check database differences. If there are some critical changes, apply fix. Please backup your database before. If this prefix changing is not the right approach for you, for some reason, you will have to copy every table independedly. Use sql like this for every table (ps_product is source, tb_product is target) truncate tb_product; insert into tb_product select * from ps_product; If the columns or their position are different, you will have to enumerate all fields as well: insert into tb_product(id_product, id_supplier, id_manufacturer,.....) select id_product, id_supplier, id_manufacturer,..... from ps_product; Very tedious task
  9. @jmeca download this file: https://raw.githubusercontent.com/thirtybees/thirtybees/main/tools/cacert.pem and upload it to your thirty bees /tools/cacert.pem
  10. Server certificate on api.thirtybees.com is not expired, it's completely valid.
  11. This is your server configuration problem. Certificate on api.thirtybees.com is valid and trusted: Your server probably do not have updated trust stores / root certificates. You need to update your server packages. How to do that depends on your distribution. Some hints can be found for example here: https://superuser.com/questions/1679204/curl-on-ubuntu-14-all-lets-encrypt-certificates-are-expired-error-60
  12. Of course I can ask them to look into database 🙂 But fortunately I won't have to
  13. Why? For people that will use Stable releases this is not an issue. The revisions will always match official release tags, such as 1.3.0 or 1.2.0. If you are using bleeding edge, then you will see current exact git commit. This information for machines, not for humans. Revision is precise and it nicely correlates with information on github. I understand that from human point of view, it's nicer to see 1.4.134 instead of d601a7dfa69025341ea598f558885b6cbbd7b7b4. However, nobody would be able to figure out what exactly is part of version 1.4.134, or what are the differences between 1.3.0 and 1.4.134, simply because 1.4.134 would not tracked in repository. With revisions, we can look at github and see it all. What is part of this version? https://github.com/thirtybees/thirtybees/tree/d601a7dfa69025341ea598f558885b6cbbd7b7b4 What are the differences between 1.3.0 and current bleeding edge? https://github.com/thirtybees/thirtybees/compare/1.3.0...d601a7dfa69025341ea598f558885b6cbbd7b7b4
  14. I believe you were on some bleeding edge version before? If that's the case, then rest assured -- this is the one-time issue only. Next update will not be affected. When updating to bleeding edge we didn't actually saved exact git revision that was being used. In your store the only available information was that this is some variant of 1.2.0. Not very useful. During update, core updater asked server for a fingerprints of files for version '1.2.0', and checks it agains files on your server. Of course, every files that were modified between 1.2.0 and the bleeding edge version you have on your store will have different fingerprint, and so they will be considered modified. The new core updater fixes this issue -- we now define new constant _TB_REVISION_ that points to exact git revision or tag. During update, core updater will ask for fingerprints of files for this exact revision.
  15. From server log I can see that some clients requests file list over and over again. Looks like the client fails to store the file list to cache. At least thats the only explanation I could came with. This is (hopefully) fixed in latest version of the module. Are you using 1.4.3? Edit: From your log it's evident you are using 1.4.0. Please update core updater module. BTW, what mysql version are you using?
  16. Install new version of core updater 1.4.3 and try again.
  17. Then it's the issue of your theme. You will have to edit product.tpl and fix it there
  18. definitely not 3 gigs, maybe 3 megs. But you are correct, we log too much. I've released new version of core updater with optimised logging. Looks like the the API request didn't finish for some reason. This is server-server communication, so definitely not browser issue. Maybe you have some sort of antivirus / security software installed on your server?
  19. Yes, reinstallibg module should create mebu item. Even if not, you can go to module configuration page, and click on Check Updates on upper right corner
  20. try deleting cache/class_index.php
  21. Also, if you are using cloudflare, try to disable it for the installation process. Cloudflare by default respons with 524 Gateway Timeout error after 30 seconds... so even though your server supports 300 secs the request will be terminated after 30 seconds.
  22. Hard to tell what's wrong. This seems to be server configuration issue, though. Maybe there are performance limits on php/mysql server
  23. Yes, it would be updated, unless Update community themes option is disabled in core updater settings.
  24. search for 'Spam'
×
×
  • Create New...