datakick

Hi everyone, I'm presenting you today a new module I always wanted to create: Consistency checks. Some of you probably know that I offer paid support services for thirtybees (and prestashop as well). In my line of work I have regularly encountered issues that were caused by inconsistencies between expected and actual environment. Thirtybees core, and modules as well, often expects that some preconditions are met. And if they are not, things can go awry pretty fast. Let me show some examples or issues I've seen: Extra file in /classes directory My customer accidentally copied php file /classes/Tools.php to /classes/db/Tools.php. That's not a big deal, right? Some extra file shouldn't have any affect on the system, right? Well, it does. When thirtybees generates class_index.php (index file for class autoloader) it includes all files from the /classes/* directory into it. In this case, the result was that thirtybees core used Tools class declared in file /classes/db/Tools.php instead of /classes/Tools.php. At the time this accidental copy happened, it wasn't a problem yet. Because both files were the same. But when my customer decided to upgrade to new version, it started to matter. And it bring down the entire server. That's because new version of thirtybees was used with old version of Tools class... It took me 4 hours (and my customer 200 EUR) to figure out the root cause of this problem. The fix was simple -- just delete the extra file. Module were deleted from filesystem without being properly uninstalled We all are guilty of doing this. Sometimes you install some module, and it crashes your shop. HTTP 500 error code. So you login via your ftp and delete the module. And the shop works ok again... But, there's a problem. There are remnants of the module in the system. Entry in modules table, registered hooks, possible overrides,... these all can cause weird stuff and bugs. For example, core updater will not allow you to perform update if it detects that some incompatible module is installed -- but what if you already deleted this module from /modules directory? Sorry, you can't upgrade. Not without going to your database and delete the module information from there... Also, these deleted modules slow down your system a bit. If there are hooks registered by delete module, thirtybees core have to evaluate this situation over and over again, every time the registered hook is executed. That's waste of resources. Images aren't displayed, because the image file is not on filesystem This is classic problem associated with migration. You copied your /img/p directory from old server, and then you import your data into database. It's very easy to make a mistake, and the data in tb_image tables can have different IDs. If that's a case, your images won't show... because the image ID does not correspond with id used to store file on filesystem... Consistency checks module All these issues can't be reproduced on vanilla installation. That's because the inconsistencies does not exists (yet). There are no extra files in classes directory, no modules were force-deleted, and all images are present,... But these inconsistencies will appear eventually, simply by using the system. So I decided to create a module that runs a bunch of tests against your system in order to find these problems. And, if possible, offers a fix. By using this module, you can get your system into the state that matches the vanilla installation as much as possible. And that can help you reduce the chance of bad things happening. At the moment, the module does not really contain a lot of tests, there are only 6 of them. But I plan to implement new along the way -- every time I will work on some problem that is caused by some inconsistency. So you can expect a lot of updates in the future. Also, if you have idea for some checks, let me know. Bug detection This module can also help detect bugs in the core or modules. If you fix some inconsistency, and it re-appears, it's likely there is some bug that wants to be fixed. Don't be shy and report this. Help thirtybees be better and more stable. Download I decided to release this module for free in order to help this project to grow. You can download the latest version of the module here: https://store.getdatakick.com/en/modules/consistency

Likely reason is missing email template for some language. The system is indeed trying to send 2 emails, one to admin and one to customer. It uses current customer selected language to find the email templates. It will need 4 email templates in order to send emails correctly: /mails/<language>/contact.html /mails/<language>/contact.txt /mails/<language>/contact_form.html /mails/<language>/contact_form.txt If one of them doesn't exists for any of the language your customers can use, you'll experience this issue. The obvious solution is to make sure these templates exists for all installed languages. And, also, I would suggest you upgrade to 1.1.0 or 1.1.x -- this functionality was redesigned and it now *survives* these situation by using fallback email templates (english version) if they exists. And it logs information about any missing email templates to Advanced Parameters > Logs, so you can easily figure out the issue and fix it.

Regarding cheque module -- there's obviously error in the module itself. It - instructs system that the module instance needs to be created, for example when rendering module list -- need_instance attribute in config.xml - in constructor, it uses module ID to perform check. This id exists only when module is installed Put these two thing together, add strict php 7.3 warning, and you know the root cause of the issue. The simple solution is remove this module from the filesystem, if you don't use it. Of course, we could modify the Currency::checkPaymentCurrencies method so it always returns array. Unfortunately, this is compatibility issue itself -- there can be some code that do strict comparison on return value, ie: if (Currency::checkPaymentCurrencies($this->id) === false) And such code would stop working. Following checks would still work, though: if (! Currency::checkPaymentCurrencies($this->id)) if ((bool)Currency::checkPaymentCurrencies($this->id) === false) With second problem I can't help you, because I can't reproduce it, and you haven't provided any actionable details.

I don't have this issue, all groups are displayed correctly. Thirtybees uses this sql to retrieve list of groups: SELECT DISTINCT g.`id_group`, g.`reduction`, g.`price_display_method`, gl.`name` FROM `tb_group` g LEFT JOIN `tb_group_lang` `gl` ON g.`id_group` = gl.`id_group` AND gl.`id_lang` = 1 INNER JOIN tb_group_shop group_shop ON (group_shop.id_group = g.id_group AND group_shop.id_shop = 1) ORDER BY g.`id_group` ASC If the group exists, then the only explanations for it not to be displayed is that it is not associated with your shop

Excelent bug report, thank you. I have copied it to github issues so it won't be forgotten: https://github.com/thirtybees/thirtybees/issues/1098 Note that we need to investigate if this is change in core (impacts all themes), or if it's niara-only related issue. If it's niara specific issue, I'll review your changes and integrate them directly from your github repository. If it's change in core, it needs to be fixed differently.

Also, there's a very handy search functionality in tb back office. Works surprisingly well for system features:

Thanks @zen for your testing, really appreciated. Anyone else tried this, or has some input? Remember, once it's integrated and released, it's too late to complain... 🙂

I think you are talking about front-end interaction. Conseqs is not the right tool for that -- it's a tool that let you automate your business processes. Triggers are events in the system like new order creation, product was updated, stock increase, email is about to be sent,...

will it? You can already distinguish the products by their weight. So, the only thing that needs to be done is to associate these products with specific category. There are tools for that, you know... (wink wink, shameless self promotion)

How about this solution - create some special (hidden) category named for example 'Free shipping' and associate those products that warrants free shipping with it. Then, create new 'Free shipping' cart rule and restrict it to this category. That should do the trick, I believe.

@MichaelEZ you haven't really answered the question. I'm also confused and unsure what is it you want to achieve. Do you want to have two packages sent? One with free shipping, and one with 3,60 €?

Hello everyone, as many of you probably know, geolocation feature in thirtybees needs to be fixed. In 1.1.0, this feature is based on MaxMind database v1, which is no longer maintained, or updated. It also contains a couple of bugs. Basically, this feature was unusable in 1.1.0 Not anymore, hopefully. This feature was not only fixed, but also extended. The main difference is that will will not depend on MaxMind database (or service) at all. Instead, core defines new services interface for any module that provide geolocation service. Merchant will be able to choose which service should be used. There will be new thirtybees native module that provides geolocation service based on MaxMind database v2. And hopefully, there will be more in the future. I personally will to extend my commercial CloudFlare GeoIP module to provide geolocation services as well. Now, I would like to ask you guys to test this feature before it goes out in the next release. If you are willing to participate, please follow these steps: 1. update your store to issue-828 branch 2. Install maxmindgeoip2 module You can download it here:maxmindgeoip2.zip 3. Configure this module - You have to download maxmind database, either manually, or by using Download button Result should look like this: 4. go to Preferences > Geolocation and select this new module as a geolocation service 5. Test, test, and test Please test the feature and report any problems or issues you have encountered. Both with new module, and with core changes.

Patching core files is not the best idea. While this indeed works, it can bring other problems down the road: you can't update your store without loosing this modification (no more coreupdater for you) if you decide to switch to different theme in the future, this will cause you troubles, as other themes actually expect jquery.jqzoom.js plugin to contain original content I would suggest you to do this instead go to your modules find Community Theme Configuration module reset it if it's disabled, enable it

what does it mean, 'custom product attributes'?

https://store.getdatakick.com/en/modules/cloudflare-cache-purger

@Mark you are not on the latest bleeding edge, or you didn't clear your browser/server/cloudflare cache. File js/admin/products.js does not contain the fix. Line 213 contains if (typeof this.current_request !== 'undefined' && typeof this.current_request === "function") { instead of the correct one if (typeof this.current_request !== 'undefined' && typeof this.current_request.complete === "function") { You need to upgrade to latest version, and clear *all* caches. Don't forget the cloudflare one.

@Mark it is really hard to tell what's wrong without any technical information. Does the system show popup window with any error? Is there any javascript error in browser's console? Is there any failed (404/502/527/...) http request to the server displayed in Network tab in browser's console? If so, what is the returned content of this failed request? (look into preview subtab)

Yes, it's possible. And quite simple, actually. The only 'problem' is to determine if the account was created from back office or from front office. To do that, you can create condition for Employee -- for example Employee:ID > 0 During initialization, conseqs loads *all* php files in classes directory in order to find all existing Object Models in the system (product, customer, order, address, ...). Looks like you have two php files in this directory that declares class SearchCore. One of these files is the standard classes/Search.php. You need to find the other one, and delete it. It shouldn't be there in the first place. Maybe you created it as a backup (Search.back.php) or unintentionally copied it do some other subdirectory,...

You can override $definition, but only as a whole, which is not ideal. To do that, simply create file /override/classes/order/OrderMessage.php with this content: <?php class OrderMessage extends OrderMessageCore { public static $definition = [ 'table' => 'order_message', 'primary' => 'id_order_message', 'multilang' => true, 'fields' => [ 'date_add' => ['type' => self::TYPE_DATE, 'validate' => 'isDate' ], 'name' => ['type' => self::TYPE_STRING, 'lang' => true, 'validate' => 'isGenericName', 'required' => true, 'size' => 128 ], 'message' => ['type' => self::TYPE_STRING, 'lang' => true, 'validate' => 'isMessage', 'required' => true, 'size' => 6500], ], ]; } Don't forget to delete /cache/class_index.php afterwards. In this case that's all you need to do. In general, you would also have to adjust database schema to match the object model definition. In future version of thirtybees, core updater will take care of this for you automagically. We are not there yet, unfortunately.

Meanwhile, this is what you can do: edit file /modules/paygreen/bundles/PGFramework/Services/Autoloader.php and delete content of function extendCache. -- find this code protected function extendCache($className, $src) { $this->classNames[$className] = $src; $cache = '<?php return ' . var_export($this->classNames, true) . ';' . PHP_EOL; @file_put_contents($this->getCacheFilename(), $cache, LOCK_EX); } and replace it with protected function extendCache($className, $src) { } And it should work.

This module contains a bug. With every request, file /var/paygreen/autoload.cache.php is over-written with list (subset) of module classes used by current thread. This file is also used by autoloader to load classes. This can (and does) lead to race condition -- one thread can write new content to this file, while other thread is reading it. Note that this is bug in the module, not in the thirtybees. You are experiencing it in back office, because thirtybees trigger multiple ajax requests at the same time, creating ideal conditions for this race condition to happen. But it's more than likely the same problem occurs on your frontend as well, if there is enough visitors so multiple request arrives at the same time (or close enough) You need to fix the module, or ask its developer to do that.

This can be set per country in Localization > Countries

This is very strong indicator that the culprit will be override override. Anyway, it's impossible to tell you what's wrong without this third-party module source code.

It's hard to explain, because it was a result of few different things. 1) Theme references to page Theme can reference different pages in its config.xml file to set appearance of left/right columns. This display layout settings is saved in tb_theme_meta table. But this table needs existing parent record in table tb_meta. There used to be a bug in 1.0.8 -- if tb_meta record didn't exists, then this layout display settings was not saved during theme installation. What this meant? Let's say that some theme specifies that page 'All reviews' of module 'revws' should be displayed with left column enabled. If you installed this theme before you revws module, then this settings would be lost during theme installation -- that's because this 'All reviews' is not yet known thirtybees at the time of theme installation. If you later install revws module, it's All reviews page will be displayed without left column. If you, however, first install revws module, than the result would be different. During theme installation, this page is already know, so the display preference would be stored. And this page would be displayed with left column. As you can see, we got two different outcomes, depending on order of installation. That's not good. So, in 1.1.x, there's a fix for this issue -- if the page is not known yet, new placeholder entry is created in table tb_meta. And that allows us to register display preference for this page, even before it's known to thirtybees. If you later install revws module, everything will work as expected. If you dont -- well, we only wasted one table row. 2) Missing entries for standard pages in tb_meta There were many missing records in tb_meta table for standard controllers. That meant that you weren't able to specify left/right display column. But also, you weren't able to specify friendly url for these pages. Again, in 1.1.x, these records were added to data pack -- if you install 1.1.x from scratch, all known controllers are represented by their tb_meta records. However, if you upgraded from 1.0.8, these controllers don't have these tb_meta records. But, because of #1, these records will be automatically created. But they are different than those created during installation. Most notable, these automatically generated records don't have friendly url assigned. 3) bug in robots.txt When robots.txt file is generated, system use data from tb_meta table to genrate disallow rules. This mechanism always contained bugs, but they manifested differently in 1.0.8 --> meta table didn't contain all records --> these missing records were NOT represented in robots.txt by respective disallow rules in 1.1.x migrated from 1.0.8 --> because meta table now contains automatically generated placeholder entries for standard pages (with empty friendly url) --> this results in Disallow / rules in 1.1.x installed from scratch --> meta table contains entries for all standard pages --> robots.txt have correct results As you can see, this is a quite a mess. By fixing 2 long-standing bugs, another one is created / discovered. Unfortunatelly, this is the reallity of legacy software.

Should be fixed in bleeding edge