datakick

I'm not saying it's not caused by tb. I'm saying that, since it is an intermittent issue, it can also be caused by something else. And until there exists repro-steps one can follow to reproduce the bug, I will continue to think so 🙂 This was never an issue, this was just unnecessary log line that caused panic. This line was added to system log whenever user loaded *any page* immediately after cart was converted to order. At that moment, cookie still contained id of old cart. Thirtybees (prestashop) reacted on this situation by creating new empty cart, and by displaying this *error message*. But it's not an error, it is an expected workflow. This was *fixed* by deleting the code that logged this line. Nothing else 🙂

Note that it's not necessarily tb fault. Since it is intermittent issue with no repro-steps, the root case can be somewhere else. For example misconfiguration of server. Say, during peak hours HTTP requests can be dropped by apache/nginx, php server might not be able to create connection to database, etc... these would result in http requests returning 500 error code (and thus ignoring paypal callback) Of course, this could be mitigated, or even completely fixed, by rewriting paypal module. For example, the module could proactively fetch all completed transaction via paypal API, and check that all of them has been processed. But that's a big refactoring, and I'm afraid that tb guys don't have enough manpower to achieve that

that's not fix. You just made your site harder to upgrade. Use override. Optionally you can install my conseqs module and create rule to block this kind of email.

That's because this commit was to master branch, which corresponds to version 6.0.0. That version was released for a brief period of time only, as many people had issues with it. Since that time there was some development on 5.x.x branch, and couple of 5.x.x version releases. Unfortunately this branch still has the issue mentioned in this thread. I don't know if there are any plans to revive 6.0.0 work and fix it, or if the plan is to continue development in 5.x.x branch. That's up to thirtybees developers to decide.

I also think that it's not really necessary to have separate checkbox for GDPR (in checkout). I have even wrote an email to the bureau that oversees GDPR implementation in my country, and they confirmed this. Data provided during checkout are considered either - required by law -- business entities are required to collect some personal data for tax and accounting purposes. These are the data displayed on invoice - name, address, etc - legitimate interest -- businesses have legitimate interest to collect additional personal data, such as email or telephone number. These are to protect against fraud, to ensure product deliverability, etc... for example, you need phone or email to contact your customer if you discover later that you are unable to fulfil the order. As long as all the personal information you are collecting during checkout can be in one of these two categories, you don't need any consent. You just need to inform your customer about it, for example in your terms or privacy page. Of course, if you collect some PI that doesn't match these brackets, then you need consent. Example is age / date of birth. Unless you are selling alcohol or tabacco, you don't have any legitimate of legal interest to collect this info - you need consent. Anyway, I'm not here to discuss about GDPR. And I don't want to force my ideas on anyone. I decided to add new feature to the module -- custom consent checkboxes. You will be able to create as many checkboxes from back office as you want. That should fix it

The first one -- product.tpl will remain unchanged. Of course, it's would be best to implement the second option, but it's much more complicated. It could work in some cases, but sometimes it wouldn't -- that's the generic problem with diffing and patching algorithms.

I don't think there is an option to restrict carriers by postcodes in the core. I guess you are using some module that does this? If so, then you should probably ask the module developer to make an exception for when the address is missing

Well, I like the online editor as well. I'm even tempted to release a separate module that will allow you to edit all your php/css/js/tpl files from back office. Someone might find it useful. Regarding your question - you can, of course, edit your parent theme directly. The module will allow you to do so. But it it will warn you not to do that. The reason is that you will have hard time to update your parent theme. You would loose your modifications when you update your theme to newer version. When you create child theme, all your modification are located in this theme only. You can safely update your parent theme. Your child theme will receive all new files, except those that you have overwritten. I hope that makes sense

It's not that simple. This extra 1k code can have huge impact. There can be some initialization script that expects to run on specific page only. If we executed this script on different page, it might produce a lot of errors. These errors or exception can prevent other js scripts to initialize correctly, and... we have not working page. There's no shortcut here. The page must contain all the javascript that's requested. Nothing less, nothing more. So, the only way to optimize this is indeed to split it into common + specific javascript chunks.

Just released

There's a checkbox to agree Terms and Conditions, that should be enough for GDPR purposes. If you need any other checkbox - the module offers integrations, other modules can create their own input fields. For example, VatNumber module adds checkbox 'I qualify for VAT relief' to address field. My premium version of revws module adds 'Send review request' consent checkbox, etc.

Great. Let me know how the testing went -- if you want to test it on your server, PM me your domain name, I'll generate a license for you

I don't think that's a bug. Every page has its own set of css/js dependencies -- there are modules that includes some css / javascript on homepage only, or on product page only. Core collects all these assets and creates a bundle from it. These bundles are different, since they consist of different content. Of course, this could (and should) be optimized. For example, core could calculate intersection of these bundles, and generate some common.js / common.css files. Every page would then serve this common.js + page-specific.js files. There would be more resources on the page, but overall performance would probably increase - common assets would be cached by browsers. You can file this as an enhancement request

I received a PM asking if it's possible to use this module to implement ps17 like template inheritance. I'll answer publicly Short answer: yes, if supported by parent theme Long answer: my module overwrites the whole template file. So, if you want to make a tiny change somewhere, you need to copy the whole template file and make the change in it For example, if we have a template <h1>{$page_name}</h1> <div> {foreach $list as $item} <div>{$item}</div> {/foreach} </div> and we want to change the page title from <h1> to <h2>, we need to create an override with this content: <h2>{$page name}</h2> <div> {foreach $list as $item} <div>{$item}</div> {/foreach} </div> This is not very extensible and flexible. If the parent file changes, we will need to copy the changes to the override. Fortunately, smarty contains template inheritance feature. This feature allows us to wrap portion of template into the {block}{/block} tags. And then we can overwrite individual blocks. So, our example would change into something like this: Parent template: {block name='page-header'} <h1>{$page_name}</h1> {/block} {block name='page-content'} <div> {foreach $list as $item} {block name='item-content'} <div>{$item}</div> {/block} {/foreach} </div> {/block} Child template: {extends file='parent:template.tpl'} {block name='page-header'} <h2>{$page_name}</h2> {/block} Parent template is a little bit more complicated with these additional blocks. But child template is much more verbose -- it says to extend parent template, and then says how the extension would work --- only change block with name 'page-header'. The rest of the parent template will be used automatically. This is how ps17 theme works. And you can do exactly the same with this module. But of course, the parent theme the child theme extends must contain the {block}...{/block} syntax. Otherwise there is nothing to extend, and we can only overwrite the whole files. Unfortunately, I doubt there are any ps16 themes using this {block} approach (maybe I'm wrong). So, if you want to use this template inheritance, you should ask your theme developers to implement it.

around 40eur

That's not theme's responsibility. You don't know why these js files are requested to be included in the page -- there might be some third party module that need some of these libraries and it *asked* core to include it. Theme's responsibility is to include everything that was requested. Otherwise you break stuff. I know it's stupid, and it leads to bloated themes with trillions of unused js libs, but that that how it is.

Hello everyone, I'm presenting you my newest addition to my modules portfolio -- Child Theme module. You can use it to, well, create child theme. This can be very handy if you want to modify your theme without loosing the ability to install future updates. When you create child theme using this module, you will find new directory inside your /themes folder. This new theme is initially almost empty, it contains only config.xml file. But surprisingly, if you use this theme, your store will look the same as if you used parent theme directly. That's because module automatically finds missing files in parent(s) directories. You can now change individual files (templates, javascript, css) inside the new theme and the changes will be applied. You can do this by either manually copying the file from parent theme to the new theme. Or you can use built-in feature of this module to edit themes. Testing You can test the module on my demo account Purchase You can purchase the module in my store for EUR39.99 childtheme-0_1_0.zip

This error message isn't useful at all -- it just says there is something wrong with some template (probably the one that comes with this module). I would suggest you to upgrade your thirtybees to 1.1.0, as it comes with more detailed error reporting tool. And of course, enable debug mode.

When you look into the html markup, you'll find that there are images, they just aren'd visible. There is some slider, and by default it has class 'remove_after_init'. This suggest there is some javascript that should, after the page loads, post-process the html code (probably choose the right image for the current resolution, etc...) and remove this class. Then the image would be displayed correctly. This doesn't seem to work in your case. It's possible that your page triggers some javascript error (not necessarily related to this area) that prevents execution of the subsequent scripts -- there is a lot of red stuff in the javascript console on your page. You can try to disable CCC, maybe that will help.

To fix this: disable debug mode open the page again enable debug mode open the page again 🙂

Not possible, to have list with duplicate values would require very complex condition, and that's not possible with my module Again, not possible. The whole module is designed to work in back office only. If you want to have some customer-facing data, use features for that

What tb version are you running on?

Class TCPDF doesn't contain static method serializeTCPDFtagParameters, there is only an instance method with the same name. You will need to instantiate the TCPDF object and run the method on it, ie: $pdf = new TCPDF(PDF_PAGE_ORIENTATION, PDF_UNIT, PDF_PAGE_FORMAT, true, 'UTF-8', false); $barcodeParams = TCPDF::serializeTCPDFtagParameters([$order->id, 'C128', '', '', '0', 40, 0.4, $stuff, 'N']);

you need to check that css file is loaded into the page -- ensure that the displayHeader / displayMobileHeader are hooked css file is not corrupted -- for example CCC may concatenate it / prepend with another CSS file that is not closed correctly invalidate cache (browser/server/CDN-cloudflare)

Looks like config.xml file is not present in the theme installation pack. Please check. Anyway, thirtybees should display proper error message when you try to upload invalid theme package. This will be fixed