datakick

I've just released new version 0.3.0. This version adds some new functionality, but more importantly it fixes serious login-related bug introduced in 0.2.0. I strongly suggest you to update to this new version NEW FUNCTIONALITY Support for manual exemption in VAT module. Your customers can now click I qualify for VAT relief checkbox Added password reset functionality Added floating UI notification snackbar to inform user about various events (invalid password, wrong discount coupon code,...) BUGFIXES Fixed serious bug regarding login user Fixed bug with not showing all customers addresses

I can't believe I forgot to implement password recovery. I'll implement it right away and release new version soon I've added this to my backlog, but with low priority. I won't implement this anytime soon. But thanks for feature request I'm not sure this should be part of checkout module. This looks like an ideal job for tbhtmlblock module Yes, it should be. You might want to do some minor css tweaks to better integrate checkout page, but in general it should work out of the box This is not implemented. I've added this to my backlog and it will be added soon. But it will probably be hidden behind some settings option, because not everyone needs this You can test this module on my demo account

No, I haven't heard any such complaint. Also, I've just made a test checkout on my iPad without any problems or errors.

Regular expression is invalid, it should be enclosed in start/end delimiters, ie '/^*gold|gold|GOLD.*/' where / is a delimiter. Also, drop the escape:'html':'UTF-8' part. It should look like this: {if (preg_match('/^.*gold|gold|GOLD.*/', $product->name))} ... {/if}

I've just released new version 0.2.0. Here are the main features: 1) you can now choose between unified block with both shipping and payment options, of have these two sections rendered separately. Unified block: Separate blocks: 2) There's an option to render logos for payment and carriers 3) Initial support for form extension. Third party modules can now extend checkout forms, and add their own fields (or even sections). For example, my premium version of revws module (in upcoming version) will render checkbox to ask user for consent to send review request. And of course, there were some bugs fixed. You can download the new version from my site

It really depends on where you want to redirect. If you want to redirect to homepage on your new site, simply add constant url. If you, however, want to redirect to specific product, then you will need to use interpolation. This is how it can be done: 1) Trigger: you will want to use Page View trigger, and page Product. This rule will be executed every time someone opens your product page 2 ) Conditions: enter conditions that matches products you want to redirect. In my case I'll redirect all products name contains text Price alert (I test this on my demo account) 3) Action: choose redirect action. Now we need to construct redirect url. For this, we use Interpolate values method. This allows us to create static text with dynamic placeholder -- part of the text will be substituted for product information. I will redirect to google search, and use product Link Rewrite as a search term. To enter placeholder, simply enter @ character and system will offer you available parameters. Note that the @ character can't be inside word, so you might need to first write space, then hit @, and remove space after you select placeholder. The result should look like this: Every time someone opens product page that matches conditions, he will be redirected to google search page with friendly url / link rewrite as a search query. You can test this on my demo account for Price Alert product. I hope this gives you idea how to implement your redirection rules. You can do this for other type of pages as well (say category page).

You should be able to use my conseqs module to achieve that

@ariom the image url should not look like yours. They should include only image id, not product id. That means that url https://www.mudrashop.com/7327-home_default/telo-mare-90x165-cm-spugna-jacquard-stelle-marine-home-sweet-home.jpg is correct. I don't know how you managed to get product id to the image url. Do you have some module or override that do this? Anyway, you are going to have problems with this schema, because most modules (and tb core) expects image id to be single identifier. Note that you already have some problems on your site. On your homepage, products img elements contains this code <img class="img-responsive center-block" srcset=" https://www.mudrashop.com/7900-home_default_smallest/borsina-a-tracolla-in-pelle-intrecciata-aba-368.jpg 211w, https://www.mudrashop.com/7900-home_default_smaller/borsina-a-tracolla-in-pelle-intrecciata-aba-368.jpg 218w, https://www.mudrashop.com/4663-7900-home_default/borsina-a-tracolla-in-pelle-intrecciata-aba-368.jpg 250w " sizes="(min-width: 1200px) 250px, (min-width: 992px) 218px, (min-width: 768px) 211px, 250px" alt="BORSINA A TRACOLLA IN PELLE INTRECCIATA ABA 368" title="BORSINA A TRACOLLA IN PELLE INTRECCIATA ABA 368" itemprop="image" width="250" height="250"> As you can see, srcsset attributes references 3 versions of the image with id 7900, but only one of them contains product id (and is accessible). I suggest you to investigate this problem right away. Edit: it looks like this is caused by enabled PS_LEGACY_IMAGES option. You could try these steps 1) move legacy images: 2) disable Legacy Images option 3) regenerate images 4) regenerate .htaccess

This is because bleeding edge is mirroring 1.0.x branch, while 1.1.0 pre-release is based on 1.1.x branch. That means that bleeding edge will give you only bugfixes implemented since from 1.0.8. New features or other 1.1.0 specific commits are in 1.1.x branch only.

the same fix applies, but this time replace all occurrences of dropDatabase with dropDatabaseCustom

I can't reproduce this issue. I've just tested on my demo account and it seems to be working correctly

Of course it should work with every OPC module, but unfortunately it's not that simple. It's because payment modules are (historically) based on hookPayment which directly returns html code. This html code is supposed to contain one payment button to submit the standard checkout form. And it's very hard to reuse this html code inside different flow, like in OPC. For example, while in standard flow click on payment button submits/completes the checkout, in OPC it usually only selects the payment method. Most OPC modules works because of some black magic. They usually render the original html code inside invisible section of the page, and in the same time they parse the html and scrape information (payment logo, text, etc). They then render their own html content using these information. When you click on final submit button, they must also perform virtual click on the (hidden) payment button. This is very complicated process, and it doesn't work in 100% of the cases. In this particular case, @haylau uses OPC module that doesn't do this job well enough.

Search and replace all occurrences of createDatabase with createDatabaseCustom in module php files

Definitely not. I was just answering your question why this happens. It doesn't mean that this is correct behaviour 🙂 Moreover, the two installation methods -- installing from zip file and installing from remote repository -- should be unified and work in the same way. Right now they use different code with different results. For example, if you update module from thirtybees repository, its directory is deleted and then re-created from scratch. This means that *any* assets that module might store inside its directory are lost (for example uploaded files). I'll create new github issue for this EDIT: actually there is already an issue for this: https://github.com/thirtybees/thirtybees/issues/522

Because the code to extract zip archive intentionally do that 🙂

That's weird. I've tested login functionality right now and it works. Could you try in incognito mode?

Well, I don't see what apache brings to the table. Nginx can take care of url rewriting, ssl, gzip, serving static assets, etc. There's nothing left for apache to handle. Unless you need some special mods (mod_security, etc). I don't need those, so I'm perfectly happy to not use it.

This problem is already fixed. If you want to continue testing, replace the `define` with `const`, as shown here

You can test using SCA test cards: https://stripe.com/docs/testing#cards

you mean earlier version of stripe module? That does not support SCA, so you wont be to receive payments past September

I've just retested the functionality on standard tb checkout flows (standard 5-step, standard one page checkout, advanced eu one page checkout) and it works fine. You can test it on my demo account as well

I don't think this is an issue with this module. I bet you are using some third party one-page checkout module, aren't you?

I don't understand at all what you are trying to say. Please elaborate

Nobody reported any issues or problems, so I'm going to officially release the new version

Well, it's not solved, it's just suppressed 🙂 But don't worry, this will be fixed in 1.1.x