datakick
-
Posts
2,969 -
Joined
-
Last visited
-
Days Won
453
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Everything posted by datakick
-
@Adik do you have override for class Configuration? If so, please consider if it's still needed
-
core folder is just a very, very small part of the thirty bees codebase. It's like 5%. If you want to update manually, you need to download thirtybees.zip file, and upload entire content to your store (with the exception of install/ directory). After you do this, you need to delete /cache/class_index.php and you should be able to access your system. It is not properly updated, though, as database changes were not applied automatically. You will have to use core updater to figure out what changes to database schema should be fixed
-
@musicmaster / @Mark thanks for the questions. I don't have time to answer right now, but I'll make sure to reserver some time for detailed explanation of both features later, sometimes during the weekend.
-
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.
-
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.
-
(solved) Core updater issue (ajax error in fresh install)
datakick replied to Websprint's question in Updating thirty bees
do you have ssl option enabled in settings? -
(solved) Core updater issue (ajax error in fresh install)
datakick replied to Websprint's question in Updating thirty bees
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. -
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
-
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 😉
-
Yes
-
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
-
@jmeca download this file: https://raw.githubusercontent.com/thirtybees/thirtybees/main/tools/cacert.pem and upload it to your thirty bees /tools/cacert.pem
-
Server certificate on api.thirtybees.com is not expired, it's completely valid.
-
Unknown column 'cache_visitors' in 'field list'
datakick replied to jmeca's question in Technical help
what? -
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
-
Of course I can ask them to look into database 🙂 But fortunately I won't have to
-
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
-
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.
-
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?
-
Install new version of core updater 1.4.3 and try again.
-
Then it's the issue of your theme. You will have to edit product.tpl and fix it there
-
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?
-
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
-
try deleting cache/class_index.php
-
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.
