@cilefen It wasn't translation related.
But it is, the settings form is multilangual and you can prefix the rest api's with your langcode to get the messages and the email that gets send in the right language. Also the module assumes this works in the same way in the frontend app, so it also prefixes urls on the frontend with the current langcode. For our implementation this was sufficient, but I can imagine this may not be the case for all decoupled websites, so if there is demand for a more flexible setup I can implement that.
I'm a dutch native normally and I would have provided dutch translations for all strings in the module, but translations go through localize.drupal.org so I can only suggest them and not much more. But besides this you can translate everything the module provides though the normal interfaces in the Drupal cms.
You should provide a frontend uri under: /admin/config/services/rest-password-reset
This is a required setting but it's left intensionally empty on install as it would be hard to guess what the value should be on decoupled websites.
I could provide a more meaningful error on this particular error condition though.
I'm a bit uncertain what test case(s) to add since a html5 date form element does not seem to accept an invalid date. Also I found yet another flaw that since then appears to have been fixed already: both regcode_create_number and regcode_create_case need to be typecasted as integer and boolean for the code to work. You could argue that "create number" should be a number then for it to not be passed as a string, but I don't think that would be very user friendly. That is I dislike html5 toggle up/down elements :)
Please let me know if this still needs work with test cases.
Also a bit offtopic but still relevant: for 2.0.0 the patches are piling up, when can we expect another stable point release?
Thanks, you are right. Forgot the default part :$ As in admin/structure/types/manage/{CT}/form-display/default/translate. It does indeed seem to work if we have group fields that are translatable.
Latest 11.x patch rewritten for 10.3.1
@nginex that is a very strange fix, tried it but it didn't work for me. Almost would say glad about that: if we are supposed to hand roll yet another patch to get this to work it really doesn' t sound like the right way. How are we supposed to maintain that?
So I would say the latest patch for 11.x doesn't work anymore. I re-applied it against 10.3.1 and it does apply cleanly but all I end up with are 403's
TY, funny part is the last Xss:filter's were put there by me after an internal code review :) I released 1.1.4 with your comments applied.
@vishal.kadam Thank you, fixed in the latest minor update.
I've added a disclaimer to make the difference between te 2 more clear. The main difference is we use a email with a password reset link to points to the decoupled website (configurable) and the decoupled website is supposed to then provide a password change dialog that POST's to a second REST endpoint in Drupal. The password link uses the same algoritm as Drupal does for the one time login code. That is: it's based on the user password and has an expire time, so if either changes or becomes invalid it doesn't work anymore.
Good point, added a disclaimer.
Was wondering about this myself, merged! TY!!
We took a different approach in this one since we have a decoupled website and had some options you would normally not have on plain Drupal.
But for others looking at this one: as it turns out CF simply uses the name of the field type in its plugin naming suffix. Entity_automcomplete for example :)
Rerolled against latest dev