wp_set_password not working with autoptmize

hmm … first time I read about such an issue so certainly not a known issue.

So where is the wp_set_password function executed/ invoked, somewhere under wp-admin (where AO does not optimize the JS/ CSS) or on the frontend?

And is wp_set_password invoked using AJAX and if so do you see any JS errors on the browser console?

It’s being run in the front end and is not done using Ajax.

there are but 2 things I can think of that can go wrong;
a. there is JS involved and the JS when optimized fails somehow (check browser console for JS errors). the easy fix could be to untick the “also optimize for logged in users”, but that might not suffice as this only applies for users that can edit_posts).
b. a problem with nonce checking; the form that is submitted when changing a pwd likely (and should) be secured by a nonce. if the nonce gets cached (by AO or more likely by a page cache), the nonce check will fail if the nonce has expired. solution would be to make sure that -if the nonce is set in JS- to exclude that piece of JS from AO optimization and to make sure page cache don’t cache that page (or at least not for a long time, shoot for 4 hours or so).

hope this helps,
frank

Okay, so here is something strange.

I tried unchecking the “also optimize for logged in users” as you suggested and that didn’t help.

So instead I tried deactivating everything, I deactivated optimise html code, js code and css code as well as deactivated the two misc options at the bottom. The wp_set_password still didn’t work.

So even though autoptimize is essentially doing nothing, if it is activated it interferes with this function.

Does that provide any clues at all to you?

I also removed the CSN url and cleared the cache.

Does that provide any clues at all to you?

no, not at all I’m afraid. do you have any of the “extra” options set?

The only extra options set were greyed out when I unticked the various “optimise code” check boxes. Which I presume means they are deactivated.

don’t know by heart, but two (the version & emoji ones) _can_ work even if the main optimizations aren’t active. not that I see how these could interfere with wp_set_password (my gut says this _can’t_ be AO really), but still …

as you’re referring to wp_set_password (a core function), I assume this is part of custom development of yours? so is the request (a POST I presume) going through? are there errors in the PHP errorlog? have you tried adding debug code to hunt this down?

The post is definitely going through. I check that it’s posted through plus I can echo it out at the exact point in the code where the function runs. So the data is being posted.

I’ve also tried hard writing the password into the function. No luck.

I’ve checked the error log. There are no errors being logged.

I’ve used query monitor to check out if the query appears to being run. It is and the query appears to be structured correctly. The hashed version of the password that can be seen in the query in query monitor is being updated in the database to this hash. However, the hash appears to be for the old password as I still can only login with the old password, not the new one.

So it appears that something is making it create a new hash of the old password not the new one, then it is successfully querying the database.

weird … and have you tried error_logging the incoming pwd, the hash or the (new) pwd before the update query is being run?

Hi,

I tried to log the incoming password, hash etc. nothing seemed to be going wrong.

However!

Due to a seemingly unrelated issue with my website, I have had to disable redis object cache. This appears to have resolved the problem. I’m not sure if that really means anything to you.

I am going to stick with having the redis object cache disabled for now unless you have any further thoughts.

Dan

ah the stale object cache syndrome … that might be due to this known ugly core bug actually :-/

Cool, well hopefully this is something they’ll fix in future but for now I’ll just not use the Reddis Object Cache.

I call this resolved!

not using redis is .. harsh, no?

but the linked core but probably does not apply, as passwords are not in the options-table ??

maybe you could flush redis before and/ or after the pwd update?

• This reply was modified 6 years, 5 months ago by Optimizing Matters. Reason: pwd is not in alloptions