Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When importing configuration on site without password_policy activated, I'm getting this error
[error] InvalidArgumentException: Field field_last_password_reset is unknown. in /var/www/html/cnas/core/lib/Drupal/Core/Entity/ContentEntityBase.php:471
How to reproduce:
1. Install password_policy
2. Export config with drush config-export
3. Uninstall password_policy
4. Import config with drush config-import
Issue fork password_policy-2771129
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
_claude_ CreditAttribution: _claude_ commentedComment #3
Yury N CreditAttribution: Yury N as a volunteer commentedFacing same issue. Looks like problem is in updating users in password_policy_install()
When using config import fields are not created at this moment.
Comment #4
kbentham CreditAttribution: kbentham commentedThis patch removes the install file and updates existing users with cron.
Comment #5
kbentham CreditAttribution: kbentham commentedThe password expiration boolean also needs to be set.
Comment #6
nicrodgersI'm not sure the approach in #5 is right, but I'm no config expert so happy to be corrected.
For now, as a temporary workaround, to deploy this through our dev/stage/prod environments, I added a hook_update call in one of our custom modules to install the module. drush updb should be called before drush cim, so this avoid the problem.
eg.
Comment #7
nicrodgersStill an issue in 3.x-dev.
Comment #8
james.williams CreditAttribution: james.williams at ComputerMinds commentedA better approach would be to remove the field_last_password_reset and field_password_expiration fields (and potentially any other config shipped by password_policy that doesn't make sense without the module around) in a new hook_uninstall for the module.
Comment #9
merauluka CreditAttribution: merauluka at Mediacurrent commentedI believe this is related to a fundamental difference in core between enabling a module manually and importing it via config.
See #2766859: Module's config files are not installed during config import.
When a module is installed during configuration import, its default configuration from config/install is not imported. This is because config import is relying on settings that are in the sync directory. And those settings will not necessarily be available to hook_install.
It would be better to move the field definitions into hook_install if the are going to be required at that point during the installation process.
I would be happy to provide that patch.
Comment #10
merauluka CreditAttribution: merauluka at Mediacurrent commentedHere is a patch that appears to resolve to error on my system.
Comment #11
nerdsteinMoving to needs review to kick off tests
Comment #12
nerdsteinCode review comments:
1. How does this behave upon uninstall? Do the fields remain? If so, we need to add a config dependency to password policy such that if the module gets uninstalled, the config does as well.
2. Looks like the patch in #10 does not apply cleanly. I think it's because of the header that the file starts with. The following code can likely be removed:
Moving back to "needs work"
Comment #13
merauluka CreditAttribution: merauluka at Mediacurrent commentedThe patch applied cleanly for me against a copy of the latest 3.x-dev branch. I tested it both with composer-based patching and with manually applying the patch via the command line. Both times worked correctly.
The header of the patch file is not the issue.
Moving back to needs review.
Comment #15
merauluka CreditAttribution: merauluka at Mediacurrent commentedThere appears to be a file that was supposed to be removed and isn't.
Working on a new patch now. Stay tuned.
Comment #16
merauluka CreditAttribution: merauluka at Mediacurrent commentedI took a different approach this time around. Based on the "TODO" in hook_install, offloading the setting of the initial field values was something that needed to be done anyway. So I moved that into a queue, preserving the provided YAML files.
I also added field clean up and queue clean up into a hook_uninstall which appears to be working well now.
Queueing patch for testing.
Comment #17
merauluka CreditAttribution: merauluka at Mediacurrent commentedThat wasn't a clean patch. Here's a better one.
Hiding bad patches and queueing for testing.
Comment #22
acbramley CreditAttribution: acbramley commentedFixed the tests by applying the same form display config to the test.
Comment #23
nerdsteinI like this approach a lot. Thanks to all of you that have contributed.
Code review comments on latest patch:
1. Seems to be a copy pasta error: "SalsifyContentImport" seems off to me in the patch.
2. The queue-based approach - does this deprecate the "cron_threshold" setting? Should we remove it? Can the threshold be configured into the queue somehow (annotation?).
3. Shouldn't items be added to the queue during hook_cron to continue to check for accounts that need their password reset? Or, is the queue only useful for install?
4. What is the timing ramifications? If a ton of existing users are added on module install, will there be a delay in which a user's reset config may not be set? Has this been tested?
Moving this back to "needs work" (notably for item 1 and for considerations of items 2-4)
Comment #24
merauluka CreditAttribution: merauluka at Mediacurrent commented@nerdstein
Comment #25
merauluka CreditAttribution: merauluka at Mediacurrent commentedThis section in
password_policy_cron
bothers me still. This doesn't seem like a good way to go since it could cause memory errors just in loading all of those user account objects.This could easily be thrown into a queue as well.
Comment #26
merauluka CreditAttribution: merauluka at Mediacurrent commentedHere's a first look at that queue operation for cron jobs.
I also added a configuration form that allows it to be toggled on and off and allows the user to set the number of accounts to process per cron run.
Comment #27
acbramley CreditAttribution: acbramley commentedSwitching the existing cron implementation to use a queueing system should be a separate issue entirely, it has nothing to do with fixing the installation of the module.
Comment #28
nicrodgersRe the comment in #25 about cron, this has recently been fixed in #2836453: Cron hook exhausts memory when there is a large dataset of users, and I agree with #27 that the scope of this issue should be contained. Further follow-up issues can be created where necessary.
Comment #29
merauluka CreditAttribution: merauluka at Mediacurrent commentedSounds good to me.
Changing this to Needs Review to kick off testing.
Comment #33
merauluka CreditAttribution: merauluka at Mediacurrent commentedSince the last test succeeded on the patch, could we get some people to test?
It would be great to get this into RTBC.
Comment #34
mikemadison CreditAttribution: mikemadison at Acquia commentedseems to fix my problem. thanks for the patch!
Comment #35
Sophie.SKI had some difficulties applying the patch against latest stable because of missing comments, but the patch worked. My config imported and the module installed. Thanks for the work!
Comment #36
yobottehg CreditAttribution: yobottehg commentedhere's a reroll against latest dev.
Comment #38
robpowellLet's give this patch a go
Comment #39
atackett CreditAttribution: atackett commentedThe latest patch was successful for me.
Comment #40
merauluka CreditAttribution: merauluka at Mediacurrent commentedThe latest patch removes the queue worker classes from the patch. It still needs those queue workers in order to process the password policy queue.
I'm hoping to be able to update it later today unless someone else jumps in.
Comment #41
robpowell@merauluka, I took #27 as saying that the queue should be outside of this patch.
Comment #42
merauluka CreditAttribution: merauluka at Mediacurrent commented@robpowell, Ah. I see. I read it a bit differently. I had started moving a few other things into queues as well, but you're right. I believe #27 was talking about the queue system as a whole. I've create a feature request for that.
#2897274: Process initial password policy settings via Drupal queue system
Comment #43
robpowell@merauluka great I'll review when you get a patch ready.
Comment #44
douggreen CreditAttribution: douggreen at Appnovation for Pfizer, Inc. commentedA simpler solution is to create the fields with hook_entity_field_info() instead of config and leave the hook_install() update alone.
Comment #45
douggreen CreditAttribution: douggreen at Appnovation for Pfizer, Inc. commentedUpdated patch includes an update handler to remove the existing field config.
Comment #46
jribeiro CreditAttribution: jribeiro for Pfizer, Inc. commentedAnother possible approach without having to change the current fields and the user entity is skip the hook_install if is config is syncing (
!\Drupal::isConfigSyncing()
) and implement a new event subscriber forConfigEvents::IMPORT
to handle the new user fields values.Comment #47
jribeiro CreditAttribution: jribeiro for Pfizer, Inc. commentedHere is the patch for #46
Comment #48
mirsoft CreditAttribution: mirsoft commentedI can confirm the patch in #47 works for me, thanks for posting! I saw the similar pattern in another modules (e.g. lightning).
Comment #49
l0keRe-rolled against latest 8.x-3.x-dev.
Comment #50
vijaycs85+ 1 to skip with isSyncing() approach as core modules (shortcut, forum) have it. In fact isSyncing() added for this reason.
Wondering why just the fields reset part of hook_install here. If the module is getting enabled as part of config import, we wouldn't get the entity_form_display as well, no?
Comment #51
thaeez CreditAttribution: thaeez commentedFWIW, I ran into this issue. Patch from 49 applied cleanly, but did not fix the error on config import. To fix, I disabled the module with drush, then flushed caches with drush and manually re-enabled the module from the Drupal admin UI. Ran config sync and everything is working now. Hope this helps someone down the road.
Comment #52
Brolad CreditAttribution: Brolad at Skilld commented#49 works fine for me, thanks!
Comment #53
kmoll CreditAttribution: kmoll at Appnovation for Pfizer, Inc. commentedI can confirm that that path from #49 applied cleanly and fixed the problem.
Comment #54
kmoll CreditAttribution: kmoll at Appnovation for Pfizer, Inc. commentedComment #55
davidburnsI'm having the same issue as #51
Comment #56
gambry+1 for #49. Ideally not the best solution, but bug is quite annoying and there is no workaround (so setting priority to major).
Worth mentioning doing this as a batch process will improve performances on website with lot of users. Also heads up for #2901418: Add hook_post_config_import_NAME after config import because when it's in we should improve this code again.
@vijaycs85 entity_form_display config entities will be nicely imported as part of the import process. We don't make use of them yet, so it doesn't matter the order they are installed in.
Couldn't reproduced the issue mentioned by #51 and #55.
Comment #57
jasonawantHi,
Patch in #49 didn't apply cleanly to latest 8.x-3.x-dev b/c of commit a96e772677761c68faf82734e45940afb1064fec
Here's a re-roll against latest dev.
Comment #58
gambryAll looks good. Thanks!
Comment #59
vijaycs85Thanks, @gambry. Let's get this in. +1 to RTBC.
Comment #60
knyshuk.vova CreditAttribution: knyshuk.vova at Internetdevels, Drupal Ukraine Community commentedConfig import works without any errors after applying the patch from #57 . Thanks!
Comment #61
jeroendegloire CreditAttribution: jeroendegloire at Calibrate commentedLatest patch works fine.
Comment #62
c_archer CreditAttribution: c_archer as a volunteer and commentedConfig import works as expected after applying the patch from #57
Comment #63
bisonbleu CreditAttribution: bisonbleu commentedOn a large website with many users, I noticed that simply enabling password_policy locally takes FOREVER to complete and can lead to a WSOD.
Unfortunately, the patch in #57, although it fixes the
Field field_last_password_reset is unknown
issue, does not address/resolve this critical memory issue. CircleCi is unable to finish its job within the allocated memory and delivers a FAILED on every build, making it impossible to use this module. See error below.On the other hand, the patch from #2897274: Process initial password policy settings via Drupal queue system fixes both of these issues.
Setting back to needs review in order to re-open the discussion and get some feedback/guidance.
Comment #64
gambryHi @bisonbleu, I think https://www.drupal.org/project/password_policy/issues/2897274 is already addressing this issue so this can be set back to RTBC as it's trying to fix another bug and not the low performance enhancement?
Comment #65
bisonbleu CreditAttribution: bisonbleu commentedHey @gambry, all good, I got my related/overlapping issues mixed up.
p.s. It is #2897274: Process initial password policy settings via Drupal queue system and #2983448: Refactor hook_install logic to expire passwords for existing users that are related and try to resolve the memory issue.
Comment #66
dallashudgens CreditAttribution: dallashudgens commentedI used the patch from #57 which passed my Travis deploy to my development environment. However, when trying to do a configuration sync, on import, I get this error
InvalidArgumentException: Field field_password_expiration is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField() (line 586 of core/lib/Drupal/Core/Entity/ContentEntityBase.php)
Is this related? or a new issue?
Comment #67
gambry@dallashudgens when enabling the module manually (or through drush/drupal console) the field is created as part of the installation process.
When the module is installed as part of config import, the relative config entities should be existing in the sync storage and so imported as part of the process.
Are field.field.user.user.field_password_expiration.yml and field.storage.user.user.field_password_expiration.yml in your sync folder?
Comment #68
dksdev01 CreditAttribution: dksdev01 as a volunteer and commentedI am using patch #49-D8 and looks fine so far.. thanks
Comment #69
geerlingguy CreditAttribution: geerlingguy at Midwestern Mac, LLC commented+1 to RTBC on patch in #57; testing with 8.6.1, and it's the only way I can get a project that's managed with Acquia BLT to be able to be reinstalled from exported configuration.
The hook_install() in its current state assumes that you won't be reinstalling the module on a site built from existing configuration over and over again, and the patch in #57 seems to fix that assumption and allows me to reinstall my site as needed.
Comment #70
raileanu.nalexandru CreditAttribution: raileanu.nalexandru as a volunteer commentedHere is an adaptation of the patch from #57 for the alpha3 version in case anyone else finds himself in the case.
Comment #71
claudiu.cristeaRTBC++
Comment #72
PieterDCPatch from #57 gets rid of the error message.
I'm a bit concerned about the possible performance impact by updating all users. Imagine sites with thousands of users.
I did not need the alpha3 version of the patch (see #70). I'm on alpha4.
Comment #73
alejomc CreditAttribution: alejomc as a volunteer commentedTaken #70 for alpha4
Comment #75
drupalninja99 CreditAttribution: drupalninja99 commentedI am having trouble getting the patch to apply in Composer. I keep getting "Invalid argument supplied for foreach() " even though patch 57 applies for me when I have 3x checked out. I am going to re-post the patch from a git diff to see if it makes a difference.
Comment #76
texas-bronius CreditAttribution: texas-bronius commentedThank you @drupalninja99: I experienced the same issue (composer install, drush cim, see "Field field_last_password_reset is unknown"), added your rerolled patch in #75, repeated, and all installed beautifully.
Comment #77
gambryCompared #57 with #75 and all looks still good.
Running the tests to see if #75 applies nicely.
Comment #79
AohRveTPV CreditAttribution: AohRveTPV commented#75 passes tests now that we've fixed some other, unrelated causes of test failures. Needs review.
Comment #80
daniel.bosenAnother re-roll against current 8.x-3.x
Comment #81
volkerk CreditAttribution: volkerk at Thunder commentedAdd test for scenario in summary
Comment #82
AohRveTPV CreditAttribution: AohRveTPV commentedReviewing #80 and #81.
1. Why is
$timestamp
set in a different way betweenhook_install()
andonConfigImport()
?hook_install()
:$timestamp = \Drupal::service("date.formatter")->format(\Drupal::time()->getRequestTime(), "custom", DATETIME_DATETIME_STORAGE_FORMAT, DATETIME_STORAGE_TIMEZONE);
onConfigImport()
:$timestamp = gmdate(DATETIME_DATETIME_STORAGE_FORMAT, REQUEST_TIME);
2. When I attempt to run just the test provided by #81, I get an error. Am I doing something wrong?
Comment #83
AleRinaldi CreditAttribution: AleRinaldi commentedHello,
actually the patch in #81 (and many of the previous ones) breaks the setup if made from configuration.
For example, if I set up my site with the config_installer profile, or if I enable the module by importing a configuration update where I add "password_policy" in core.extensions.yml, the setup will fail because it won't find the new fields.
The solution in #45, for example, seems to be better because it works in this scenario.
Comment #84
AohRveTPV CreditAttribution: AohRveTPV commentedThe following warning is reported by the DrupalPractice PHPCS standard for #80/#81:
The offending line is:
Comment #85
rcharant CreditAttribution: rcharant as a volunteer commentedI have removed the fields 'field_password_expiration' and 'field_last_password_rest' using drush first and the import succeeded.
Use
drush eval 'field_delete_field("field_password_expiration")'
anddrush eval 'field_delete_field("field_last_password_rest")'
to remove the fields and then rundrush config-import
.Comment #86
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedHere is a re-rolled patch based on : https://www.drupal.org/project/password_policy/issues/2771129#comment-12...
EDIT: Please ignore this patch.
Comment #87
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedComment #88
navneet0693 CreditAttribution: navneet0693 as a volunteer and at QED42 commentedRunning this hook_update and then doing drush cim saved my world.
Comment #89
james.williams CreditAttribution: james.williams at ComputerMinds commentedComment #90
james.williams CreditAttribution: james.williams at ComputerMinds commentedI'd advocate for a version of the patch from comment 45. Though any data in the existing fields should be migrated into the new base fields.
As navneet0693 says, DB updates must be run before any config import. For anyone installing from config, that config must be exported from a source installation after DB updates are run too. This is standard practise for any config management - the database needs to be in the right shape before any import/export config operations are run. Otherwise Drupal cannot rely on its known schema for config.
Other approaches that install the existing fields when password_policy is installed, need to ensure the fields are correctly uninstalled when the module is uninstalled too. I haven't seen a working version of that yet either.
Comment #91
anairamzapReroll patch from #81 for latest Dev (8.x-3.x was updated on 28 Jun 2019)
Comment #92
alejomc CreditAttribution: alejomc as a volunteer commentedCreated this for alpha5 based on last patches.
Comment #93
alejomc CreditAttribution: alejomc at Globant commentedupdated patch
Comment #94
DamienMcKennaI rerolled the patch, and fixed some minor coding standards issues.
Comment #95
AohRveTPV CreditAttribution: AohRveTPV commentedVersus #94:
- Committed unrelated
hook_update_N()
documentation fix: https://git.drupalcode.org/project/password_policy/commit/de2b0e9. (Thanks, Damien.)- Removed some trailing whitespace.
"Needs work" because this patch introduces a PHP_CodeSniffer warning (per #84):
Comment #96
shrop CreditAttribution: shrop at Mediacurrent commentedMarking critical as a note to get this in the next release.
Comment #97
tomasdev CreditAttribution: tomasdev commentedI've been applying @anairamzap patch for a couple times already... any timeline on when this gets released?
Comment #98
AohRveTPV CreditAttribution: AohRveTPV commentedtomasdev, thanks for reporting that the patch is working for you. The patch in #94 has at least one issue and still needs work per #95.
Comment #99
pfrenssenI don't think this is a good idea:
On complex sites with many users this operation can take a very long time, I can imagine 30 minutes or more. This would increase the downtime too much for deployments. More likely even, this would cause the process to run out of memory, causing the deployment to fail with a fatal error.
A better way to approach this is to perform a simple update query, which will take care of this operation in less than a second even if there are hundreds of thousands of users.
Comment #100
mtorresn CreditAttribution: mtorresn commentedPatch in #95 works but is based on the 8.x-3.x branch and doesn't match with the 3.0.0-alpha5 module version code (latest release so far) Updating this patch to be applied to 8.x-3.0-alpha5.
Comment #101
scotwith1tPatches are always against the latest dev version. If you want to re-roll it to apply to a specific release, you're certainly welcome to do so and post here for others who might want it, but the latest patch against dev in #95 should still be the one shown on this issue until a newer patch against dev which addresses any outstanding concerns (like @pfrenssen's in #99) is provided.
Comment #102
loopy1492 CreditAttribution: loopy1492 commentedI can confirm that the patch has some whitespace issues...
Comment #103
aleevasIn this patch provided fix for failed apply from #100
Comment #104
aleevasTrying to fix my latest failed patch
Comment #105
joestewart CreditAttribution: joestewart at Mediacurrent commented#104 still had the following error message while #95 was successful on a drush site-install with config imported from a profile.
InvalidArgumentException: Field field_last_password_reset is unknown. [error]
Status is already "needs work".
Comment #106
j3ll3nlSame here. On installing from config with drush it still throws the same error.
Comment #107
DamienMcKennaPatch #95 is the correct one to use for now.
Comment #108
wells#2983448: Refactor hook_install logic to expire passwords for existing users has a patch that would resolve this as it removes the user stuff from Password Policy's install hook. Adding it as related.
Comment #109
bmunslow CreditAttribution: bmunslow as a volunteer commentedIf, like me, you need a hot patch for
password_policy 8.x-3.0-alpha4
because your stuck toctools 8.x-3.0
for the moment, then this is the patch to useComment #110
Nigel CunninghamHere's an updated patch against current dev that fixes the outstanding use of \Drupal.
Comment #111
chr.fritschDATETIME_DATETIME_STORAGE_FORMAT is deprecated and should not be used anymore
Comment #112
wellsSee #2983448: Refactor hook_install logic to expire passwords for existing users for a patch that also resolves this issue and does not use
gmdate
or deprecated global constants.Comment #113
pfrenssenWe should block work on this until #2983448: Refactor hook_install logic to expire passwords for existing users is fixed. We are duplicating code from the install hook which has a performance issue. This code is being removed in that issue. Let's pick this back up once the install hook is cleaned up so we don't risk to reintroduce the performance issue.
Comment #114
suzymasriPatch updated to fix
DATETIME_DATETIME_STORAGE_FORMAT
andREQUEST_TIME
deprecations.Comment #115
nerdsteinI'm marking this as fixed thanks to the work performed in #2983448, comment 21 which had overlap and has been merged.
Giving everyone credit for all of their contributions to this longstanding issue. Thanks
Comment #116
piggito CreditAttribution: piggito as a volunteer and at Skilld commented@nerdstein On current dev branch I'm still getting the error when installing a site from a config export directory. This patch is fixing the issue for me so I believe this might still be needed.
Comment #118
PCate CreditAttribution: PCate commentedSame as @piggito I ran into this error when installing from config. Patch #114 worked for me.
Comment #119
jor_kai CreditAttribution: jor_kai commentedSame as @PCate and @piggito. Ran into this issue while attempting to import config on a new environment. The patch in #114 worked for me.
Comment #120
sonnyktConfirming that patch #114 works.
Comment #121
rkent_87 CreditAttribution: rkent_87 commentedI can't get this to apply with Composer, am I doing something wrong?
results in
Invalid argument supplied for foreach()
Comment #122
wrd CreditAttribution: wrd at State of Missouri, OA-ITSD commented@rkent_87: Inside the patches array, each package is the key for an array of patches, like so:
Comment #126
idimopoulos CreditAttribution: idimopoulos for European Commission and European Union Institutions, Agencies and Bodies commentedSorry to open a new PR. I tried to use beta1 but apparently, it did not include the patch from #2983448.
Note, that this is fixed in the dev version.
Comment #127
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot for Vardot commentedThank you, for this fix
Waiting for a release.
I hope soon
Comment #128
khiminrm CreditAttribution: khiminrm at Centarro commentedPatch from #114 works for me with beta1 too. thanks!
Comment #129
manish.upadhyay CreditAttribution: manish.upadhyay as a volunteer and at Publicis Sapient commentedPatch for https://www.drupal.org/project/password_policy/releases/8.x-3.0-beta1 release.
Comment #130
realityloopReriolled against 3.0 release
Comment #131
loopy1492 CreditAttribution: loopy1492 commentedI tried upgrading to 3.0 and got this error:
> Fatal error: Uncaught Error: Class 'Drupal\password_policy\EventSubscriber\ConfigEvents' not found in /var/www/docroot/profiles/custom/webny/modules/contrib/password_policy/src/EventSubscriber/PasswordPolicyEventSubscriber.php:125
I hunted around for fragments of this error until I found this issue. I had removed the old password_policy patch because it wouldn't apply. I assumed it had been rolled into the full release since it was so old. Still, I decided to try applying the most recent version of this patch and re-running the update. It worked.
I wouldn't say this is "fixed". I recommend rolling this into your 3.1 whenever that happens.
Comment #132
saurabh.tripathi.cs CreditAttribution: saurabh.tripathi.cs as a volunteer and commentedHi I am still getting below error for 8.x-3.0. #130 patch did not worked for me.
Drupal\Core\Entity\EntityStorageException: Field field_last_password_reset is unknown. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save()
I get this error while adding new user.
Comment #133
azam90 CreditAttribution: azam90 commented@saurabh.tripathi.cs
I was getting the same error whenever I created a new user and when the user updated their own password. I fixed it by running "drush updb". Figured out the issue after looking at this bug https://www.drupal.org/project/password_policy/issues/3236417
Comment #134
kruczi CreditAttribution: kruczi commentedThe version of patch 130 is no longer applicable for the latest version of module drupal/password_policy [3.2].
I updated the patch for the new version.
Comment #135
kruczi CreditAttribution: kruczi commentedSorry :(.
I have a problem updating comments with the correct number of the version of the file :).
Comment #136
Denis Degtyarev CreditAttribution: Denis Degtyarev at OWNSTR Ltd. commentedPatch #135 had a lot of code style errors (4 tabs instead of 2), added interdiff between old #130 & previous #135 patches to check errors.
Rerolled #130 patch against 8.x-3.2.
Comment #139
Rajeshreeputraplease review MR-44, here is the patch for the same.
Comment #140
Rajeshreeputraupdated patch with submodule coverage
Comment #141
yashsk8 CreditAttribution: yashsk8 as a volunteer commentedWill these patches work for password_policy 4.0?
Comment #142
DamienMcKennaThere no "Drupal 4.0", as far as you should be concerned, the Drupal core 4.0.0 release is from 2005.
I think this issue should be left "closed' and a new issue opened if the problem still exists in 8.x-3.x or 4.0.0.
Comment #143
c_archer CreditAttribution: c_archer as a volunteer and at Whisky Auctioneer commentedComment #144
Kristen PolEchoing @DamienMcKenna's comment that a *new* issue should be created if this is still a problem as this one is marked closed/fixed. Thanks. You can link to this one.