Remove files deleted in 2.1.0 during the module upgrade

[TLabutis]

Problem

A PrestaShop ZIP upgrade overwrites files but never removes the ones a new version dropped. 2.1.0 deletes 46 files, so on every upgraded shop all 46 stay on disk and stay reachable, while a freshly installed shop does not have them.

Two consequences, both observed on a shop that genuinely came through the 2.0.3 -> 2.1.0 ZIP upgrade:

1. controllers/admin/AdminSaferPayOfficialFieldsController.php survives, and PrestaShop's ModuleTabRegister::addUndeclaredTabs() registers a tab for any *Controller.php in controllers/admin/. Pressing Reset on the module brings the obsolete Saferpay Fields tab back. Opening it is a fatal, because the controller reads SaferPayConfig::HOSTED_FIELDS_TEMPLATE, a constant removed in 2.1.0:

   Error: Undefined constant Invertus\SaferPay\Config\SaferPayConfig::HOSTED_FIELDS_TEMPLATE
   

2. Four front controllers survive (iframe.php, hostedIframe.php, successIFrame.php, failIFrame.php). Module front controllers dispatch on file presence, not on a DB row, so all four stay routable. hostedIframe.php and successIFrame.php fatal on removed constants. iframe.php is the real problem: it still reaches CheckoutProcessor with the payment method taken from a request parameter, an entry point that exists only on upgraded shops and is no longer part of any tested flow.

Only an upgrade script can fix this, since a ZIP cannot delete.

Change

upgrade_module_2_1_0() gains three steps next to the existing tab cleanup:

• unlinks an explicit list of the 46 removed paths, then removes the parent directories that become empty
• deletes the obsolete SAFERPAY_HOSTED_FIELDS_TEMPLATE setting, which nothing in 2.1.0 reads
• clears the Smarty cache, so no compiled copy of a deleted .tpl is served

The list is explicit rather than directory based on purpose. views/js/front/hosted-templates/ still holds hosted_fields.js, which live 2.1.0 code loads from src/Presentation/Loader/PaymentFormAssetLoader.php:146, and four of its siblings in that directory are among the removed files. Same situation in views/css/front/ and views/img/. A directory level delete would break the payment form on every upgraded shop.

Testing

On the upgraded shop (PS 9.1.4 / PHP 8.5, 7 existing Saferpay orders, one captured and refunded in three parts). Captured a render baseline, deleted the 46 files, cleared caches, re-ran the same probe. Before and after are identical:

BO order panel (hookDisplayAdminOrderTabContent)
  order 12: OK len=2942 refund=1 capture=1     <- same both runs
FO payment options
  Visa, action=/module/saferpayofficial/validation?saved_card_method=VISA&isBusinessLicence=0
FO asset loader: registered js=2, missing-on-disk=0
hookDisplayCustomerAccount / hookDisplayOrderConfirmation: OK

At HTTP level only the intended endpoints change:

404  /module/saferpayofficial/iframe          <- was reaching the checkout processor
404  /module/saferpayofficial/hostedIframe
404  /module/saferpayofficial/successIFrame
404  /module/saferpayofficial/failIFrame
301  /module/saferpayofficial/validation      <- unchanged
301  /module/saferpayofficial/return          <- unchanged
301  /module/saferpayofficial/notify          <- unchanged
301  /module/saferpayofficial/creditCards     <- unchanged

On the script itself. Reproduced the ZIP upgrade on disk (2.0.3 tree with the 2.1.0 ZIP copied over it, 1403 files), then ran upgrade_module_2_1_0() against it:

before: 1403 files
after:  1357 files
diff vs clean 2.1.0 ZIP (files):       IDENTICAL
diff vs clean 2.1.0 ZIP (directories): IDENTICAL

An upgraded shop ends up structurally indistinguishable from a fresh install. Idempotent, verified by running it twice more with no warnings or notices under E_ALL. hosted_fields.js and the module root are untouched.

php -l and php-cs-fixer --dry-run clean. phpstan does not scan upgrade/.

Notes for the reviewer

• Existing order data is untouched, the change is file only. Orders created through the old iframe flow still resolve, because PaymentType::HOSTED_IFRAME, PaymentTypeProvider and controllers/front/return.php:115 all still ship in 2.1.0. Only the entry point files are gone, not the handling of the stored value.
• The unlinks use @unlink, so a file the web user cannot delete is skipped and the upgrade still succeeds. Failing the upgrade over a leftover file would roll the version back, which is worse. The tradeoff is that on a shop with locked down file permissions the orphans survive and this fix silently does nothing.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.