datakick

Niara already has copyright section. You can edit content using Community Theme Configuration module

https://github.com/thirtybees/niara/commit/15e5338e628fca184a339d6cde66c961bfeb8169

Validate::isValidEmail is called very often, in many contexts. Changing it is not a good idea. If you indeed have a need to validate email addresses, you can use hook actionBeforeSubmitAccount and do your validation there. I personally think it is not a good idea, as you will loose sales. Note that there are third party api that you can use to validate email addresses. For example, mailgun verification service works very nicely. They do a lot of tests - check that domain exists, test that MX records for domain exists, check that recipient email server is accepting connections. And apart from this, they have their own huge database of 'alive' emails, because their service send millions/billions emails monthly and they process result/bounce responses/etc. Still, I use this service to validate emails in my marketing list only. I don't care if address for transactional emails are invalid, I send the email anyway. If my customers don't want to tell me their real email address, they should be allowed to do so. As long as they complete the purchase, I'm happy. They won't be able to retrieve forgotten password, and they will not receive order processing emails, but why should I care.

There are modules for accepting crypto, but they usually work with some provider using third party api. If you want to implement crypto payments yourself, you can. 1) simply create custom currency (bitcoin, ethereum, etc), and set conversion rate (either manually, or via script). Then you can create custom payment method, and set currency restriction in a way that only this payment method can be used with crypto currency. 2) again, a lot of ways how to solve this. For example, my conseqs module can be used to change order status after some period of time. Or you can create simple cron script.

I understand your frustration. However, it's simply not possible to maintain 100% backwards compatibility, and yet move this project forward. Some of the compatibility changes were forced upon us. For example PHP8 reserved new Attribute class forced us to change core class name, without any way to provide BC polyfill A lot of libraries thirty bees core depended on, like minification, http requests lib, template, made their own changes and API modifications. Old versions of these libraries are not PHP8 compatible, so we had to adopt the new one. Again, this cause BC compatibility problems if some module uses them. To maintain compatibility in these areas, we would have to abandon PHP8 completely. And we don't want that. Even for a price that some older modules stop working. Then there are those minor incompatibilities you talk about. some of these are caused by new feature developments (new column in tables, new indexes, additional parameters to some methods). We try to implement these changes to be as BC as possible. For example, most of the new columns are nullable. Sometimes, it's not possible, though. changes in code structure - basically refactoring. We very rarely change signatures of public or protected methods, mainly to maintain BC with overrides. Sometimes we do this, but not very often. changes in semantics - again, we do this very rarely. For example, change return value of some method from 'array or null or false or zero' to return only array. These changes are sometimes forced to fix php8 issues caused by older modules. For example, some module can have code foreach (SomeClass::someMethod() as $row) {...} if someMethod returns false/null, this would throw an exception in php8. We might decide to fix this problem by making sure this method never returns null/false, and it always return array (maybe empty). But that can cause BC as well, if some module have strict comparison checks like this if (SomeClass::someMethod() === false) {...} So we now have to make a decision to prevent exception (500 error page), or potentially cause some minor compatibility issue. It's not an easy decision. And whatever we decide, somebody will blame us for doing it wrong. bug fixes -- yes, some modules depends on bugs in core. Some bugs were there for years, so module developers embraced and worked around them. When we finally fixed those bugs, modules stop working properly. Should we keep bugs in the core? I don't think so So yes, there are some (maybe lots of) backwards compatibility issues. Still, it's orders of magnitude less than what ps17 forced upon their user base. The only way to not have backwards compatibility issues is to stop development.

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