Support Forum
Support Forum
Offline
OK,
Sorry Roberto but will have to leave this one for @mr-papa.
Offline
Hello,
I've found a solution although it doesn't make sense to me yet why it worked. What I did was to compare the source code of an old, working version (v.5.3.4) that's running on the production site and that running on the dev (not working, v.5.5.11) site. I'm no PHP programmer but have programmed enough in my lifetime to wade my way through understanding it on the fly with the help of google.
Anyway the culprit appears to be the latest version of the file simple-press/forum/profile/ahah/sp-ahah-profile-save.php.
In the older, working version lines 77 & 78 the index 'password1' and 'password2' are used as the index to the $_POST variable to retrieve value of the passwords entered in the account settings form. The same for lines 120 & 121.
In the newer (v.5.5.11), non-working version those same lines use the index 'pass1' and 'pass2'.
I looked for the file containing the input form code for the password change (in v.5.3.4) to verify what index name should be used and figured that file to be simple-press/forum/profile/forms/sp-form-account.php. Reading through the code, I saw the index name used was 'password1' and 'password2' (Lines 73 & 81 of v.5.3.4).
Out of curiosity and just to try something, I changed all occurrences of 'pass1' to 'password1' and 'pass2' to 'password2' in the 5.5.11 version of simple-press/forum/profile/ahah/sp-ahah-profile-save.php.
I then tested if I can change passwords and it worked! Tested it repeatedly and it keeps working.
Then it occurred to me to compare the source code for the input forms which I figured to be simple-press/forum/profile/forms/sp-form-account.php for both versions. From my fragmented knowledge of HTML/PHP, what I did shouldn't have worked since the older and newer versions were using seemingly correct name attributes in relation to their respective sp-ahah-profile-save.php files. I also noticed that in v.5.5.11 those lines in question were using the same strings ('pass1','pass2') for both name and id attributes of their corresponding <input> elements, unlike in v.5.3.4 which used different strings for name and id in its corresponding <input> elements.
Ok, in summary it's working now with that edit I did to the sp-ahah-profile-save.php file, but I don't understand why it's working.
P.S.
One other curiosity is that the in both 5.3.4 and 5.5.11 versions of sp-ahah-profile.save.php, the part where it updates the user's email (if changed) appears to use SQL instead of the standard WP API wp_update_user(). Is there any particular reason for this?
Offline
so late to this game and very late tonight... but the issue is you are getting a is_plugin_active error? or something else...
we have a pretty good clue on the error and if so, will look into in next day or two (short handed with Andy on vacation and me working long hours - Ike doing yeoman's job around here!)...
or is the problem other and password just not saving? sorry for my confusion...
Visit Cruise Talk Central and Mr Papa's World
Offline
The problem in this thread is the password not being saved. Please check out my most recent post (#12) about it since that's the furthest I've gone so far in investigating the issue. Thanks.
Offline
okay, so nothing to do with is_plugin_active()... reason I asked for clarity as this thread has wound around...
have opened a ticket and we will investigate... bit short handed with team vacations, but its high priority ticket...
Visit Cruise Talk Central and Mr Papa's World
Offline
I do not understand this...
Nor can I replicate the issue... passwords change just fine in the profile...
and in order to work, it must be pass1 and pass2.. changing to password1 and password2 wont work - or at least should not work... you found in your research that the names/ids of the fields are correct for the saving code (at least as set in core)... and at this point, is not a change that can be globally made...
now, since wp_update_user() is called, its possible another plugin (or the wp theme) is hooking into that process and checking password updates... before wp 4.3, they used to use pass1 and pass2 as well... in 4.3 they changed to password1 but dont use a second password field...
the fact for you that using password1 and password2 works, also makes me wonder if something is hooking into wp user updates...
do you have any plugins that deal with user registration, profiles, membership or other that might be able to affect passwords?
worth adding, we had changed some versions ago to pass1 and pass2 to match wp when we added in the wp password hardness meter and it required matching field ids/names...
Visit Cruise Talk Central and Mr Papa's World
Offline
Driving me nuts too. I have a couple of plugins that could affect how the passwords save, but they were all deactivated during those tests. Theme My Login (6.4) and Woocommerce (2.4.7) were the only other plugins that did password changes but again, they were both deactivated.
Ok, here are some screen caps again that might help:
This first one is the browser (Chrome) "inspect element" of the account password change form loaded from the old (5.3.4) working, production version showing the HTML code related to the password entry form.
This next one is from the same form but on the 5.5.11 test version, with plugins active (Firefox) and using Genesis/Dynamic Website Builder Theme.
This next one is from the same 5.5.11 test version with all plugins deactivated and using Twenty-Fifteen theme:
I guess this shows that whatever's going on, the form that gets shown is using "password1" and "password2" for the name attribute. Ok, this leads me to believe that the form that's being invoked on my test site is not the right form because this doesn't tally with the source code of sp-form-account.php that I inspected. Another telltale sign is that the password hint text below the form is not showing as there is that part in the source code. It's as if another version of the sp-form-account.php file is being executed, from where I can't figure out.
Other than plugins (which have all been deactivated), what could be doing this?
My set-up is something like this (using imaginary domain name):
http://my-domain.com -- my main wordpress site on my server's public_html root (with WP Supercache)
http://my-domain.com/dev/2.2/ -- /dev/2.2 folder under the main public_html root containing the test wordpress with a separate DB (no caching)
The reason I'm stating it is I'm wondering if there's any conceivable way those two installs can affect each other. I can't imagine how. Is there any way my dev/2.2 forum software could be pointing to other parts of my folder structure? This is really frying my brain...
Offline
In addition to this, I was wondering if you or anyone reading could recommend a debugging tool/plugin that could help me figure out what PHP files are getting loaded (and from where) while loading the page in question. Thanks!
Offline
try going to forum - toolbox - housekeeping and reset the profile forms... if they are pointing somewhere else, that would fix reset them to default..
Visit Cruise Talk Central and Mr Papa's World
Offline
Ok, that finally worked using Reset Profile Tabs!
Understand you're busy, but I would like to understand how that happened in the first place. I am routinely transferring the whole production site to a development location and am suspecting that the procedure I use might be the root cause.
What I do is transfer a copy of the production site to a separate WP installation using the Duplicator plugin, which handles the replacement of references to the home URL so that the new copy is updated to reside in the new location. After duplication I upgrade WP to the latest version using the WP dashboard and upgrade all plugins, including SP and its plugins.
Is there something on SP Forum side that was probably not handled properly by this procedure? Is it enough to just reset the profile tabs or is there anything else I should do to make sure the new copy of the site's forum is working?
All RSS1 Guest(s)