Codeigniter

CodeIgniter 3 PHP 8.3: os erros fatais que aparecem logo no boot

Subi um sistema em CodeIgniter 3.1.13 pro PHP 8.3 e ele morreu no primeiro request: Call to undefined function each(), com o trace terminando em system/core/Common.php. Esse arquivo não é o culpado. É nele que mora o _exception_handler, que o system/core/CodeIgniter.php pendura no boot com set_exception_handler(), então todo fatal passa por ali. Quem interessa é a linha de cima do trace, dentro de application/.

Os três pontos que quebram

O each() e o create_function() saíram no PHP 8.0 e não têm substituto automático: o primeiro vira foreach, o segundo vira closure. O terceiro é o traiçoeiro, porque não aparece no boot: desde o PHP 8.1 o mysqli reporta falha por exceção (MYSQLI_REPORT_ERROR e MYSQLI_REPORT_STRICT vêm ligados por padrão). O driver em system/database/drivers/mysqli/mysqli_driver.php devolve FALSE pro DB_driver.php tratar, e é esse contrato que some: a primeira query ruim estoura mysqli_sql_exception antes de qualquer tratamento do framework.

grep -rn --include='*.php' -E 'beach(|bcreate_function(' application/ system/

# varredura completa; o stable 9.3.4 é de 2019 e não conhece o 8.3
composer require --dev phpcompatibility/php-compatibility:dev-develop 
  dealerdirect/phpcodesniffer-composer-installer
vendor/bin/phpcs -p application/ --standard=PHPCompatibility 
  --runtime-set testVersion 8.3

O remendo que segura o mysqli

// index.php, antes do require_once BASEPATH.'core/CodeIgniter.php'
mysqli_report(MYSQLI_REPORT_OFF);

Isso devolve o comportamento antigo e faz o CI voltar a tratar erro de banco como ele sabe. É remendo: esconde a exceção, não conserta a query. Deixe o db_debug ligado em homologação pra não perder o erro de vista. Argumento opcional declarado antes de obrigatório é só Deprecated desde o 8.0, não derruba nada, mas em library de terceiro isso enche o error.log a cada requisição.

A conta honesta: o 3.1.13 é de 2022 e não vai ganhar versão nova. Se o phpcs voltar com centenas de ocorrências espalhadas em libraries que ninguém mantém, remendar sai mais caro que reescrever o módulo crítico. Rode as duas varreduras em homologação com display_errors ligado e navegue nas telas que usam banco: o que não quebra no boot costuma quebrar na primeira consulta.

Post Recentes

cron_schedules WordPress: intervalo de 5 minutos no WP-Cron

O WordPress só oferece hourly, twicedaily, daily e weekly. Use o filtro cron_schedules para criar um intervalo de 5 minutos…

15 horas atrás

E-mails do WooCommerce não chegam: como testar o envio de um pedido real

Dispare pela linha de comando o e-mail de um pedido que já existe na loja e descubra se a falha…

23 horas atrás

CodeIgniter 4 tela branca: CI_ENVIRONMENT e o erro que sumiu

Página em branco no CodeIgniter 4, sem nenhuma mensagem? O ambiente está em production e escondeu o erro. Troque o…

2 dias atrás

Google Consent Mode v2 no WordPress: default denied antes do gtag rodar

O Google Ads acusa consentimento ausente porque o gtag sobe antes do banner. Veja como injetar o default denied do…

3 dias atrás

Módulos PHP 8.3 faltando na Saúde do site do WordPress: como instalar

A tela Saúde do site avisa que faltam extensões como intl, imagick ou zip: instale no PHP 8.3, reinicie o…

3 dias atrás

Caso de teste PHPUnit a partir do bug: do relato solto para o teste que falha

Chegou um chamado sem passo a passo e sem exemplo. Veja como virar esse relato em um caso de teste…

4 dias atrás