datakick

To tell the truth, this is the one of my worst selling module. The reason is probably that the target audience is tb (and possibly ps16, although I had no sale for this platform). My other modules that run on ps17 sells much better

Thought on what? I still don't understand what you are talking about. If you need the pay button to be the last one on the page, you can move the cart to the top, as I've already answered. If you need the button to say 'Buy now', then use translation. I don't see any other problem

You can disable floating cart and display it on top.

There is no 'Buy now' button, so I guess you mean final payment button? Well, it's already the last button in on the page, so I don't really understand what you want to achieve???

I did some investigation, and this area is pretty fuc*ed up. There is a column total_paid_real in order table that tracks how much money was actually paid. This column has been deprecated for a very long time, because this information is primarily stored inside tb_order_payment table. However, for backwards compatibility reasons, this column is still there, and thirtybees tries to keep it in sync with records in tb_order_payment table. Needless to say, it does this very poorly. The issue I've mentioned in my previous post is just one problem. There are others, for example currency issues. Some code expects this column to be in shop currency, other code expects it to be in order currency, and this can lead to totally wrong amounts (apples and oranges added together) We need to fix this. The first item is to remove all *read* usages of this column from core. Core code should always use data retrieved from tb_order_payment, and not use this deprecated column at all. Then, we should fix all *write* usages, so modules that depends on this column continues to work. Unfortunately, even with all of these, we will still have consistency issues, only not so frequently. It's just not really possible to keep things in sync. For this, we should have some scheduled task that automatically fix the data. https://github.com/thirtybees/thirtybees/issues/1161

I think this issue is directly related to the one fixed recently - https://github.com/thirtybees/thirtybees/issues/1153. You can forward to bleeding edge and test it. Note that the code change will NOT have any effect on already existing orders, as the data are already corrupted in the database. But new orders should display correct payments

Yes, it's possible. But dev experience is required

These kind of issues can be reproduces when you try to install zip file that is NOT a valid module. Sometimes, developers give you zip file that contains another zip file (actual module) + documentation, license keys, etc..... If you try to install this zip file, the content is unzipped into /modules directory, and result is that you have inner zip file inside your module directory instead of module directory. Another common problem is when you download zip from github repository. Github will give you zip that contains one directory named modname_master, instead of modname. Because there is no modname_master/modname_master.php file (there is only modname_master/modname.php file), thirtybees does not recognise this as a valid module, and completely ignores this directory. All these problems can be, and should be, detected during module installation process, and explained to merchants in some user friendly way. This is work in progress 🙂. The module installation process is being redesigned and unified (there will no longer be dependency on tbupdater module). During installation a lot of additional checks will be performed, and module installation will fail if any of these fail. And most importantly, if installation fails, there will be no residuals in /modules directory

Yeah, I was surprised as well. There's no real benefits, only plenty of potential bugs and issues. We should get rid of this 'feature'

@Sigi asked me how to change delimiters in feature value field exported by my datakick module. I've prepared a short video that shows how to do this:

Well, there is no switch for this. You can only remove the invoice from 'Order status change' emails, not from the 'Order confirmation' email. You can submit enhancement request for this on github.

@Chandra you are mixing two things. The settings on Order Statuses has impact on 'Order Status Changed' email only (ie. Awaiting bank wire email) What you are talking about is the 'Order confirmation' email, and that has nothing to do with order status. This email is always sent, and it contains all current information available. I guess we could change the current semantics, and attach invoice to 'Order confirmation' email only if current order status has the send invoice checkbox enabled. However, I'm sure there would be plenty of merchants that would not want this behaviour by default.

You should also install Override Check module to see what overrides are installed on your system

@toplakd the fix for this issue is committed in branch issue-1153. Could you please verify that it works? Simply use core updater and update to this branch

The problem is that total_paid_real column is not adjusted when the order is switched to the order status that 'Pays' the order (generate payment + invoice). Tracked here https://github.com/thirtybees/thirtybees/issues/1153

This directory should always exist -- it's part of thirtybees installation, and it's also part of ps16 installation. If it was missing on your system, you must have deleted this directory somehow. Either manually, or maybe some module did this for you, who knows. There is no code in thirtybees itself that deletes this directory, there is only code that empties its content. Therefore, I don't think this issue was related to your 1.1.x update. It's more likely it was just discovered during the verification process.

@rubben1985 gave me access to his back office, so I had a look at the issue. Indeed there was some weird stuff going on. For example, cache was not flushed when you clicked on Clear cache in Performance tab. My investigation showed that this problem was caused by missing /cache/smarty/cache directory. Recreating this directory using ftp seems to fix the issue (pending confirmation from @rubben1985) Thirtybees codebase never checked existence of this directory, so this issue is hardly 1.1.x injection. But it's an issue nevertheless -- the system should recover from this situation. The fix is already committed in bleeding edge

When shop data are changed there is NO automatic cache flush. Every module must handle this individually -- some of them subscribes to 'actionAfterUpdate*' hooks and use this callback to flush cache. Other modules invalidates cache on time basis - these can display stale information. I don't know how Advances search modules handles cache invalidation. I don't even know what 'Advanced search' module you are referring to, as there are multiple with this same name 🙂 Did you check your smarty cache settings in *all* shop context, as I suggested in my previous post?

Also, since you are using multistore -- ensure your cache settings is consistent across all your shop context, otherwise weird stuff can happen

It's very hard to do this kind of investigation on a live site. Debugging issues locally is very easy and straightforward - I can connect debugger, step through the code, immediately see content of any variables, evaluate test expressions, etc... the whole investigation process can be done in like 5 minutes. And it's safe. Debugging on a live site is completely different beast. I can't connect debugger. The only way I can do is actually edit source code and upload it via ftp. I have to be 100% sure I didn't screw anything before uploading modified files - it's pretty easy to bring down complete website this way. Also, since I don't have access to any variables, I have to print them to the page somehow. Of course, I don't want your regular visitors to see these, so I have to make this debug printing conditional to my session only. And there are the thing about encoding php values to string for debugging purposes. This tedious process can take hours, and is extremely dangerous. I would love to help, but I don't have hours to spend on this. Also, you are the only one who complained about this so far. So it can be something specific to your store only. I'm not going to invest any more time investigating this issue. Not until someone can reproduce this problem on vanilla thirtybees, and provide reprosteps.

Oh, but there were no demands on third party developers. I'm just saying that I've exhausted all resources - I've tested extensively, and failed to reproduce this issue. Unless somebody provides reprosteps there is nothing I can do further.

You might find this nginx configuration useful if you want to run your thirtybees on nginx + php-fpm server { listen 80; index index.php index.html; server_name localhost; root /var/www/default; # use original IP address changed by cloudflare set_real_ip_from 103.21.244.0/22; set_real_ip_from 103.22.200.0/22; set_real_ip_from 103.31.4.0/22; set_real_ip_from 104.16.0.0/13; set_real_ip_from 104.24.0.0/14; set_real_ip_from 108.162.192.0/18; set_real_ip_from 131.0.72.0/22; set_real_ip_from 141.101.64.0/18; set_real_ip_from 162.158.0.0/15; set_real_ip_from 172.64.0.0/13; set_real_ip_from 173.245.48.0/20; set_real_ip_from 188.114.96.0/20; set_real_ip_from 190.93.240.0/20; set_real_ip_from 197.234.240.0/22; set_real_ip_from 198.41.128.0/17; set_real_ip_from 2400:cb00::/32; set_real_ip_from 2405:8100::/32; set_real_ip_from 2405:b500::/32; set_real_ip_from 2606:4700::/32; set_real_ip_from 2803:f800::/32; set_real_ip_from 2a06:98c0::/29; set_real_ip_from 2c0f:f248::/32; real_ip_header CF-Connecting-IP; # root location / { try_files $uri $uri/ /index.php?$args; index index.php; } location ~ /.git/ { deny all; } location ~* \.tpl$ { deny all; } location ~* \.(eot|otf|ttf|woff|woff2)$ { add_header Access-Control-Allow-Origin *; expires max; } # Rewriting for images pretty url - both jpg and webp formats location ~* \.(eot|gif|ico|jpg|jpeg|otf|pdf|png|svg|swf|ttf|woff|webp)$ { rewrite ^/([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$1$2$3.jpg break; rewrite ^/([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$1$2$3$4.jpg break; rewrite ^/([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$1$2$3$4$5.jpg break; rewrite ^/([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$1$2$3$4$5$6.jpg break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.jpg break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.jpg break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.jpg break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9$10.jpg break; rewrite ^/c/([0-9]+)(\-[\.*_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.jpg$ /img/c/$1$2$3.jpg break; rewrite ^/c/([a-zA-Z_-]+)(-[0-9]+)?/.+\.jpg$ /img/c/$1$2.jpg break; rewrite ^/([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$1$2$3.webp break; rewrite ^/([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$1$2$3$4.webp break; rewrite ^/([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$3/$1$2$3$4$5.webp break; rewrite ^/([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$3/$4/$1$2$3$4$5$6.webp break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.webp break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.webp break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.webp break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9$10.webp break; rewrite ^/c/([0-9]+)(\-[\.*_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.webp$ /img/c/$1$2$3.webp break; rewrite ^/c/([a-zA-Z_-]+)(-[0-9]+)?/.+\.webp$ /img/c/$1$2.webp break; allow all; try_files $uri $uri/ /index.php?$args; } # php rewriting location ~ \.php$ { # Installer is using /install/sandbox/anything.php url to test rewritting capabilities # it should rewrite to /install/sandbox.test.php file rewrite ^/(.*)/sandbox/anything.php$ /$1/sandbox/test.php break; try_files $uri $uri/ /index.php?$args; index index.html index.htm index.php; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass php:9000; fastcgi_index index.php; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_intercept_errors on; fastcgi_read_timeout 360s; fastcgi_buffers 8 64k; fastcgi_buffer_size 64k; include fastcgi_params; } }

You can't just copy anything from one template to another and expect it will work -- templates need data that are provided by associated front controllers. Sitemap controller prepares data for sitemap template, and index controller prepares different set of data for homepage template. There's no way to mix and match this... The easier way to achieve what you want is to implement your own module, hook it to `displayHome` hook, and display any data you want (in your case copy code from sitemap controller, and copy sitemap template, and wire it all together)

Most likely theme related. You should look into js console to see if there are any js errors.

This is exactly the kind of breaking change that we are trying to avoid 🙂 There are many modules (both native and third party) that would be broken with this change. Take elastic search module as an example. This module *expects* that only one feature value exists for every feature. How would this module behave if we allowed multiple feature values? Who knows. There are couple of possible outcomes. It could work out of sheer luck -- maybe the module is retrieving the data from the database, and process them, in a way that it would survive such change it could throw an error during product indexation or it could continue to index only one feature value (the worst scenario, if you ask me --- the module pretends it works correctly, yet search returns incorrect data) Somebody would have to look into the code of this module and verify it works. We could do that for native modules (however it would take ages to go over all of them), but it's not realistic to expect third party module developers will do the same. There is actually a free module out there that works OK on thirtybees -- link can be found somewhere on this forum. But that doesn't change anything. It's very dangerous to use such modules, if you ask me