datakick

yes, there is new column in table tb_feature_lang. If you use coreupdater to update your store, it should be automatically created. If you updated your store manually, you can still use core updater to fix database differences.

I don't understand why this should bother you just now, as this was the case from the very start of thirty bees. This was the way tbupdater module extracted the modules it downloaded from api server. Module directory was indeed deleted, and replaced with new dir. If you uploaded the module manually, this didn't happen -- content was merged. In thirty bees 1.5, this is not an issue anymore, since we don't use tbupdater for updating modules from api server anymore. How is that a compatibility issue? We simply display information about extra column. We don't delete the column from db. We also display that removing this column is 'Dangerous'. I would expect that nobody would click on it, unless they know what they are doing. This is similar to previous point. Some module decided to change database schema for core table, and didn't bother to inform core code about this change. You are saying that core is breaking the module by enforcing database indexes it depends upon. I say that module is breaking core by changing database indexes. The core code depends on unique indexes a lot. PHP code expects database to enforce these indexes. If some module changes the index structure, all these assumptions in core code stops working. Exceptions and 500 error pages follows. Ahh, finally some compatibility issue. Thankfully 99.5% of modules uses lowercase-only in their names, so this one is not critical. I agree it should be fixed, though. We do accept Pull Requests -- feel free to fix this bug if it causes trouble for you. Should be fairy easy.

I'm afraid this is not easily doable, as back office login is performed by ajax call. That would probably require template override.

If you apply it recursively it should be enough (if it's the right folder) There can be other issues other than permissions. For example open_basedir php settings. Or misconfigured apache modsecurity. Or any other. Look into your browser network tab to see what your server response was for the ajax request that failed (the one with generateSettingsFile=true). There might be some clues there. In my case it completed without errors, I guess in your case there will be some error displayed

You are not supposed to create it, installer will create it itself. The first message means that installer failed to create settings.inc.php file for some reason (probably folder permissions)

Yes, as long as the schema remains the same - for example {categories:/}{rewrite} If you change the schema, then the old urls will stop working.

This functionality is kinda weird. If you have product ID in your url schema, for example {categories:/}{id}-{rewrite}, then system will use the product id directly and it doesn't matter what is entered in categories portion of path (even product rewrite can be wrong, it is not checked) For example url https://domain.com/en/a/b/c/d/2-whatever will automatically redirect to url of product with id 2 - for example https://domain.com/en/gifts/2-soap However, if you don't have ID in your url schema - for example {categories:/}{rewrite} then system will try to resolve the product ID by looking into db if product with given rewrite exists if it exists, then check that url matches The step #2 seems to be unnecessary, and is causing troubles. Without it, the system would automatically perform redirect for url for product with matching rewrite https://domain.com/en/a/b/c/d/soap but now it returns page not found, because the url for soap does not match expected url https://domain.com/en/gifts/soap I will probably fix this in bleeding edge / 1.5 @30knees with this change, you shouldn't have to do anything. Your old urls will be automatically redirected to new ones.

This compelled me to set up static subdomain for my website as well. Everything seems to be working correctly. Could you check with your chrome version https://store.getdatakick.com/ if it works fine for you?

No, I can't. It's likely browser version issue, or server configuration (maybe too strict cors policy, etc) Could you PM me your domain, so I could test on your site?

I guess thirty bees will have to emit some additional responses headers to mark media servers as trusted sources. I will have to read up on that. @the.rampage.rado can you create github issues, and enter any information you have found so far regarding this are? Media servers do not really help you that much if you point it to the same server as your primary domain. The only benefit is that requests to static assets on media servers will not contain cookies, so each request will save ~2k of data each way. Another benefits is that you can apply more easily caching rules (for example in cloudflare) If you had another server, and set up data sync between your primary server and your media server, then the benefits would be much bigger. On the other hand, you would have to solve issues with out-of-sync data

The only thing that exists is this: https://github.com/thirtybees/thirtybees/blob/e25be2ffb57ff6d98ea28b65ac3aa3bc6e621d0a/classes/ConfigurationTest.php#L180-L195 That should NOT run during installation time, because constant _DB_SERVER_ is not defined yet. If this test is executed during install time, that means that you defined this constant somewhere - most likely in in settings.inc.php file. Double check that this file does not exists.

Apache might have similar settings / issue with big headers. See here, for example: https://bz.apache.org/bugzilla/show_bug.cgi?id=64919 This is all just guessing. You have access to your server, so look into your apache/nginx/php error logs. It will tell you what is wrong, that's what they are for.

This looks like issue with small nginx header buffer (if you use nginx in front of your php) Look into your nginx error logs if you see messages like this one: upstream sent too big header while reading response header from upstream By default, nginx support only 4k of http headers. Sometimes it's not enough - all cookies, Location header, custom HTTP headers, etc must fit into this, which can be a lot. Especially if you have multiple cookies. For example, my PHP server returns 959 bytes in headers with single cookie. If I'm logged into back office, this would be around 2k. HTTP/2 200 server: nginx date: Tue, 11 Jul 2023 06:30:39 GMT content-type: text/html; charset=utf-8 x-powered-by: PHP/7.4.33 expires: Thu, 19 Nov 1981 08:52:00 GMT cache-control: no-store, no-cache, must-revalidate pragma: no-cache powered-by: thirty bees set-cookie: PHPSESSID=5ng3b7o88aktkk43uktrvnb645; path=/ set-cookie: thirtybees-52c547b202be54b989b7b16314b81de3=def5020083e391b99d2b735eec52301c2b655e1aa64110a7382a792b9e548322f81599d1c6480e39ee0f24a9ea1cf5ddfc502241d446f14065f449cae12783db1ad8db942d281e8dcabb67239a3d8592c77b8da9a5294caf3af5a8c974eccb9b8609801ebb9809971eef3f56eff88cd3c639d8150b737a21e13ac9507afd57ea3b67cfe39a89edda5f125ce2b0ff7c1bb617efee261f71f4df37f3a412be793c9d025d90b5439e0d90a0cd6409eb3d8d420ce601d72e682ba9578e7f451015be1be55afd7259a70f5db9a10e9e068cb418315637648413fada4e12c4; expires=Mon, 31-Jul-2023 06:30:38 GMT; Max-Age=1727999; path=/; domain=***.com; secure; HttpOnly x-powered-by: PleskLin If you use modules that creates their own cookies, this can easily reach 4k limit. If that happens, nginx will then drop the response from PHP, and returns 502 error page instead. The fix is to modify nginx configuration and increase buffer size. For example, I use this: fastcgi_buffers 8 64k; fastcgi_buffer_size 64k;

These are not texts from thirty bees. It is browser native validation support. The html input is marked as 'required', and browser will display these balloons automatically when nothing is entered.

Try to delete your browser cookies, or use incognito mode. Looks like something is remembering your db settings somewhere from previous installation

delete settings.inc.php file from config directory, if it exists. During installation, enter name of your db docker container as database server.

you need to install/enable PDO_MYSQL php extension

check php.ini configuration in your php docker, specifically sys_temp_dir. Make sure your php user has write access to this dir.

Regarding native mollie module - this is approved project. We also need this module. We investigated and decided to backport latest version of ps17 module to ps16 platform. Most of the functionality was written back in the days when ps16 was supported, so backporting those parts will be trivial. Some new functionality (like subscription/recurring payments) were unfortunately written for ps17 only. It will be possible to backport this as well, but with significantly more effort. So subscriptions may not be part of the first native version, we will see. Ultimately, we want to backport this functionality as well, as we have plans to use it for 'tb backers' ourselves. Regarding warehousing module. In short, it is a set of tools to handle after-sale processes. At its heart, there is a warehouse stock management system that is using double-entry accounting principles. Everything is modelled as a stock movements between locations (location is something like account). Locations can be physical or virtual. We have input locations (suppliers), output locations (customer sales, lost, wasted, etc), warehouse/regular locations, transient locations (picking and packing stations, etc). Every location has set of capabilities -- for example, if one can use this location for picking, if the products on location are sellable, etc. We don't track quantities of individual products on every location, we only track stock movements. Every movement belongs to some sort of 'warehouse operation document', for example picking, packing, stock intake, stock reservation, etc. Within this document, sum of quantities must equal to zero. For example, when picking products, we can take 3 items from Shelve1 and 2 items from Shelve2, and put 5 items into PickingBin1. sum(-3, -2, 5) == 0. This ensures that we can track where every product came from, and that nothing is lost. At location level, we do not track quantities. Instead, current quantities of products at location is SUM of stock movements for this location. This all allows us to answer a lot of interesting questions about our inventory: how many products we have for sale (sum of all sellable locations) how many products we actually have (sum of all locations - this can include returns, products in pick'n'pack process) On top of this core, there are implemented few processes - product intake, order fulfilment. In the future product returns, etc. For example, order fulfilment process: available quantity for sale is automatically calculated from warehouse info -- store shows actual quantity available for sale. order is placed by customer, and goes through the standard order validation process. employee mark order as validated, and switch it to 'Ready for warehouse' status module will try to automatically reserve stock on locations available for pickers. This can fail, for example if stock is at location that does not support picking (external warehouse, high location, etc) In that case, employee will create internal 'Stock movement order' to transfer stock to location available for picking. Once all stock is ready at picking locations, it will be reserved. When all products are reserved, system can (automatically or manually) print 'picking order'. Pickers will take this employee, and will use our picking app inside barcode reader or phone they will scan order it will tell them location where to go, and what to take from there they will scan barcode at location, and barcode of product, enter quantity one everything is picked, they will move the picked items to packing station packer will take the list, and will use our other application to ensure everything is packed. It will print the shipping labels etc. packages are handled over to carriers Internally, there will be multiple documents. Reservation document will mark product at location as reserved. Picking document will move product from location to temporary picking bin. Packing document(s) will move products from picking bin to package location. Carrier document will move products inside packages to customer location. It's all very complex and complicated, but also quite powerful. It's designed for bigger shops that have multiple employees and that want to streamline their warehouse processes. Pickers/Packers will not have to think, really, they will just do what they are told by the system. in office, you will have overview of what is where, what needs to be ordered/moved/etc Hope this makes it more clear. I know it probably raised more questions than it answered,... it's really hard to explain.

I apologise for the late reply, I was on a vacation last two weeks and I'm slowly burning through my unread mails and threads now 🙂 Regarding the @wakabayashi image rewrite -- this is scheduled to go to bleeding edge after the release of 1.5 (which will be very soon). We talked about pros and cons and risks about putting this into 1.5, and decided it's too risky to do so. While this is very nice functionality, it also brings some backwards compatibility problems and issues. The main (but not only) issue is that friendly urls of product images changed. We need a backwards compatibility solution for this issue, one that would work on both nginx and apache. We have to be sure that if store update to new version their images will still be displayed. That's not the case with current code, if deployed on nginx server. I've tested it on my demo server and it broke very fast. I understand that it can be very disheartening that it takes so long for us to merge this. I know @wakabayashi put a lot of effort into that. But we can't just merge is as it is and hope for best. It probably works nicely for his store, but we need to be sure it will work for everyone else as well. We need to be sure there are no visible bugs. We have to do core review to check for security and other issues. And this all takes a lot time -- if you look at this change, you will find that it touches 72 files, a lot of addition and deletion. I've already spend around two days of my time on code reviews, on fixing various small issues. There are still some issues that we need to work on before we merge it. But it will be merged. Just not into 1.5

Even on PHP7.4 your server is screaming these warnings at you. You (and most others) just decided to ignore it. You should look into your server error logs (or install collectlogs module if you can) and fix every warning / deprecation that you find in there. This one would definitely be listed there - on PHP7.4 as a warning still. PHP8 increased this problem to error level. Only AFTER all warnings are fixed is it safe to update your php version. This particular bug in module code is very easy to fix. Simply change the order of parameters of implode function from $products = implode($products_arr['href'], ','); to $products = implode(',', $products_arr['href']);

You can enable / disable modules per customer groups. You can have this disabled for visitors / guests, and enabled for customer or any other group you have.

I also haven't encountered any issues on my production server so far. Granted, I don't use that many modules, but its encouraging anyway. This is a tricky one. Do not turn off Stringify fetches on production server. Back in the days, MySql returned numbers (and other native types) as string. PHP would receive text value '100.45' instead of float value 100.45, even though in database it was stored as decimal number. PrestaShop / thirtybees didn't convert the data to expected data types, and work with the strings. PHP is funny enough to support operations with mixed data types without complains, for example $result = '100.45' * 10.65; Of course, this is little bit slower than doing operations with floats directly. And there are some gotchas and corner cases that make developers go mad. Newer db servers can return data in correct types, so we would receive floats or ints from mysql server directly. For developers this would be a big relief, because we wouldn't have to remember that the data we work with might be float of string or null. A lot of code could be simplified. Unfortunately, this can cause a backwards compatibility issues. And what is worse, it can just change the behaviour of system without any exceptions being thrown. Imagine there is a code if ($address->id_country === Configuration::get('PS_COUNTRY_DEFAULT')) { // do something } method Configuration::get() returns string, and there is a strict comparison used === instead of normal comparison ==, so types of operands will be checked as well. With stringify fetches, this condition returns true, because $id_country property contains string, so the condition is actually if ('1' === '1') { } Without stringify fetches, the condition would be if (1 === '1') { } and that evaluates to false. The result is difference in evaluation of logic. We are trying to weed out these kind of things from core, but it's hard and slow process. We will probably never get to the point where this option could be disabled safely. It's probably a good idea to hide this switch for normal users, or move it to some sort of 'Experimental' tab. I will do that.

No, subqueries are integral part of parent query. I'm talking about multiple independent sql statements executed in one call. With this option enabled, you could do $conn->execute('delete from a; delete from b; delete from c'); and it would be the same as $conn->execute('delete from a'); $conn->execute('delete from b'); $conn->execute('delete from c'); Theoretically, the first would be a little bit faster, because you save two calls to db server. It's nice, but very dangerous.

Hard to tell. There were few places even in core that used multiple sql queries. Thise were fixed. But if that's all, nobody knows. Static code analysis is mostly useless here.