Account Management resetting User Information on edit

RESOLVED: Not an InterWorx issue

I just migrated over from cPanel (LiquidWeb performed the migration) and have encountered this NodeWorx issue.

All of the SiteWorx accounts on the server have nicknames and admin addresses that appear in the account table in the UI. Those nicknames and addresses are all correct.

However, if I attempt to edit an account for, say, allowing crontab access, and click Save, I get a “problem validating the form” error. When I expand the User Information accordion, I see 3 issues: [LIST=1]

  • The Nickname is defaulted to the main domain user name rather than the account user.
  • The Email Address is defaulted to the server admin email address.
  • The Confirm password is blank and the error icon displayed because of the mismatch whatever Password value is in that field. [/LIST] I can't continue until I reset this information, including resetting the password.

    I hoped that doing so would “stick” the information, but the next time I open up the account modal, the same issue occurs – Nickname, Email, and Confirm password are defaulted as mentioned above.

    And yet in the account table, I still see the correct Nickname and Email Address.

    Any thoughts on this one?

  • Not sure about #1 but #2 and #3 could be browser behavior. Since we’re using IPs instead of names for control panel access, browsers will ‘remember’ a password, email or some previously used credential and fill the form ‘to be helpful’ even if the credential belongs to a different account. Siteworx and Nodeworx URLs are the same (but different ports) no matter what forms we’re editing, but the browser makes no distinction. It can be very annoying.

    You shouldn’t ever need to re-enter or reset a working password to make a change, just make sure both password fields are empty before saving.

    By chance are you using Firefox with Windows? I get the “problem validating the form” error whenever I try to create a database in Siteworx using Firefox but it works fine with Brave. If you’re getting that error a lot see if a Chromium-based browser makes any difference.

    Hi skmoore

    Welcome to IW forums

    Sysnop is very experienced and has a wealth of knowledge. Kudos to sysnop

    I am sorry, I am struggling to understand your post sorry. Perhaps too early in the morning for me sorry or not enough coffee…

    Would you be able to post a picture (obscure any data) so I maybe able to understand more but a few questions

    Are you doing this from siteworx or nodeworx (if nodeworx, it maybe correct as users are controlled from siteworx), if so, login as siteworx user and change - does this correctly work

    what IW-CP are you running and distro

    Many thanks



    Sorry, if the user account exists or you are creating a new user, is login also ticked and then you tick cron.

    Many thanks


    I wish that was true. Thanks anyway, John, for your generosity.

    I thought of another peculiarity related to form fields in Siteworx. It’s not a bug and makes perfect sense after figuring it out.

    If a Siteworx account is setup with the same email address used for Nodeworx logins, you probaby won’t be able to modify package features and other settings until the Siteworx account has its own unique email. I discovered this while trying to add a PHP version for a Siteworx user; changes wouldn’t take and there’d be a warning and/or “problem validating the form” error. Immediately after changing the account email it worked as expected.

    Just a heads up to make sure all accounts have unique email addresses. Maybe this was common knowledge but it was new to me at the time.

    Thanks for the replies.

    I’d considered it might be a browser issue, sysnop, but it seemed unlikely given that I’d expect those fields to be prepopulated from InterWorx data about the account. I’m using Chrome, but I’ll certainly try Brave and maybe even Safari on the Mac side of things to see if that makes a difference.

    Allow me to clarify the problem:

    • I'm working only with accounts and sites migrated from cPanel, so this pertains to all [B]existing, migrated [/B]SiteWorx accounts. I've not yet tested it with setting up a new account, but will try that today to see if the behavior is different.
    • When I navigate to the SiteWorx "Accounts" option, I see the correct Nickname information for the accounts in the SiteWorx Account Management table:
    [INDENT][ATTACH=JSON]{"data-align":"none","data-size":"full","title":"AccountTable.png","data-attachmentid":50173}[/ATTACH][/INDENT] [INDENT]Hovering over the "SiteWorx user" link shows the correct email address for the user account's administrator.[/INDENT]
    • When I click [B]Edit [/B]to bring up the Account Management modal for the specific account, I see this under the User Information:


    [INDENT]You can see here that the Nickname and Email information do not belong to the account itself (as shown in the SiteWorx Account Management table), but have reverted back to the main domain/server admin information. We can't see what's in the Password field, obviously, but it's clear the form is expecting a change as it's prompting me to confirm the password.[/INDENT]
    • I changed the crontab access setting as needed for this particular account, but clicking [B]Save [/B]to store the new setting causes the form to throw the validation error, precisely because it thinks the User Information screen isn't complete:
    [INDENT][ATTACH=JSON]{"data-align":"none","data-size":"full","title":"UserInfoError.png","data-attachmentid":50175}[/ATTACH][/INDENT] ​​​​​​​ Thanks to all for any insight you can provide. If no one else has encountered this issue, I'll open a ticket.




    Looks like we cross-posted, sysnop. (Spot the ex-technical writer.) :slight_smile:

    Thanks for this info. I’ll take a look and report back.

    Big shout-out to sysnop on this one on pointing me the right direction.

    It’s the Chrome LastPass extension that’s poking that information into the form fields. I had to go to the Extension settings and tick the box that said “Don’t autofill form fields that are already filled”. Why that’s not the default setting, I have no idea.

    The form is now working as expected. Thanks!


    Kudos to Sysnop and skmoore, thanks for your update. It’s good to know

    Sysnop - sorry I just tried your post on an account that only has the same email for siteworx as nodeworx and was bale to edit the package, changing allowed bandwidth and adding PHP 7.2 and PHP 8 Dev. It saved correctly

    I hope I understood what you were meaning as I did this from nodeworx, siteworx edit siteworx account package. Sorry if I have not understood though, I seem to be on blonde day today

    Stay safe

    Many thanks


    Glad you got it sorted out. Your descriptions sounded so similar to my experience with Firefox filling forms automatically. It can be unnerving but I’ve gotten so accustomed to backspacing a field before saving changes that it made me too lazy to figure out how to tame Firefox. Normally FF is sensible about remembering forms but I think URLs without host names trip it up.

    Hey John. I appreciate you testing what I described but sorry to have wasted your time. I must be wrong about packages or other settings when a Siteworx email matches a Nodeworx email. I definitely wasn’t able to add an addition PHP version to Siteworx until giving the SW account a different email. But it could also be chalked up to some other cause. As I recall, I had tried with two different browsers and when I changed the SW email and it worked… I jumped to a conclusion based on the last action which isn’t always reliable.