El Patron

Yes, you’re absolutely correct — temporary email services do have proper DNS setup. Most of them include valid MX, DKIM, DMARC, and SPF records, so from a DNS perspective, they look exactly like Gmail or Outlook. That’s why simple DNS or MX checks alone can’t really catch disposable addresses — they pass those tests just fine. There are actually many different ways to handle this, and the approach really depends on which PrestaShop version you’re using and what you’re trying to block (fake registrations, spam checkouts, etc.). The example shown earlier is just one possible method. Because of what you pointed out, most shop owners end up using a layered approach — something like this: Use a blacklist or API service to detect disposable email domains. Keep basic MX/DNS validation just to block obvious typos. Add behavior or IP filters to stop bots reusing the same IPs.

here's an idea You registered displayVideoComments, but the template likely calls it without parameters (e.g., just {hook h='displayVideoComments'}), so $params only contains the default context bits (smarty/cookie/cart), not a product. That’s why $params['product']->id fails. Your forum post text also matches this symptom (product array empty). your custom hook method must accept $params, and the template that calls your hook must pass the product in. If the template doesn’t pass it, $params['product'] will be empty. What to change Module method signature public function hookDisplayVideoComments(array $params) { if (empty($params['product']) || !isset($params['product']->id)) { return ''; // not on a product page or product not provided } $idProduct = (int) $params['product']->id; // ...your query logic (ALWAYS cast to int / avoid string concat SQL) // Example: // $res_video = Db::getInstance()->executeS( // 'SELECT ... WHERE v.id_product = '.(int)$idProduct // ); $this->context->smarty->assign([ 'reactions' => $res_video ?? [], 'replies' => $res_replies ?? [], 'loggedOn' => (bool) $this->context->cookie->id_customer, 'customerId'=> (int) $this->context->customer->id, ]); return $this->display(__FILE__, 'views/templates/hook/videoreactions.tpl'); } Pass the product when calling the hook Smarty theme (Classic / 1.7–8.x): {hook h='displayVideoComments' product=$product} Twig (Hummingbird / PS 8.1+ and 9): {{ renderhook('displayVideoComments', {'product': product}) }}

There are a many ways to do this. Basic Syntax and DNS Validation (Built-in or Simple Hook) Out of the box, PrestaShop only checks email format (@, . etc.). You can extend this easily with a small PHP hook: Validate that the domain has MX records (i.e., a mail server exists). Reject or flag addresses from invalid domains or typos like gmai.com, hotmial.com. if (!checkdnsrr(array_pop(explode("@", $email)), "MX")) { $this->errors[] = $this->l('Please use a valid email address.'); } Fast and server-side, blocks emails that cannot receive mail at all. however, we do not know your prestashop version so I cannot guide on how to implement, please always include this for best results. a couple module that might solve most of your issues https://addons.prestashop.com/en/website-security-access/95042-block-fake-email-block-disposable-or-fake-emails.html I trust this developer: https://mypresta.eu/modules/administration-tools/customer-register-spam-protection.html

one page checkout is out dated, ugly, that module same as years ago, once page is ridiculous, checkout should be above the page fold, i.e. no scroll. if you have to scroll, which one will with that module, then it's two page checkout ajajajajajjajaja what you want, what your visitors want is 'above the fold checkout, i.e. no scroll. Best? my ph module solution built from walmart.com and jet.com(now closed and owned by walmart)...but the 2nd best? Native checkout, no module not even prestashop checkout. The native prestashop checkout is 'above the fold', rock solid and our module is a template override of native, native is that rock solid. What I am talking about is not 'prestashop checkout module'. Again there are only two rock solid above the fold checkout's, native prestashop and mine. Go with native. Note: the free stripe module is pretty awesome, you get cc intake, amazon,google and apple pay. Of course I don't know if you have requriements for more localized payment methods. The free paypal, before ps9, you could do cc intake at checkout....but stripe far superior in presentation and ease of use. Have fun, ecommerce is easy, chekcout does not have to be hard unless you replace native checkout oh and shipping is the hard part. el

@202ecommerce sorry to be a bother, quick question, during testing we expected the cc intake to be on checkout but this does seem to be an option, i.e. eventually we can enter cc through paypal pop up. Could you please confirm this or maybe I did not configure correctly. Thanks in advance for your time.

I do not recommend using prestashop checkout, it is very buggy, read more here...I have fixed many shops that had issues with theckout, removing prestashop checkout and using standalone payment modules. Depends on your country but usually paypal and stripe module. Stripe allows display of more than cc intake but again depending on country like google/amazon/apple and local regional. By far the most flexible payment features for PrestaShop. so if you remove prestashop checkout later, use native checkout which is very nice, all above the fold, standalone modules, paypal and stripe for example. the chances of having checkout issues etc. are signficanly reduced.

You are very welcome, again I apologize for saying upgrade! Good luck happy hunting!

rather than preach and perfectly understand, admin should not upgrade unless they talk to ps adult jajajaja let's try this wild guess, and here we go! The error “Attempted to call function highlight_file …” is only because the host disabled that PHP function. Re-enable it and reload — you will then see the real Symfony error. The real error is: “Expected argument of type object, array or empty, string given” which usually means a module added something wrong to Shop → Parameters → Product Settings. Disable the extra module(s) that extend that page, reload, and it should open. Then re-enable one by one to find the culprit. To find the real cause On 8.0.4 the Product Settings page is a Symfony form that other modules can extend. The classic causes: A module that tries to add a field and returns string instead of array in its form subscriber. A module that stored invalid JSON/array in configuration and now the form can’t hydrate it. A value in ps_configuration that should be array but is now string. Quick checks: Temporarily disable 3rd-party/back-office form modules (stock, feeds, product extras) and try the page again. Turn on debug and check /var/logs or var/logs/dev.log once highlight_file is enabled — it will tell you exactly which field is failing. If you recently installed/updated a module just before this started, that’s suspect #1. If you can grab the first stack trace after enabling highlight_file, paste it and I can tell you exactly which module/field it is.

I use any one of a number of online tools for robots.txt 'checker'. For your issue you may want to go to the chrome forum. https://technicalseo.com/tools/robots-txt/

I build basic blog on how to clean up common large tables but pretty much what @cooper662 suggested https://prestaheroes.com/blogs/mysql-optimization/which-large-prestashop-tables-can-be-dropped-or-emptied-safely

how do they pay the invoice? do the pay outside of PrestaShop? If so then you would need to manually change order status to 'paid', you can add new order status manually 'paid by invoice'.

8.0.4 is the 4th patch of beta 8.0. it is not a very reliable version, really until 8.2.3 was ps8 really ready you should consider an upgrade, but back everything up, build staging on subdomain, upgrade there to test. etc. Do not at this time upgrade to ps9, it's not anymore ready that 8.0.4 was.

would it not be simpler to just cancel the order?

what is your prestashop and php version? please always post this important information so community can help you better. excellent recommendations

Bonjour, Parmi les trois installations en version 9.0.0 et celle en 9.0.1, il existe un problème que vous n’avez peut-être pas encore remarqué : le bouton « Ajouter au panier » ne redirige pas toujours vers le panier. Je vous conseille vivement — en réalité, je vous mets en garde — de ne pas utiliser la version 9.0.1 tant qu’une version stable n’aura pas été publiée. Plusieurs problèmes majeurs pour la 9.0.1 ont déjà été identifiés et confirmés sur GitHub. Bonne après-midi, Fred