datakick

There is not much that can be done. This would require massive rewrite of the js app, there's not a simple solution

This is just a short FYI: We are currently integrating various features to main branch (aka bleeding edge) in preparation for release of thirty bees version 1.3.0. Some of these features require special initialisation, for example creating entries in database tables, new menu items, etc. Unfortunately, current version of Core updater do not support this functionality - only code is updated, and potentially database schema is fixed. But no data fixtures can be inserted into the database as part of update. This is serious limitation that prevents us to roll out of new features. Therefore, we have decided to extend Core Updater and implement this functionality. New version will be released soon. This new version allows us to introduce new core code together with all data fixtures it needs, nicely wrapped together. New functionality in 1.3.0/bleeding edge already depends on this new core updater functionality. Unfortunately, this also means that in order to update to upcoming version 1.3.0 (or current bleeding edge), you will have to first update your Core Updater module. Current version of core updater CAN NOT be used to update to this new version, because the system database would end up in inconsistent state. You can still use current version to update to 1.2.0, but not to main (bleeding edge). This is wanted behaviour. Once new version of core updater is released (hopefully this week) and you update to it, you will once again be able to update to bleeding edge and/or 1.3.0.

Nobody can answer that based on your description. Something must have changed - new module, updated php version, implemented caching system, antivirus, hacked server, etc. Computer programs rarely stop working without external input. Did you look into server logs? What does browser console says?

I see. Unfortunately no, it's not possible from within the module itself. You can delete it directly in db, using query like this: delete from tb_revws_review_image where id_review = 12345; Just replace id_review with correct value

It's not possible. The email address is required to distinguish between returning and new customers. Flow for different kind of customers are very different. For example, with returning customers you can choose between existing addresses, you don't have to enter account related information again, etc.

Hi everyone, Sorry for the trouble. This seems to be related to server plesk software update -- the configuration of extra PHP environment property was lost during the update, and the api server stopped working. The server is up and running again.

Hi Andy, I don't understand the question. Could you please explain a bit more?

Thirtybees requires InnoDB database engine. Your mysql server does not support this. You need to contact your hosting provider and ask them to enable it

that's indeed a very good idea, as it offers much better protection than the IP address check. It also ensures that the employee context is properly initialized -- that's important for logging, error handling, etc. And since you extract the logic to the admin controller, you can also wrap it all into a small useful module and offer it to the community 🙂

Because server responded with error code 500, you need to look into server errors log for further information

The module contains js library to determine screen resolution, and use it to determine if the floating cart is supported or not. On small displays it's automatically disabled. I guess there is some bug in the library itself, or in the browser on the devices, that reports wrong screen size sometimes. The size detection seems to be working correctly when testing on desktop browser in mobile mode. It will be hard to fix, as debugging in mobile is very limited, ... and I don't have such device that is affected by this problem. I could implement a feature that would force-disable cart floating on specific device(s), based navigator.userAgent browser property

And what does it say in javascript console?

There will be some screen resolution glitch. It's hard to investigate if it's reproducible on this device only, and I don't have it. Anyway, you can disable floating cart in the module settings, that should help mitigate the problem.

The fix should be in 'main' branch, not in 1.2.x

Regarding PHP compatibility: 1.3.0 will still be supported on PHP5.6 ... PHP7.4 There is an ongoing effort to make it work on PHP8. This is not a small feat because PHP8 introduced standard class 'Attribute' that clashes with thirty bees core class. To fix it we need to rename our class, respective move it to different namespace (in core and all native modules). While this is quite simple to do, it of course introduces compatibility issues with any third party modules. To overcome this issue, thirty bees will contain mechanism that will parse and 'patch' third party modules PHP files. When you install new module, it's php files will be processed anda all references to Attribute class will be adjusted. For this we will use third party library. Unfortunately that lib does not support PHP5.6, which is one of the reasons why we are deprecating PHP5.6 and will not support it in the future. At this moment there is still no need to actually remove support for PHP5.6, but once we integrate the support for PHP8 to mainline, we will be forced to do it.

Look into database. table <prefix>_configuration and check value of configuration key PS_OS_PAYMENT select name, value from tb_configuration where name = 'PS_OS_PAYMENT'; +---------------+-------+ | name | value | +---------------+-------+ | PS_OS_PAYMENT | 1 | +---------------+-------+ The value contains ID of order status that will be used when paypay module process the payment. You can compare it with the value in table <prefix>_order_state_lang select id_order_state, name from tb_order_state_lang where id_lang = 1; +----------------+--------------------------------------+ | id_order_state | name | +----------------+--------------------------------------+ | 1 | Payment accepted | | 2 | Processing in progress | | 3 | Shipped | | 4 | Delivered | | 5 | Canceled | | 6 | Refunded | | 7 | Payment error | | 8 | On backorder (paid) | | 9 | Awaiting bank wire payment | | 10 | Awaiting PayPal payment | | 11 | Remote payment accepted | | 12 | On backorder (not paid) | | 13 | Awaiting Cash On Delivery validation | | 20 | Awaiting Bitcoin Payment | | 21 | Waiting for 2 Confirmations | | 22 | Bitcoin Payment Confirmed | +----------------+--------------------------------------+ In my case, it matches the Payment accepted order state. I bet in your store this configuration option will point to different state. If that's the case, then update the configuration value to point to expected order state.

Please send me the module in zip file + information how to reproduce the issue, I will look into that. It will be something trivial, probably just wrong instance of $smarty being used to get variables

I believe the problem might be in modules/m4pdf/classes/M4Object.php 1772: if (version_compare(_PS_VERSION_, '1.7.4.0', '>=')) { 1773: $sid = new Smarty_Internal_Debug(); 1774: $ptr = $sid->get_debug_vars($smarty); 1775: $template_data = $sid->template_data; 1776: } else { 1777: $ptr = Smarty_Internal_Debug::get_debug_vars($smarty); 1778: $template_data = Smarty_Internal_Debug::$template_data; 1779: } The code expects that PS < 1.7.4.0 comes with old smarty library. Thirtybees updated smarty library to new version, so this expectation is not valid. Try to change this code to 1772: if (defined('_TB_VERSION_') || version_compare(_PS_VERSION_, '1.7.4.0', '>=')) { 1773: $sid = new Smarty_Internal_Debug(); 1774: $ptr = $sid->get_debug_vars($smarty); 1775: $template_data = $sid->template_data; 1776: } else { 1777: $ptr = Smarty_Internal_Debug::get_debug_vars($smarty); 1778: $template_data = Smarty_Internal_Debug::$template_data; 1779: } It might help. Or not 🙂

There seems to be a bug in tb core. The Webp compression settings is saved, but never used. Fixed in commit https://github.com/thirtybees/thirtybees/commit/86b570f23a08f877bdd8c078c09382224ac593c5

This problem happens when there are proxy servers in front of your store. These proxy servers usually act as a cache or a load balancer. When your visitors visit your server, the browser would send request to the proxy server. If proxy can't handle the request itself (usually because it's for dynamic php file), it will make it's own request to your php server. From the perspective of your php server the client IP address is address of proxy server, not IP address of actual visitor (request come from proxy server, not from browser). Now, as long as there is only one proxy server everything works fine, because the IP address of the client remains the same. However, if there are multiple, load balanced, proxy servers in front of your store, then each request to your php server can actually come from different proxy server with different IP address, and cookie the security enabled by 'Check the cookie's IP address' will take place. Thirtybees will block such requests, and that's correct behaviour.

This is common problem for those that use cloudflare. The solution is indeed to disable 'Check the cookie's IP address'.

This is browser telling you that it can't translate domain name to IP address. That is 100% not thirty bees issue. There could be some redirect in your store to non-existing domain, though. If that's the case, you should see it in your address bar.

When you log in to your back office, thirtybees will store your current IP address inside the cookie. On every request, the store will check that the IP address stored from the cookie matches the IP address of the request. If the request comes from different IP address, it will ignore the request, and close the session. When you are behind cloudflare proxy server, end user (browser) communicate with cloudflare proxy server instead of your site. When cloudflare can't handle the request from cache, it will contact your server to get retrieve content. This server->server communication is performed by one of the hundreds of cloudflare servers they have in their pool. Which one will be selected to do the job is entirely up to cloudflare. The end result is that every request to your site can, and usually will, come from different IP address belonging to cloudflare. And thats the reason why 'check ip address in cookie' feature does not work properly with cloudflare. As I wrote, there are two ways to fix this. You can either disable this check - yes, that will make your store slightly less secure, but if you are using https you should be pretty much fine. Alternative is to retrieve and use real end-user IP address that cloudflare sends in header. You can do this by modifying php code. I personally do this by putting another nginx server in front of my php server, this nginx do this translation automatically.

The project is going forward as planned. There should be 2 major releases per year, 1.3.0 will be released during the summer. While we also planned to release s few bugfix releases, there weren't that many injections and regressions in 1.2 release to actually do that. That would be a lot of work to release 2 bugfixes. I understand that it can look like not much is happening when you look at github repo(s), but a lot of work is done behind the scenes. Some is work on private repositories (thirtybees api server, data collection service, scheduler, etc). Some is work on public repositories that is not published yet (for example, there is an ongoing effort to make core and native modules php8 compatible, and this must be released as a big bang). Also, tb core repo is not the only one that receives some love. For example there's a big overhaul of core updater coming soon.

Yeah, that's common issue. Once you are behind network proxy like cloudflare, requests from the same browser can reach your site from different ip addresses (that belongs to cloudflare). The safety mechanism kicks in, and your back office session is closed. If you want to use cloudflare, you need to disable IP check in the cookies, or modify core to correctly determine real source IP address (cloudflare sends this one in http header, but thirtybees ignores it)