Best practice for replacing the password_forgotten email (No hook/trigger available)?

[Blaine]

Hello everyone,

I am working on unifying all of our store's emails into custom HTML Notification Modules. I successfully did this for Order Confirmations and Account Creations, but I have hit a roadblock trying to replace the native password_forgotten.php email.

In the core password_forgotten.php root file, the $reset_key is generated, saved to the database, and the plain-text email is sent via Notifications::mail() all in one hardcoded block.

Because there is no $hooks->call or native module trigger broadcasted for this specific email, my standard Notification Module cannot "hear" the event to take over.

I tried two approaches, but neither feels like the correct "Phoenix Way":

Page Override: I tried placing a modified copy of the controller in templates/override/includes/pages/password_forgotten.php. However, because it's a root file, doing this causes application_top.php to load twice, resulting in a fatal wall of "Constant already defined" errors.

injectAppTop Hook: I can successfully hijack the $_POST['action'] == 'process' submission using an injectAppTop hook, generate the reset key myself, send the HTML email, and redirect the user before the core file runs. This works, but duplicating the core logic in a hook feels heavy.

My Question:
What is the recommended, upgrade-safe method for intercepting or overriding the password_forgotten.php email block to send an HTML template via a notifications module, given that it lacks a native trigger?

Thank you in advance for the guidance!

[ecartz]

injectAppTop Hook: I can successfully hijack the $_POST['action'] == 'process' submission using an injectAppTop hook, generate the reset key myself, send the HTML email, and redirect the user before the core file runs. This works, but duplicating the core logic in a hook feels heavy.

This is what's available now.

Beyond that, migrate the page to use a notification module like the others. Submit to core as an upgrade (pull request). Then the core change will be in core and safe from updates. Once it's a notification module, you have all the normal tools to override notification modules. You'd probably still have to duplicate the logic to make it work, but now you're duplicating a module rather than copying into a hook.

There are basically two reasons why I never did that. First, this is a low value email. I'm not sure that it makes sense to do it in HTML. In particular, the security worries of someone sending a spoofed email seem stronger than the advantages of better formatting. Second, I just never got around to migrating it to notification modules.