datakick
-
Posts
3,120 -
Joined
-
Last visited
-
Days Won
487
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Everything posted by datakick
-
Ouch, this is beautiful bug: https://github.com/thirtybees/thirtybees/issues/1355 To fix it, either update to bleeding edge, or edit file classes/Cart.php and on line 2398 change if (carrier::useProportionateTax()) { to if (Carrier::useProportionateTax()) {
-
Hard to tell what's wrong. You should enable debug mode, and then look what does the ajax response looks like. There might be some hints there
-
@SLiCK_303 could you give me access to your back office so I could investigate the issue further?
-
This ajax error without any details is most probably mixed http/https CORS issue. Basically, if you - have SSL enabled on your store but access your back office using http:// - have SSL disabled on your store, but access your back office using https:// then the browser can blocks ajax call, because of mixed http/https protocols. I have fixed this issue in core updater and will release a new version soon. Meanwhile, just ensure that you access admin via https:// if you have SSL enabled, or using http:// if you don't.
-
@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
