datakick

Disable debug mode, or upgrade thirtybees to 1.1.0. I've also filed an issue for this to be fixed within the module: https://github.com/thirtybees/advancedeucompliance/issues/10

Could you PM me access to your back office? I'll look into it

Core updater would tell you about them -- they would be listed after you compared versions If there are any improperly deleted modules, you are out of luck. There isn't any automated mechanism to fix that, unfortunately. You would have to manually delete them from PREFIX_module table (or modify core updater module to ignore them)

Thanks you all for your thoughts. I'd like to show you what I'm building here, and explain a little bit more my vision, regarding the theme page editor. What I did is I split the big template (like product.tpl) into many small blocks. Then I created a layout mechanism that allows to re-arrange these blocks as you like. There will be additional structures you can use, like section, tabs, columns etc where you can drop these blocks. Of course, dynamic blocks are supported as well (you can place any hook anywhere on the page) Here's a video. Note that this is work in progress, and very far from the final stage. So excuse the crude design 🙂 Is this something that your guys want / need, or is it completely useless? Any ideas?

I have recently helped someone with the very same issue. There were two problems that prevented migration: 1) core updater detected that incompatibile modules were installed. Unfortunately, these modules weren't really installed. They were simply deleted from /modules/ directory, but weren't uninstalled properly. Core updater tried to uninstall them automatically, but failed because they weren't found on disk. This is probably bug in core updater, and could be fixed 2) the update was run on php 7.3. Older version of thirtybees contains code that is not php 7.3 compatible, and this blocked upgrade. If anyone is running on php 7.3, it's important to use older php version to do the upgrade. Then, you can switch back to newer php 7.3. Again, this could be fixed -- that would require that core updater would bundle all it's dependencies, and would not depend on tb core files

You should upgrade to latest 1.1.0. That would actually solve this issue, as it contains new error handling code that does not emit notices or warnings to standard output Because you are experiencing so many issues, you should investigate what's wrong. Use core updater to detect modified files. Use Override check module to see what overrides you have installed. Use latest (unreleased) version of core updater 1.2.0 to find database differences, and possibly fix them, etc...

I've just tested it on my demo account and it works, as you can see here. My current settings: {hook h='displayRevwsReviewList' reviewStyle='item-with-product' allowPaging=true}

That's awesome, I'm happy the module works for you.

Db::getInstance() calls doesn't add any measurable overhead. Once the connection is established this method returns existing instance from static pool. Of course, it's possible to extract it to variable like this to save couple of micro/nano seconds per loop $conn = Db::getInstance(); do { ... } while ($conn->getValue($sql));

Imagine dice throwing. Every side (1..6) has the same probability -- uniform distribution. But if you throw 2 dice, then probability of multiplied number is different: total 1 -- probability 1/36 -- there is only one combination (1 * 1) that results in 1 total 2 -- probability 2/36 -- two combinations (1 * 2) and (2 * 1) total 4 -- probability 3/36 --- (1 * 4), (4 * 1), (2 * 2) total 7 -- probability 0 -- there is no combination that would result in 7 (or 11, 13, 17, 19, 23, 29, 31) As you can see, probability distribution changed significantly

I believe that product of two random number with uniform distribution results in a number that does not have uniform distribution, which means it leads to more collisions. In your case, mariadb rand() probably doesn't return number with uniform distribution, so product of two rand numbers might be useful. In my case, it's not (assuming php rand generates number with uniform distribution, as my quick test suggests)

For collision to happen, there would 1) have to be 2 php processes trying to insert new entry into the same table at the same time (or in the timespan of ~10ms) 2) and both php processes would have to generate the same random number Even the first condition is very unlikely to happen. But probability of both two condition to be met at the same time is effectively zero. You could run your store for thousands of years without this to ever happen.

Good job. I'm most interested in conversion of loyalty points on checkout. I'll test how it works with chex, but I assume it doesn't integrate

I believe php rand() function returns number with uniform distribution. But even if it didn't it's not really an issue. My snippet above checks if record with the same ID already exists. If so, then another random ID is generated. The worst case scenario - this adds a little bit overhead.

First of all, there are more database tables which primary key can be used to deduce interesting business information: guest, customer, connection, order, order_invoice,... If you want to implement some primary key randomizer, you should probably do this for all of these tables. One possible solution to tackle this is to create override for ObjectModel::add method. Something like this should do the trick: public function add($autoDate = true, $nullValues = false) { if (!isset($this->id) || !$this->id) { $clazz = get_class($this); if (in_array($clazz, ['Order', 'Customer', 'Guest'])) { $definition = static::getDefinition($clazz); // generate random number that can fit into signed int(11) and doesn't exists yet do { $rnd = rand(1, 2147483647); $sql = (new DbQuery()) ->select('1') ->from($definition['table']) ->where($definition['primary'] . '=' . $rnd); } while (Db::getInstance()->getValue($sql)); // use random number as a new ID $this->id = $rnd; $this->force_id = true; } } return parent::add($autoDate, $nullValues); }

I don't really know how to generate multiple invoices for one order. I just see there's a support for this in the code. Also, in back office order edit form there is some support for this, for example when adding discount: But it's totally possible this is just remnants of some old functionality that was dropped from ps/tb

I believe what you want do do is override Order::setLastInvoiceNumber. Note that there can be multiple invoices for one order, so make sure your invoice numbers do not clash in this situation

That's because I modified revwsrecent/views/templates/hook/content.tpl template and changed line {hook h='displayRevwsReviewList' allowPaging=false} to {hook h='displayRevwsReviewList' reviewStyle='item-with-product' allowPaging=false} Note that you can customize the widget more by passing these options: displayReply - display shop replies or not. Allowed values: true | false. Default true displayCriteria - controls how to display criteria breakdown. Allowed values: inline | side | false. Default value is the one set up in your settings reviewStyle - controls review style. Allowed values: item | item-with-product. Default value item order - how to order reviews in list. Allowed values: date | usefulness | author | product | title | content | grade | id. Default is date orderDir - order in descending or ascending - Allowed values: desc | asc. Default value desc pageSize - how many reviews should be displayed on one page. Default 5 reviews allowPaging - controls if paging is allowed or not. Default value true product - display reviews for specific product only customer - display reviews submitted by specific customer guest - display reviews submitted by specific anonymous visitor

I'm afraid that can't be done at the moment. Email subject translation works strangely - thirtybees is going through all php files on your system and looking for this pattern Mail::send(1, 'template-name', Mail::l('Subject')) When it finds this pattern, it notes that email template with name 'template-name' uses subject 'Subject', and offers it for translation (translation is performed within Main::l method during runtime) Unfortunately, this means that emails subjects and template must be hardcoded in the php code in order for them to be translatable. If there is some code that dynamically chooses email template, then translation doesn't work. Take following code for example: $template = 'template-name'; $subject = 'Subject'; Mail::send(1, $template, Mail::l($subject)); It should, theoretically, do the same as the previous snippet. The only change is that constants are extracted to variables. But, in this case, thirtybees's static analysis is unable to determine the association between 'template-name' and 'Subject' There are many emails in the system that are using this dynamic way. For example, emails regarding order status changes. Because order statuses are not hardcoded (you can create new one in back office), email subject can't be hardcoded in php codebase as well. And, therefore, they are not translatable using standard mechanism. Note that order status change emails use order status name as a subject, so you can modify order status name to tweak email subject. Or, you can use my conseqs module and replace subject on the fly

My solution for this issue is quite simple -- add this css code to /admin-dev/themes/default/css/overrides.css #nav-sidebar { overflow-y: auto; }

Enable Advanced Parameters > Performance > Profiling. This should tell you where the bottlenecks are. @lesley could you look into that?

It's ok if opcache extension is forbidden -- every usage in the core is conditional, there's a check that this functionality exists if (function_exists('opcache_invalidate')) { ... } The problem here is that it exists, but is crippled by some security restriction. That's weird. If thirtybees can't invalidate opcache entries, and opcache is actually in use, that might cause strange errors during code updates, as your server might still effectively use old version of php files.

Not relevant. You have enabled compatibility warnings, so all usage of deprecated methods are reported. To get rid of these, remove define('_PS_DISPLAY_COMPATIBILITY_WARNING_', true); from your /config/defines_custom.inc.php or /config/defines.inc.php files Not core issue. You have installed some module that registered hookModuleRoutes hook, but the hook did not return array. You will need to fix that module Looks like server settings issue -- its not possible to invalidate opcache. Talk to your hosting provider and ask why is OPcache api restricted.

This error occurs because your browser user User Agent string is too large (129 characters) and database column can store only 128 characters. Current version of thirtybees silently ignores this, and database automatically truncate the string to 128 chars. In this particular case it's not really important, because who uses this field, right? But in general, this silent truncation is a bad thing, because it can lead to unwanted data loss. The question is what the right fix should look like we can increase column size for this field in CustomerMessage object model we can do explicit truncation as @yaniv14 suggested (probably better to use multibyte version of substr function) or we could introduce some new Object Model Field meta information to inform core that it's OK to automatically truncate the field, something like 'user_agent' => ['type' => self::TYPE_STRING, 'size' => 128, 'truncate' => true], I personally think #3 solution should be implemented.

This is responsibility of Krona module. This option is does not work retroactively. When review is created, customer display name is saved into database, and is used forever. The *Default customer name* option just tells Revws module how to generate default value, so your customers don't need to enter their names. But it's only a default value, they can still change the display name to whatever they want, and it will be used. The email displays all products in order. One product is considered primary -- the most expensive one, and name of this product is used in email title. The email contains hover-able stars that are displayed if the email client supports it. Some email clients blocks images, css or other browser functionality - for these the stars are not displayed, but it fallbacks to simple links 1 2 3 4 5 That's revwsrecent - Recent Reviews Free module