I am trying to:
Provide a page containing the password reset shortcode, where the user can enter a new password twice and confirm.
1) On entering an email address and clicking the "Get New Password" button, the following is shown on the page. "Check your email for the confirmation link."
2) The email is sent to the user.
3) The link in the email opens a browser on our reset password page.
4) User can enter a new password twice and confirm, however this always errors out with the following error:
"ERROR: Your password reset link appears to be invalid. Please request a new link."
I am following documentation from:
https://toolset.com/documentation/user-guides/building-the-my-account-page/
(We have made a slight deviation from the documentation in that we are not using Toolset Layouts for the Login form, rather a separate WordPress Page "Login" to show the Login form. We control who accesses the Account page and/or the Login Page with two Toolset Access Post Groups, "Logged In Users" and "Guest Users". This part also seems to be working successfully and is separate from the "Reset Password" functionality, but I thought I'd mention it.)
Link to a page where the issue can be seen:
hidden link
I expected to see:
The user being redirected to our "Password Reset Successfully" page.
Instead, I got:
ERROR: Your password reset link appears to be invalid. Please request a new link
The password remains the same as the original, ie no password changing is happening in the back end.
We have also included the subdomain *.native-nanny.com under
Toolset > Settings > Front-end Content > Safe Redirects
If you want to reproduce the error, please feel free to create yourself as a Native Nanny on the following page:
hidden link
and then try to reset your password here:
hidden link
Hi, I think the issue here was related to the use of the /en directory for the default language in WPML. Some of the redirection URLs that were used in these shortcodes included the /en directory, others did not. I edited each of the pages in this process and updated the URLs as needed, then tested again. I was extra careful to use different browsers for testing and for monitoring wp-admin with the support account...that's easy to trip over. This time my password was reset successfully.
Can you completely log out of all sessions in all browsers, then test again by creating a new Nanny? Let me know if it's still glitchy for you and I can take another look.
Hi Christian
I suspected it might have to do with the /en which was added from WPML. I managed to reset a password successfully for another an account.
Now my question is, will this work in other languages if the /en is "hardcoded" into the URL?
Surely it must be possible to use some kind of variable to retrieve the site base URL, otherwise we are gonna face deployment problems anyway when we move from eg dev.native-nanny.com to test.native-nanny.com?
What are the recommendations here in terms of writing URLs in such a way that these are easily deployable/portable, especially with the added consideration of our multilingual site?
Thanks and regards
Simon
Now my question is, will this work in other languages if the /en is "hardcoded" into the URL?
It depends on how you plan to translate (or not translate?) these pages into other languages. My guess is that you'll translate the /en/lost-password page into other languages like /es/contrasena-perdida and /de/passwort-verloren...is that correct? If so, then when you translate the content, you should translate the shortcodes as part of that content. The relevant URLs will be different in each language. Spanish translations will use /es/, German /de/...so the hard-coding will still exist, but it will be set per language.
If not, then I would need more information about how the different language login and reset password processes work, with the relevant URLs.
Surely it must be possible to use some kind of variable to retrieve the site base URL, otherwise we are gonna face deployment problems anyway when we move from eg dev.native-nanny.com to test.native-nanny.com?
Even if you had a shortcode that would provide the base URL, the login form and reset password shortcodes don't accept other shortcodes in the URL attributes. You can only use plain-text, full, absolute URLs. Does your site migration process not automatically find-and-replace environmental domains written out in post content? If it does, then the process should handle this automatically, since it's essentially replacing text strings in content. If not, then it might be possible to render a different set of shortcodes per environment using HTML conditionals. Let me know if that backup solution is needed and we can discuss some options.
Hi Christian
Thanks for the helpful response. In answer to your question:
Q) My guess is that you'll translate the /en/lost-password page into other languages like /es/contrasena-perdida and /de/passwort-verloren...is that correct?
A) Yes, that's how we plan to go. I understand that each page will have a different URL in each case due to the languages. However all the languages will share the same common root URL of hidden link.
If we then want to deploy all our work to hidden link, do we have to do a search and replace through the entire file system to replace all instances of "hidden link" with "hidden link"?
I guess my question is a general one now on the best way to deploy a site from dev to test. We are still working on DEV and aren't yet ready to move to TEST, but since Toolset development is so fast ;-), we aren't far away from that yet and will have to start experimenting with doing incremental deployments from DEV to TEST to mirror real-life production deployments.
1) Does Toolset have any tutorials or guides on how to migrate from one environment to another, eg Dev to Test?
2) Is this normally handled with plugins and if so, does Toolset favour any in particular over others?
3) Are there any particularly special considerations we need to be aware of or guidance from Toolset, considering we are also using WPML? (I presume the WPML deployment is handled with custom .mo files?)
Thanks and best regards
Simon
If we then want to deploy all our work to hidden link, do we have to do a search and replace through the entire file system to replace all instances of "hidden link" with "hidden link"?
Well I was asking you specifically about content in the database, but the file system is another part of the migration process that must be considered as well. Only someone familiar with your site migration process knows what must be done manually and what the migration process automates for you.
In a normal WordPress / Toolset setup, only one file on the server includes domain-specific code: wp-config.php, a WordPress file that holds key configuration information. There are no domain-specific files in Toolset plugins. If your site includes Toolset custom code snippets (added in Toolset > Settings > Custom Code), then you would have to consider those snippet files during migration and modify any included domains as needed. If your site uses a custom theme, then you would also have to consider those files during migration, as well as any custom plugins or other custom code added to the file system.
1) Does Toolset have any tutorials or guides on how to migrate from one environment to another, eg Dev to Test?
Nothing specific to site migration I can think of, other than some information about how to handle registration and site keys when you only have one license and multiple test environments (only register in the production site, then update the plugins manually in any other environment).
2) Is this normally handled with plugins and if so, does Toolset favour any in particular over others?
It's handled in many different ways - plugins, custom bash scripts, deployment engines, git processes...but usually a plugin is sufficient. Toolset doesn't lend itself to one or the other migration plugins. Our support team typically uses a plugin called Duplicator to clone a client's site and migrate it to a local test environment. The software automatically replaces domain names during migration, including the file system and the database. Another plugin we frequently use as a backup to Duplicator is All-in-One WP Migration. Both offer free versions.
3) Are there any particularly special considerations we need to be aware of or guidance from Toolset, considering we are also using WPML? (I presume the WPML deployment is handled with custom .mo files?)
Nothing exceptional I can think of offhand. Do not "find-and-replace" on a database dump file using a text editor program. That might seem like an easy fix, but you will most likely break serialization in the database and crash the site.
My issue is resolved now. Thank you! Another 5* 🙂
