To avoid a core hack there are two approaches I would suggest you could either create your own Model that would extend UserModelReset
so that you can insert a fake user id when a valid one is not found.
Or create an override for /com_users/view/reset/tmpl/default.php and replace line 24 to not call reset.request in the subcontroller reset.php but some code of your own.
<form id="user-registration" action="<?php echo JRoute::_('index.php?option=com_users&task=reset.request'); ?>" method="post" class="form-validate form-horizontal well">
Or if the plugin you mention is something you can edit then I would suggest you do your own check if the user exists in the com_user table and if not then pass a valid but fake userid to the regular processing, just don't allow a non-existent user to be passed. Not knowing when the plugin gets involved, I can't be sure this is a valid option for you, but would be easiest and cleanest way to do it.
If you follow the process of a normal password reset then you can see what is happening and why the code hack described by @jamesgarret is not working for you and you aren't getting to the final page displayed with the 'email sent' message. I would guess that your Plugin is calling processResetRequest
directly and not going through the subcontroller reset.request.
As mentioned above default.php
calls the subcontrolelr reset.php
and function request
. function request
in turn calls processResetRequest
in com_user/models/reset.php
If you read what is going on processResetRequest
you can see that a database call for the user email address is made and that variable of $userId is returned at line 389.
As per @jamesgarret answer at line 399 a check is done for an empty $userId
and it is at this point that you do NOT want have an empty $userId
. If you used the core hack from @jamesgarret with the normal processing then return true
gets you back to reset.request
but if your Plugin is what called processResetRequest
then you need to handle the redirect to the correct page yourself.
If you haven't already checked and passed a fake user id via your plugin then at line 401 you need to create a valid user id and give it to $userId
so the processing can continue with valid User Id.
(changing line 401 would be a core hack or in an extended processReserRequest)
You have to create a fake user id in your com_user table that isn't a super user and has a valid email address that you can automatically discard when it is received by your mail server/account.
The reason you need this fake user id is so that processing can complete, an email is sent and you get to the bottom of the processResetRequest
so that you get returned to the request
function in the reset
subcontroller. This is what redirects you to com_user/views/reset/tmpl/reset.php
which is the screen you want with the right message that an email has been sent and everything looks genuine.
Incidentally the message you want to appear
"An email has been sent to your email address. The email has a
verification code, please paste the verification code in the field
below to prove that you are the owner of this account."
comes from com_users/models/forms/reset_confirm.xml
and is a fieldset label at line 3.
<fieldset name="default" label="COM_USERS_RESET_CONFIRM_LABEL">