datakick

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

Track here: https://github.com/thirtybees/thirtybees/issues/995

Have you updated your php version recently?

Do you have any cron tasks in your cronjobs module? If you do, then you need to setup external cron, otherwise these tasks will never run. What this external cron setup does is quite simply - it regularly opens specific url on your server, which gives cronjobs module opportunity to execute its tasks.

Oh, it's not related to this problem then. This is an issue with uploaded images that are stored inside /modules/<module>/ directory (instead of /img/ directory). When module is updated, its directory (including all upload images) is deleted and recreated from scratch. The root problem is in badly written modules, they need to be fixed to store their uploaded content outside of /modules/ directory.