yaniv14

You can add it to header.tpl or footer.tpl depends if you want it before closing head or body tags. in case your script has curly braces "{ ... }" like the async one you posted, than you should wrap it inside literal tag. e.g.: {literal} your script {/literal} Good luck. p.s. I believe that @SLiCK_303 suggestion would work as well, but I never tested that feature so I can't tell.

If you are on Apache try to regenerate htaccess. probably saving again in seo & url page will do the job. otherwise you probably has some cache on your computer.

try: {if $smarty.get.id_cms_category} {if in_array($smarty.get.id_cms_category, array(2))} {$content|escape:nofilter} {/if} {/if}

It is normal tb/ps behavior because orders are tied to carrier_id and if you change carrier info (like tracking link) and want to look at old order than you can get the carrier info from that time. I really ate this behavior because I believe that the only thing matters in orders are the shipping price and this part already being saved in the order table.

I dont know how the core updater code will work when doing those updates. But in general you shouldn't have any issue doing those changes in the DB. No data will be damaged or lost if the process will finished as it should.

If you are on a shared host and using Apache webserver, try to disable mod_security.

You should look inside the social login module folder for a "mails" folder.

I guess in your sample something like this will work: https://www3.royalmail.com/track-your-item#/tracking-results/@ @toplakd I am not sure about that. if I remember correctly the code is based on string replace from carrier->url. which mean that nothing will print if no carrier->url set

In order for it to work you need to setup the tracking url in the carrier settings.

On older version of TB there was a bug on module translations.

Try to look for a pattern related to the price of the products that fails. Maybe price with decimal or not. Maybe price that with added tax comes to floating numbers. Its hard to tell without examining the module, but I guess this error comes from the payment gateway api and not from the module code.

Each column is a different module. Information = Block CMS My account = Block my account footer Store info = Block contact infos

So basically your original problem was not related to nochex module but was a problem with Knowbands Super checkout module? Now that you disabled supercheckout module both your payment modules works fine?

If Paypal module throw the same error than I guess the error caused by the supercheckout module. Try to disable the module and revert back to standard TB checkout

can you post the content of this file: modules/nochex/nochex.php