Leaderboard
Popular Content
Showing content with the highest reputation on 09/03/2020 in all areas
-
Hey Puffdade, Sorry to hear that. That looks like a hack from the Hacker Group from Algeria. Super Irritating. Probably a bunch of kids who learnt the exploit from some malicious discord server somewhere. The only thing you can do is stop the initial attack vector which is either a bad/non-secure module or the phpUnit Folders which you can read about here: https://build.prestashop.com/news/critical-security-vulnerability-in-prestashop-modules/ Next make sure you're not using any outdated modules that may be vulnerable, the extent of your attack looks like it might stem from the 3rd party modules rather than phpUnit exploit. Make sure you're not using of any the infected modules listed in the first few posts in this thread - uninstall them and remove them from the modules folder in prestashop. Then go to your Back Office under Advanced Parameters > Configuration Information. At the bottom of this page it will check for any file changes not normal to Prestashop files. Replace those files with a backup of your website from before the attack. If you don't have a backup, replace it with the correct files from a fresh installation of your version of Prestashop. Watch out particularly for controller/admin/AdminLoginController.php and controller/front/AuthController.php - These are common to edit as they control the way passwords are handled. After all those files are checked. Go to your home/public_html and delete any suspicious files, You can identify them by being changed or edited the same day as the attack. Some are them are named the following: XsamXadoo_Bot.php XsamXadoo_deface.php 0x666.php f.php Xsam_Xadoo.html Its not limited to this list. Also look for anything with the words "Bajatax" or "jaguar" After all this is done and the website is operational again. You need to keep checking for modified changes each day to make sure there are no back doors. I currently am still looking for the backdoor on my site at the moment. If we cannot find the remaining backdoor, you may not be able to have your site back without completely restoring. This all goes without saying please back up everything before making changes. if you delete something you're not supposed to with no back ups, then you have a problem. Also after its all over, remember to change your passwords. if they've hacked your back end - they probably have your passwords. God Speed!2 points
-
Hi, This is for all who likes to add google analytics on their shop. If you are directly configuring 'Google analytics' by the module don't do it because it'll not work properly. You will get all the insights at first and after some time it'll stop giving insights at all. (Personal experience) So What I did is add this code in my header.tpl file in template/_partials but don't forget to add {literal}{/literal} at the starting and closing of the tag else you'll get a blank white page. {literal} <!-- Global site tag (gtag.js) - Google Analytics --> <script async src="https://www.googletagmanager.com/gtag/js?id=UA-134165817-1"></script> <script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-*********-*'); </script> {/literal} Hope it helps1 point
-
i had studay since last 2 weeks, clear cache, reconfig index, rebuild index, and i found search box are not function, in back end it work very well, any one please help or i need to hire an expect to fix it, this bug seem serious. thanks and have a good day1 point
-
Casi seguro es algún módulo que está dando error al añadir un producto al carrito. Activa el modo depuración luego en la consola del explorador comprueba los errores que salen. Comprueba en posiciones de hook los módulos que están en action add cart, puede que sea uno de ellos, captura la pantalla y ve quitando de ese hook los módulos, recuerda que luego debes añadir exactamente igual como estaban.1 point
-
Ah oui mais vous êtes en 1.7 donc ce n'est pas la même plateforme. Remontez votre bug sur Github qui n'a d'ailleurs rien à voir avec ce sujet ni le module chèque mais avec la méthode validateOrder qui contrôle les règles paniers (paymentModule appelle une méthode private de la classe Cart ce qui n'est pas autorisé) Vu comment ont été réécrites les cart rules en 1.7 ce bug ne me surprend pas^^1 point
-
Borra el caché (de PrestaShop) y revisa que ese custom CSS se está cargando en la página, no la veo cargada en ningún sitio. Si añado esa linea css por el inspeccionar del navegador si que funciona correctamente. Espero que puedas resolverlo. Salut!1 point
-
Buenas noches @ismaelfre como te a dicho @gusman126 sigue esos pasos. Por aquí también te dejo una guías que saco prestashop hace un tiempo https://www.prestashop.com/es/blog/instagram-shopping https://www.dominiozero.es/instagram-shopping-para-prestashop/1 point
-
Har du et modul med countdown timer ? Der er fejl i owlcountdown.php line 63. Hvis du har et modul til nedtælling med tilbud, så prøv at deaktivere det. Siden bliver aldrig færdig med at loade, så jeg kan ikke se indholdet. I øvrigt kan man heller ikke lægge i kurv fra produktlisten - er det meningen?1 point
-
Thank you very much, man! I've been able to update all my modules through the link you gave me, to the latest version and each one of them is working fine, now i'm finally ready to update Thanks really a lot!!1 point
-
ok. after few minutes of trying to do the same think with the same results i have seen that i have this problem when the checkbox of products isnt selected. when i select it all is fine. im not a coder to explain what does it mean but it will solve your problem reorder > select box of all the products u wanna move on next step > move > save&refresh > next step1 point
-
I have solved this in the following way. It is not a clean solution and it will break on update. I have made notes and comments though so hopefully it won't be hard to reapply on update. 1. First I have made tracking url in my Carrier, like this: https://apc-overnight.com/track-parcel.php?id=@&postcode=# 2. Then I edited /controllers/admin/AdminOrdersController.php The changes here are responsible for the tracking link in the email that the customer will receive. There is a public function postProcess(). In there around line 487 there is this: $templateVars = array( '{followup}' => str_replace('@', $order->shipping_number, $carrier->url), '{firstname}' => $customer->firstname, '{lastname}' => $customer->lastname, '{id_order}' => $order->id, '{shipping_number}' => $order->shipping_number, '{order_name}' => $order->getUniqReference() ); We need to change the {followup} var to include the postcode. So be fore this code I query the database to get the postcode. $post_code = Db::getInstance(_PS_USE_SQL_SLAVE_)->ExecuteS(' SELECT a.postcode FROM `' . _DB_PREFIX_ . 'address` a WHERE a.id_address = '.(int)$order->id_address_invoice.' '); Then the {followup} var inside $templateVars will become: '{followup}' => str_replace(array('@', '#'), array($order->shipping_number, str_replace(" ","+",$post_code[0]['postcode'])), $carrier->url), This will replace character @ with the shipping number and character # with the postcode, replacing any spave in postcode with the character +. (this is one of the specs from courier) 3. Then I override Order.php file. So this will be safe in prestashop updates. /override/classes/order/Order.php This change is responsible for the B.O. order page class Order extends OrderCore { public function getShipping() { return Db::getInstance()->executeS(' SELECT DISTINCT o.`id_address_delivery`, a.`postcode`, oc.`id_order_invoice`, oc.`weight`, oc.`shipping_cost_tax_excl`, oc.`shipping_cost_tax_incl`, c.`url`, oc.`id_carrier`, c.`name` as `carrier_name`, oc.`date_add`, "Delivery" as `type`, "true" as `can_edit`, oc.`tracking_number`, oc.`id_order_carrier`, osl.`name` as order_state_name, c.`name` as state_name FROM `' . _DB_PREFIX_ . 'orders` o LEFT JOIN `' . _DB_PREFIX_ . 'order_history` oh ON (o.`id_order` = oh.`id_order`) LEFT JOIN `' . _DB_PREFIX_ . 'order_carrier` oc ON (o.`id_order` = oc.`id_order`) LEFT JOIN `' . _DB_PREFIX_ . 'carrier` c ON (oc.`id_carrier` = c.`id_carrier`) LEFT JOIN `' . _DB_PREFIX_ . 'order_state_lang` osl ON (oh.`id_order_state` = osl.`id_order_state` AND osl.`id_lang` = ' . (int) Context::getContext()->language->id . ') LEFT JOIN `' . _DB_PREFIX_ . 'address` a ON (o.`id_address_delivery` = a.`id_address`) WHERE o.`id_order` = ' . (int) $this->id . ' GROUP BY c.id_carrier'); } } Basically I added the postcode so we can use it later. 4. /admin/themes/theme/template/controlers/orders/_shipping.tpl This change is again responsible for the B.O. order page and we are going to use previous change. Around line 65 we have <span class="shipping_number_show">.......... This becomes like this now {assign "letters" array('@', '#')} {assign "new_data" array($line.tracking_number, $line.postcode|replace:' ':'+')} <span class="shipping_number_show">{if $line.url && $line.tracking_number}<a class="_blank" href="{$line.url|replace:$letters:$new_data}">{$line.tracking_number}</a>{else}{$line.tracking_number}{/if}</span> 5. Then I override OrderDetailController.php /override/controllers/front/OrderDetailController.php This change is responsible for the customer order details Around line 208 there is this if ($carrier->url && $order->shipping_number) .... So this becomes now like this $post_code = Db::getInstance(_PS_USE_SQL_SLAVE_)->ExecuteS(' SELECT a.postcode FROM `' . _DB_PREFIX_ . 'address` a WHERE a.id_address = ' . (int) $order->id_address_invoice . ' '); $order->postcode = $post_code[0]['postcode']; $this->context->smarty->assign('followup', str_replace(array('@', '#'), array($order->shipping_number, str_replace(" ","+",$post_code[0]['postcode'])), $carrier->url)); These 5 changes seem to be working for me, for now. Would be nice to see some flexibility within prestashop regarding the tracking url and not have to go through these changes. I hope it will help a soul here. cheers1 point
-
Hello John, we had clients with similar problems. There are several things that can cause this problem: 1. Your cookie have duplicates as you mentioned (www vs non-www). This can hapen if you do not have propper redirect. For example, client came to your store as mystore.com (first cookie is created), then your configuration redirects user to www version (creation of second cookie occur). Keep in mind that cookies from non-www domain are available across all subdomains, including www. Solution for this case is quite simple, in cookie class, override function that sets cookie, set non-www domain cookie along with www, but for troubled domain, set cookie to expire somewhere in the past 2. Other cookie problem, that manifest itself with empty cart along with login problem (user cannot be loged in, always is redirected back) is problem with cookie size (max size is about 4096 bytes). After some research, we have decrypted clients problematic cookie, and found out that module responsible for this mess is actually "blockviewed". If someone is interested, we could create module that creates overrides for those functions. Hope this helps to understand the problematic behaviour1 point
-
I think maybe there is another CMS file which overrides the original one, did you check this? because it works fine for me when I removed that piece of the code1 point
-
Hello @lipo999 I know why it prevents you from inserting such tags, it's because in the CMS class file, you will find this line of code : 'content' => array('type' => self::TYPE_HTML, 'lang' => true, 'validate' => 'isCleanHtml', 'size' => 3999999999999), All you need to do here is to remove this piece of code: 'validate' => 'isCleanHtml' Don't forget to extend this class from the override folder so everything stays clean for any future upgrades. Good luck Cheers1 point
-
I also override that file and your override path is correct. Make sure overrides are not disabled on backoffice > Performance.1 point
-
Ya lo he conseguido solucionar, por si a alguien le pasa lo mismo. Basta con desactivar en el apartado de preferencias la librería HTML purifier. Un saludo1 point
-
alright, figured it out. personally, I still do have 1.4.2.5, though I believe all v1.4 should have the same structure. You gotta change this: self::$_totalWeight[$this->id] = round((float)($result['nb']) + (float)($result2['nb']), 3); to self::$_totalWeight[$this->id] = round((float)($result['nb']) + (float)($result2['nb']), 3); self::$_totalWeight[$this->id] += 0.05; where in my case, I added 50 grams to every order for packaging purposes. (0.05) In terms of Order.php, code is the same in v1.4, therefore I'm not reposting it once again. hope this helps1 point