datakick

No, it's not supported. The highest supported php version is 7.4. Support for php8 should be in upcoming version 1.4.0. Note that support for php5.6 will be dropped

I have also deployed the bleeding edge to my demo server. You can play with it there and test the solution. https://demo.getdatakick.com/admin561wkvz9k/index.php?controller=AdminLogin&token=a0bcc55a35147408f49720ea9ac7cf79

This is now in bleeding edge. Nobody reported any issues, so hopefully it will work

what?

Hi guys, I'm looking for a testers of a new functionality -- dynamic pack quantities. This new feature allows you to create pack of existing products, and system will automatically calculate available quantities based on quantities of products in pack. The previous method (manual tracking of pack quantities) is still supported. In order to implement this functionality a lot had to be changed, so there is a potential for bugs. Therefore, I would really appreciate your help testing this before I integrate the code to the bleeding edge / next release If you want to test, please use latest version of core updater (1.5.0), and in settings, select 'Distribution channel' = 'Custom targets' in Update tab, select Version type = 'Development branches' Development Branch = 'dev' This will update your store to 'dev' branch.

It's not much of a core material, given that only a subset of merchants would want such feature (only EU, and I guess they do not want it). No changes to the core are needed in order to implement this functionality in a module as well.

I assume this regulation is concerned about final prices. As you know, there is no 'single' final price in thirty bees. There are a lot of components that can impact final price - customer group reductions, specific prices reductions, cart rules, quantity discounts, specific prices for different currencies, etc... Theoretically, the function to calculate final price depends on customer group customer country currency quantity carrier price(productId, customerGroupId, customerId, countryId, currencyId, carrierId, productQuantity) -> number Of course, in most cases, the final price is the same. But it *can* be different. So, for every productId, we would have to calculate final prices for all combinations of these input variables to figure out the lowest final price, and save it somewhere to price history table. And we would have to recalculate prices (sometimes for all products, sometimes only for subset of products) every time something important changes, like product base price changed customer group reduction changed product carrier association specific prices was created, deleted or modified cart rule was created, deleted or modified customer group was created, deleted, or modified Alternatively, we could calculate lowest price for all products periodically, like once a day. But then there would be a potential for breaking the law, as a short-lived price reduction might not be caught and tracked in price history table. Then, some merchants will want a functionality to track multiple lowest prices, for example for 'Wholesale customers' and 'Normal customers' groups. This will make it even more complicated. All of that is a huge amount of work. Just to track price history. This regulation was clearly designed for brick and mortal shops, where there is only one single price displayed on a shelf. In dynamic e-commerce environment this makes much less sense.

Ability to have custom code per store is added in bleeding edge

Very nice. I've tested it, and found only a small issues. For example, escaping for separator value (I can't use separator >) Otherwise, very nice addition. Addition: for 'schema' -- it would be nice to also have {count_values} -- displays number of values {first_value} -- first value according to 'Sorting settings {last_value} -- last value according to 'Sorting' settings

Oh my, what a stupid directive. For example, if I reduce price for a single day (black friday) by 50%, I will not be allowed to announce any reduction for another 30 day, unless it's more than 50 %. Because the reduced black friday becomes prior price. Also, technically very hard to implement.

Fixed in latest bleeding edge, thanks for reporting this issue. https://github.com/thirtybees/thirtybees/commit/c024695e15c5a7f0f8c3b6fdf7859d150a577154

Of course, if the browser visited the page before you fixed the cache-control header, it will keep using cached version of the page for the next 30 days. There's no reason for browser not to do so

I have created an issue for this 'bug': https://github.com/thirtybees/thirtybees/issues/1434 In my opinion, the change to save translations per section was very bad decision, and should be fixed. Of course, the fix should ensure that the original problem with max_input_vars is addressed as well.

this will affect new orders only

Your server returns cache-control header with max-age=2592000 seconds (30 days), which instruct browsers to cache the content for 30 days. curl -I https://torchsa.com/pl-pewpew-lights/739-olight-pl-pro-valkyrie-black-or-tan-1500lumen.html HTTP/2 200 date: Wed, 11 May 2022 09:29:27 GMT content-type: text/html; charset=utf-8 set-cookie: MyCookieName-d6e7f0883bc4d518a8b11c4d02613039=hgBy4hbJ6rg3YiQ4lqfHtqUz7xUB2K4xv6bzziD6bXuC771g2miisGwjYwQHnGwbBnAg_D5HHDwR6CZYyV1-10MvsiSUcI4J-5i90ToqaKHDIRwJ2eiRQqj3LSgBVYyyOLInFKxRWPCpWFFjb5PXiobwfCi67x3w4Bg6ttbDyRt7enR4kaBZUkJn5-MgCgmoDwVquJVIztOIx9Jdo-LmkfOD7evM7An-ZUOtHeHLvVg; expires=Tue, 31-May-2022 09:29:26 GMT; Max-Age=1728000; path=/; domain=torchsa.com; secure; HttpOnly cache-control: max-age=2592000 expires: Fri, 10 Jun 2022 09:29:26 GMT You need to figure out what component in your stack is emitting this header. It can be your http server (apache / php-fpm), or it can be some proxy server you might be using. Once you figure out which one is responsible for this issue, reconfigure it. This is not thirtybees related, the same behaviour would exists if you installed any php app on your stack.

basically, increment each value by 1

update value column in configiration table. For PS_OS_PAYMENT it should be 2, for PS_OS_PAYPAL it should map to 11, etc...

Look into tb_configuration table for 'PS_OS_????' entries. Update value to valid order statuses. You can use this sql query to find out to what order statuses are config keys currently mapped -- in your case, it will be wrong: SELECT c.name, c.value, l.name FROM tb_configuration c INNER JOIN tb_order_state_lang l ON (c.value = l.id_order_state AND l.id_lang = 1) WHERE c.name LIKE 'PS_OS_%';

the wp plugin uses this code to construct image src: $src_img_product = $url_service.'/' .$result['alternate_data']['product']->product->id_default_image.'-' .$current_atts['size_img']."/".$slug.".jpg"; where $result and $slug comes from webservice response, but $current_atts['size_img'] comes from plugin configuration: 'size_img' => get_option('didpd_default_size_img') There is probably some UI element to set this config key, or maybe now. I don't know wordpress. Anyway, this is not tb webservice issue

It's not. What is needed is for end user to be able to request deletion of PII, and that's not customer account. In fact, deletion of customer account can prohibited by other laws that have precedence over GDPR directive. To be GDPR compliant, all that is needed is a notice somewhere on your website, where you inform you customers that they can request account deletion by sending email. You can then perform action manually. Note that such request will most likely never happen, as people are too lazy to actually put any effort into anything. If it happens, you can go to customer account, and delete it (if there are no orders / invoices associated). If there are invoices, you have to decide according to your country laws if it's ok to delete such account. It's quite likely you are obliged by law to keep the records of sales for few years, so the deletion can't be allowed at this point. Also -- GDPR says that you have to delete only PII information. That means, you don't have to actually delete the account itself, but you can simply mangle personal information (name, email, phone,...). Such account can no longer identify natural person, and therefore is not under GDPR directive. But it can still be very useful for analytics, trends investigation, etc.

Go to your back office, to Advanced Parameters > Logs, and use decrypt exception functionality to find out actual error message.

You need a module for that. You can test my datakick module, it has xml export functionality: https://store.getdatakick.com/en/modules/datakick-data-export-and-import. There is 14 days trial period.

It's doable, but not very friendly. Look what static methods are available in Meta class. You could you getMetaByPage, or getCategoryMetas or getCmsMetas {assign var='contactMeta' value=Meta::getMetaByPage('contact', $lang_id)} {assign var='categoryMeta' value=Meta::getCategoryMetas(4, $lang_id, 'category')} {assign var='cmsMeta' value=Meta::getCmsMetas(9, $lang_id, 'cms')} <pre> contact title = {$contactMeta.title} category title = {$categoryMeta.meta_title} cms title = {$cmsMeta.meta_title} </pre>

Are you sure that it does not work? From the code excerpt you posted, it looks like that's exactly what module configuration page should do. The module installs Menu item so you should look there for more functionality. If unsure, ask module author

Bummer. This gdprpro module is not compatible with thirtybees.