Em produção, ligar o modo debug para todos os utilizadores expõe stack traces, paths internos e por vezes credenciais — não é opção. A alternativa é ligar o debug apenas para o teu IP, e deixar a loja a correr normalmente para os clientes.
O sítio certo para esta lógica é config/defines_custom.inc.php — este ficheiro sobrevive a upgrades do PrestaShop, ao contrário de config/defines.inc.php, que é sobrescrito.
<?php
// config/defines_custom.inc.php
if (!defined('_PS_MODE_DEV_')) {
$devIps = ['1.2.3.4', '5.6.7.8']; // os teus IPs
if (in_array($_SERVER['REMOTE_ADDR'] ?? '', $devIps, true)) {
define('_PS_MODE_DEV_', true);
} else {
define('_PS_MODE_DEV_', false);
}
}
Atrás de Cloudflare ou outro proxy
Se a loja está atrás de Cloudflare, $_SERVER['REMOTE_ADDR'] é sempre o IP do CDN — todos os utilizadores parecem vir do mesmo sítio. Usa o header com o IP real:
$realIp = $_SERVER['HTTP_CF_CONNECTING_IP'] // Cloudflare
?? $_SERVER['HTTP_X_FORWARDED_FOR'] // proxy genérico
?? $_SERVER['REMOTE_ADDR'];
// X-Forwarded-For pode trazer múltiplos IPs separados por vírgula
$realIp = trim(explode(',', $realIp)[0]);
if (in_array($realIp, $devIps, true)) {
define('_PS_MODE_DEV_', true);
}
Cuidado: confiar em X-Forwarded-For sem proxy à frente é perigoso — o cliente pode forjar o header. Só usar quando há um proxy de confiança que define o valor.
Limpar a cache
O PrestaShop guarda muito em cache. Depois de mudar o ficheiro, limpa var/cache/ ou usa o botão “Limpar cache” no back-office. Caso contrário podes ficar a debugar uma cache antiga e a pensar que o teu IP não está a apanhar.
Alternativa: por cookie
Se andas entre redes (casa, escritório, telemóvel), os IPs mudam. Em vez disso, liga o debug quando uma cookie estiver presente:
if (!defined('_PS_MODE_DEV_')) {
define('_PS_MODE_DEV_', isset($_COOKIE['ps_dev']));
}
Pões a cookie no browser quando precisares (DevTools → Application → Cookies → Add → name ps_dev, value qualquer coisa) e tiras quando acabares. Funciona em qualquer rede.