yaniv14

are you sure you are changing in the validation file? all you need to do is to change from: $this->module->execPayment(); to $this->module->execPayment($cart);

As you can see this variable is not even being used in the function. anyway just do this and you should be fine.

This error has nothing to do with newer version of TB. this is related to PHP7+. the message is very clear about the reason. look at file: modules/iemt/controllers/front/validation.php on line 51. this function require 1 argument which is not passed. this function exists on file: modules/iemt/iemt.php at line 237, now i can't tell much about what is expected for $old_cart. but i guess you can try to pass the cart from validation. so try changing line 51 in validation.php file to: $this->module->execPayment($cart); if you can show the rest of the code after line 247 it will be better.

I guess you can remove/hide it from the relevant templates when you have a button or form related to registration. Like: authentication page, checkout page...

Its hard to tell without seeing the module or looking at some error log info. My guess that it something minor, as long as it is working on php 7+

My guess would be something related to your server/hosting. I never had this kind of error. I know some hosting use Apache webserver with mod_security that might cause problems.

are u using any module for checkout?

create a file "ContactController.php" and place it inside "override/controllers/front" folder. the file should look like this. <?php class ContactController extends ContactControllerCore { public function postProcess() { $email_address = Tools::convertEmailToIdn(trim(Tools::getValue('from'))); $emailParts = explode( '@', $email_address ); $emailDomain = end($emailParts); if ($emailDomain == 'qq.com') { header('HTTP/1.1 403 FORBIDDEN'); header('Status: 403 No China here!!!'); header("Location: https://www.qq.com/"); } return parent::postProcess(); } } i think it should work, don't have time to test it right now. you should delete cache/class_index.php as well

Its better to have it as an override. also delete cache/class_index.php file

If all attacks comes from the same ip address than you can block the ip address on your nginx/apache server block. if not and you need to block it on the code level, than you should make an override to ContactController postProcess function and check the email domain and block it there. $emailParts = explode( '@', $email_address ); $emailDomain = end($emailParts); if ($emailDomain == 'qq.com') { // do something }

check that the db table collation is utf8

Start by blocking the ip address and see if this bot attack again from different ip

Please post this in github as a bug.

All these speed test tools. Gmetrix, Google page speed, YSlow...... are pure garbage that all they do is provide job for SEO companies. I never run those tests on my sites. You can tell if your site is running fast or not. btw: do you know how much loading time you will save with the compress version (61 bytes less)? you will save about 0.000000000000001 second.... so you should defiantly go for it 🙂

If you want to use Chex i am sure that @datakick will be happy to help you solve this minor issue you are having with carrier as array

So its a core bug and it should be tracked in Github so it won't be forgotten. Did you check it with Default or Niara theme? and on what TB version are you working?

Are you talking about customized product or some 3rd party module that adds custom fields?

What kind of custom fields values?

Do you have any error log for the problem?

I am not familiar with Mollie module, but all the payment modules I am aware of don't really use the next available order number when using redirect method to payment gateways, they just send the cart id and expect to get it back when being redirected back to TB. and only than using the cart id with validateOrder function to create an order in the system. thats the proper way for creating an order from payment module. cart id is unique for a specific cart & customer so I don't really know how its possible to mix orders with carts unless the payment module is sending the wrong cart id or processing an order based on wrong cart id.

I don't think there should be a limit of 128 chars for user agent. But you can truncate the user agent to 128 chars like this: substr($_SERVER['HTTP_USER_AGENT'], 0, 128). Anyway I don't think that this kind of information is valuable to you because you probably use GA or other tools to collect this data.

Go to modules -> positions and play with the block cart position (up or down) inside displayTop section

I would first try to disable friendly urls and see if it works. And if it does I suggest to setup the same url patterns like you had before.

No, the one that shows when you hover the icon.