As mentioned in my previous comment, sub theming doesn't work as it breaks a ton of the styles. If I was fluent enough in theming I wouldn't be looking for a contrib theme or asking if the theme could support subtheming.
Yes, I can confirm that using '#default_value' on form rebuild does NOT work. Printing out the value of the entitys field during the 'back' process prints the correct value, but using that in #default_value returns null (The value it originally was before the user entered information into it).
This is the reason I was using setUserInput() to begin with, because the #default_value was being ignored on form rebuild.
Yeah I was playing around with it a bit today, and got most of this implemented. The thing I am still struggling with though is the #default_value being replaced correctly on rebuild.
Example if the #default_value on initial build is set to 'test value' (based on the entities value), and the user changes the value to 'test value 2' and clicks next, which sets the entities value to 'test value 2' when I click the 'back button' (which triggers $form_state->setRebuild()), the #default_value is still 'test value' and not 'test value 2'. For some reason rebuild is ignoring the #default_value parameter on rebuild.
Thanks, by the way, for that much easier approach to handling multi-steps. Much easier to work with and works nicer with add/edit forms when they are the same form.
That's an interesting concept that I am interested in. A few questions I have are:
- How are you saving the entity to the form state? Via $form_state->setStorage()?,
- and you are able to do that in the formBuild()? I wasn't aware you could alter the form state in that method.
- How are you re-applying the value to the form element itself? When I am attempting to use #default_value in my ajax form, it only applies the first time the form is built. The second time (after $form_state->setRebuild() is called (example, clicking back) or subsequent rebuilds, it doesn't update the value of what is in #default_value on the form. (it only uses whatever the initial value was when the form was first built.) How did you overcome that?
Even with this patch in place, I am still getting the same error message related to using 'guess' as the method name.
@mingsong I am not sure I entirely agree with this.
The 'send' button is only rendered if email is setup as otp anyway (even with application code as well), so surely there's a way to trigger the automatic email if 'only' email otp is enabled. This is not only a user experience improvement but also a pretty standard practice.
At the very minimum, adding in some messaging on the page to indicate the user must first click 'send' to receive the code should be considered as receiving the code automatically via email is a pretty standard practice in TFA, and without some messaging indicating users need to click it to even receive the first code isn't very use friendly.
Would a better solution be to just send the verification code when the TFA activation form is first displayed?
Seems counter-intuitive to have to click 'Send' first when you typically get the code sent automatically.
@ja09 That's correct. I can send the sendgrid test email, and all of the default system emails (password resets, etc) all go through, but any other emails not generated by Drupal core (like from other modules, or from custom modules), all throw the same error.
I did some debugging, and I temporarily added a print statement where the Assertion happens at (in vendor/fastglass/sendgrid/src/Mail/emailAddress.php), and it's printing the email address field twice, with no space and no commas between them. (e.g. test@example.comtest@example.com) on the PHP error page.
Uploading a new version of the patch.
Our team has been working on this for our own project and are sharing what we did.
I for some reason did not get notifications of this new issue. I will look at this. Thank you for reporting.
BUMP. Checking in on the status of this. Aside from having to increase the number of remembered devices to a really high number (and therefore making remember device limit pointless), there is no way to forget remembered devices for users. When the limit is reached, they are no longer asked to remember any more devices.
jfurnas → created an issue.
All set. The licensing and *.info.yml information has been removed.
Hi! I had sort of bypassed the queue since there are already two issues in there that the maintainer/owner has not addressed in over a year. Felt it was pointless to post in the queue when it's not monitored.
Can I get a bump on this please? This has become an extreme burden as we are doing active development and keep getting our emails rerouted numerous times a day because config_ignore is not ignoring the settings and is instead changing them.
I can confirm that today, running Drupal Core 9.5.9 that I start seeing this issue immediately after a cache clear whenever I view a page that loads or uses entities. This is the error I am receiving as of today:
Warning: Undefined array key 1 in Drupal\Core\Entity\EntityDisplayRepository->getAllDisplayModesByEntityType()
Check your settings.php file. It looks like setup didn't write the settings.php file correctly or you have a module somewhere that's changing the database.
This has been pushed into the main release so I am going to mark this resolved.
Uploading the patch to remove the unneeded lines.
I am running PHP 8.1 and using the latest version of sendgrid_integration (with the above patch included in it), and I am receiving the same error message, except it's not returning the 'to' address. I can replicate it across all emails being sent in the system (both custom emails and system emails)
Thanks for the reply JayPan. Do you have an example of this? I have custom JavaScript in place via an attached library, but the JavaScript file runs only once so once I submit and the Ajax runs (which is when the validation happens), it doesn't re-attach/run the JavaScript.
@shrishail-hiremath,
Thanks for the response. I can confirm that I am running the most up to date version of the module. Weirdly enough though, it seems to be working now.