Jurist

Thanks but creating a child template for a small code insertion, while child template can already exist under a different name is not really an acceptable solution.

Hello, I am trying to create a module, which needs to alter the active theme .tpl block, for eg: {block name='product_brand_below'} from product.tpl file. How do I do that? Using module front controller? I found $this->setTemplate('module:sample_module/views/templates/front/product.tpl'); method, but not exactly sure when it needs to be fired. {extends file=$layout} {block name='product_brand_below'} <p>Best brand ever</p> {/block} Is that the approach I should try to go with? I know I can just override the template file with child-theme but that's not something I am looking for. Thanks for any replies

Dear Prestashop Users, If you are not aware - today many stores all across the world were attacked by a new strain of Magecart trojan. The latest one was in July 2022, just about 7 months ago. Prestashop Management - please explain that. The platform for sellers and module developers is rapidly losing trust. 3 stores of ours have been attacked today. We are already thinking about moving to another CMS.

The most recent magecart attack.

Prestashop is under a global Magecart attack again. The last one was just about 6 months ago. We need an official stance from the Prestashop staff.

looks like mulitple store of ours have just been attacked by this. How do we prevent that issue? Cleanup is not enough. We need to stop that from happening

Prestashop has probably just been attacked by some new strain of Magecart attack Please check for suspicious javascript files and possibly classes/controllers edited files

If anybody was interested in such feature, I have developed a module which does what I needed in the thread above: https://addons.prestashop.com/en/registration-ordering-process/88522-auto-guest-passsword.html#overview

Hi @masterblaster, Thank you for your help. We have restored large portion of the store, responsible for communicating DB etc and briefly looked at the malicious code, which appears to be reading data from forms on website and then sends it through PHP curl to some remove server. do you have any idea on how to find out what plugin our file served as an attack vector? I was thinking about checking requests log, however due to a large number of users every day, I think it would be difficult to find out.

@masterblaster thanks for your help. we did restore large part of the site + removes the files that the script created. We will also add some extra security measures to those websites. I understand how it works with reading the data from forms, I think that didn't happen because there were no registrations between the time that the problem ocurred and the time it was removed from site. Do you know if that script reads data from the database?

@masterblaster I can confirm that there was /app/Mage . php file on both servers. there was also /js/vas51cs.js with a generated name. Looks like magecart attack. Which PS version eliminated the vulnerability? Does the malware impact the database data or only the new form users?

Hi @masterblaster, Thank you for your reply. I am afraid that we actually have been attacked. The files couldn't damage themselves. Do you know which PS version got rid of that vulnerability? Or does this require a new PR?

This happened to 2nd of the store I take care of the 2nd day. I am curious if that's a general Prestashop problem now? The problem is: when you go to the admin page of the store and insert correct credentials - nothing happens, page is just reloaded when you go to the admin page of the store and insert incorrect credentials - there's no error on the page, 500 server error in JS console. Either way, you are unable to log in to the store anyway. The resolution of the problem was restoration of half of the store's folders. I was unable to dig in and investigate which would take time, as I had to have those stores back to work. Restoration of the following folders helped: app bin classes controllers js admin tools var vendor webservice but I am just concerned now, are we being attacked by someone? Why was one of the files damaged, so the admin login was no longer working. It happened to 2nd separate completely different store, 1st one had a problem on Thursday, 2nd one on Friday. Same problem, same fix. Can't believe it's just a coincidence. I am looking for help.

Thank you for your input. I guess if there's no other way to do that, I am going to do it that way, thanks.

What do you mean both? Inserting smarty variable into the .tpl by Users is bad, because it requires manual alteration of the files and basic knowledge that not everybody has. Moving the content into the desired place with JS is also bad, because the content is rendered elsewhere and then only moved with JS to the proper place so it's displayed the right way. However Google renders content pre-JS alteration and also it would require onload event which could possibly slow the site down. I am asking about the correct and recommended behaviour, I couldn't find anything in PS docs.