janoo

If I understand right, problem lies in converting data to TB collation. For converting I use script developed for Wordpress plugin, but working also as standalone file: https://interconnectit.com/search-and-replace-for-wordpress-databases/ https://github.com/interconnectit/Search-Replace-DB I had never any issue with using it. It also helps to search and replace data records, and you can run it in "demo" mode without any changes, just see logs. Please don´t say it´s old 🙂 it´s not necessary upload something what works reliably already

Congratulation to this great milestone! Happy to see it 🙂 Many thanks to all contributors for talent and effort!💯

thank you @Theo but who count lines 40-60? 🙂 read carefully original: https://build.prestashop.com/news/major-security-vulnerability-on-prestashop-websites/ don´t count lines, find exact code there with your eyes, you aren´t robot And: that is rough correction, not a fix. Guys from Prestashop don´t care about PS 1.6 anymore, and patch for PS 1.7 doesn´t fit neither to PS 1.6 nor TB. So this rough correction is temporary good until some great coder make patch for TB here. I am not so good, so I use this rough correction. But not deleting these rows, just disable by commenting it. Question is: who use mysql cache and not file chaching? Who use mysql caching is vulnerable more now.

Maybe you are aware already of Dominik Shaim (CZ) who helped PS guys with this, and as @WBNet-Wout found link to patch for PS1.7, Dominik also wrote code for rough check your eshop: https://www.openservis.cz/pedido_checker.php?url=domain.tld and further reading in czech language is on: https://www.openservis.cz/prestashop-blog/dulezita-bezpecnostni-aktualizace-modulu-balikovna-update-nutny/ there you can find also link to download zip with code do clear attacked eshop with Dominik´s code: https://psmoduly.cz/modules_download_22/psql_find_nakaza_SPECIFIC_46045e87d3366a10dde0c1e80e0dd3aa.zip I really appreciate his effort

ThirtyBees and PS 1.6 has this code slightly different from in PS 1.7: you can find it in "./config/smarty.config.inc.php" if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') { include(_PS_CLASS_DIR_.'/SmartyCacheResourceMysql.php'); $smarty->caching_type = 'mysql'; } but principle is as same as in original Prestashop files v 1.6.x and 1.7.x described in https://build.prestashop.com/news/major-security-vulnerability-on-prestashop-websites/ I prefer to comment these lines, not remove at all, but it´s my decision only

In our company we offten use module: https://addons.prestashop.com/en/analytics-statistics/27146-premium-google-tag-manager.html it´s not cheap at all, but our guys from marketing and analytics are very satisfied and they use it 5 years already without issues or needs for something more accurate

If you noticed after Chrome/Chromium update to v99 or higher you will see on Admin Login moved items of "Stay logged in" and "I forgot my password", blame it on Chrome 99+, not ThirtyBees 🙂 This isssue is also on Prestashops 1.6 and 1.7 also. Chrome/Chromium added some new functionalities for CSS to core, and it comes maybe with certain bugs too https://developer.chrome.com/blog/new-in-chrome-99/ On other browsers layout appears correctly as before. Fix is easy, identical for Thirtybees or any Prestashop and no invasive for other browsers appearance of Login panel: Add into file: .\admin\themes\default\css\overrides.css this style: /* fix: chrome99+ login flying blocks */ #login_form #remind-me, #login_form .show-forgot-password { position:relative; }

works quick & fine on clean install, on php 7.4.x, many thanks to all for effort!

In my case same problem was triggered by changing translation for template (Niara in TB 1.1.0). Module functions comes to working fine even with pagination changing again after I´ve deleted translation php in themes/niara/modules/blocklayered/translations/ + deleted TB cache.