New accounts unable to be created

[David..]

When trying to create a new account on our site it creates the account successfully but on the registration form it proceeds to say "That display name is in use by another member." & That email address is in use by another member. Do you need to reset your password?"

There is an issue here as the account name & email was available right before hitting the "Create my Account" button.

I tried disabling all apps & plugins via support, but the issue was strangely still present.

Access information is up to date.

 

Potentially related system log:

INSERT INTO `ipb__core_pfields_content` ( `member_id`, `field_12`, `field_13`, `field_27` ) VALUES ( 8497548, 'Windows', '11', 0 ) ON DUPLICATE KEY UPDATE `member_id`=VALUES(`member_id`), `field_12`=VALUES(`field_12`), `field_13`=VALUES(`field_13`), `field_27`=VALUES(`field_27`)
IPS\Db\Exception: Out of range value for column 'member_id' at row 1 (1264)
#0 public_html/system/Db/Db.php(941): IPS\_Db->preparedQuery()
#1 public_html/applications/core/extensions/core/ProfileSteps/ProfileFields.php(208): IPS\_Db->insert()
#2 public_html/applications/core/modules/front/system/register.php(572): IPS\core\extensions\core\ProfileSteps\_ProfileFields::formatFormValues()
#3 public_html/applications/core/modules/front/system/register.php(242): IPS\core\modules\front\system\_register::_createMember()
#4 public_html/applications/core/modules/front/system/register.php(176): IPS\core\modules\front\system\_register->_registrationForm()
#5 public_html/system/Helpers/Wizard/Wizard.php(181): IPS\core\modules\front\system\_register->IPS\core\modules\front\system\{closure}()
#6 public_html/applications/core/modules/front/system/register.php(183): IPS\Helpers\_Wizard->__toString()
#7 public_html/init.php(927) : eval()'d code(27): IPS\core\modules\front\system\_register->manage()
#8 public_html/system/Dispatcher/Controller.php(118): IPS\core\modules\front\system\nexus_hook_register->manage()
#9 public_html/system/Dispatcher/Dispatcher.php(153): IPS\Dispatcher\_Controller->execute()
#10 public_html/index.php(13): IPS\_Dispatcher->run()
#11 {main}

 

Backtrace:

#0 public_html/init.php(1029): IPS\_Log::log()
#1 public_html/system/Helpers/Wizard/Wizard.php(227): IPS\IPS::exceptionHandler()
#2 public_html/applications/core/modules/front/system/register.php(183): IPS\Helpers\_Wizard->__toString()
#3 public_html/init.php(927) : eval()'d code(27): IPS\core\modules\front\system\_register->manage()
#4 public_html/system/Dispatcher/Controller.php(118): IPS\core\modules\front\system\nexus_hook_register->manage()
#5 public_html/system/Dispatcher/Dispatcher.php(153): IPS\Dispatcher\_Controller->execute()
#6 public_html/index.php(13): IPS\_Dispatcher->run()
#7 {main}

 

Edited December 14, 2022 by David..

[Jim M]

The value being passed there for member_id is larger than the table structure allows. I would suggest disabling all third party applications/plugins and switch to an unmodified theme then try again as your database auto-increment is within scope of the structure.

[David..]

6 minutes ago, Jim M said:

The value being passed there for member_id is larger than the table structure allows. I would suggest disabling all third party applications/plugins and switch to an unmodified theme then try again as your database auto-increment is within scope of the structure.

As mentioned in the first post, that does not seem to help.

One thing I do notice is that disabling everything still keeps the custom theme for guests which was usually not the case.

[Jim M]

Just now, David.. said:

As mentioned in the first post, that does not seem to help.

One thing I do notice is that disabling everything still keeps the custom theme for guests which was usually not the case.

Disabling via the Support tool would only switch the theme for your admin account, not everyone. You would need  to change this for guests by going to ACP -> Customization -> Themes -> edit the theme and make it the default.

[David..]

1 minute ago, Jim M said:

Disabling via the Support tool would only switch the theme for your admin account, not everyone. You would need  to change this for guests by going to ACP -> Customization -> Themes -> edit the theme and make it the default.

Disabled everything, switched to default theme and unfortunately the issue is still present.

[Jim M]

There still appear to be modified files on the system. If these are your own, you would need to revert these back to what is in the Client Area.

[David..]

Just now, Jim M said:

There still appear to be modified files on the system. If these are your own, you would need to revert these back to what is in the Client Area.

I have tested with those reverted back and everything disabled after a fresh update to 4.7.5, the issue is still present. 

 

[Jim M]

We would require these modified files to be replaced with the unmodified for our troubleshooting. We cannot troubleshoot with them present, I'm afraid.

[teraßyte]

Most likely you've reached the MAXIMUM VALUE of the data type used for the member_id column in the ipb__core_pfields_content table.

The current default value is BIGINT(20) but in the past it had a lower limit. The column was not updated properly in one of the upgrade steps probably.

Edited December 14, 2022 by teraßyte

[RevengeFNF]

42 minutes ago, teraßyte said:

The current default value is BIGINT(20) but in the past it had a lower limit. The column was not updated properly in one of the upgrade steps probably.

Mine is mediumint (8). You sure it changed to bigint?

[Adriano Faria]

That’s the problem. Member ID has to be BIGINT(20).

[David..]

58 minutes ago, teraßyte said:

Most likely you've reached the MAXIMUM VALUE of the data type used for the member_id column in the ipb__core_pfields_content table.

The current default value is BIGINT(20) but in the past it had a lower limit. The column was not updated properly in one of the upgrade steps probably.

Thank you for this. The problem seems to be solved now.

Thank you!

[Gary]

Hi @David..,

Happy to hear that this has been resolved. If you encounter any other issues, please don't hesitate to get in touch again. 🙂

[teraßyte]

@Gary The database checker usually detects that kind of thing but it looks like there's some specific code in place to specifically skip INT/MEDIUMINT columns that should be BIGINT. Other people will surely run into the same issue at some point. Maybe you could bring it up with the developers?

 

See file /system/Application/Application.php on line 2846:

/*  If the only difference is MEDIUMIT or INT should be BIGINT UNSIGNED - that's where we changed the member ID column. We don't need to flag it */

[...]

 

[David..]

Hi @Gary,

I unfortunately refrain from getting in touch with IPS support given that the simple file modification I’ve made makes it impossible to receive support from the staff.

Thankfully, other members were able to assist with this issue.

I would like to emphasize that this issue had nothing to do with the modified files, and neither did my previous support topics.

[Gary]

You shouldn't refrain from asking for support at any time, @David.., as it completes your package as a client of Invision Community. But if we find there is custom code or modified files on your community, then it makes it more difficult for us to diagnose the issue.

Think of it like having warranty on a vehicle. If you own a Volkswagen and decide to install an aftermarket part, the Volkswagen dealership will not take responsibility for it, and you'll likely void your factory warranty. If you were to replace that part with a genuine product, then they will work on your vehicle (just like we will continue providing support on your issue once you revert everything back using unmodified files). If you don't want to do that, then that's completely fine as the dealership will just refer you to another unbranded workshop to work on your vehicle (in this case, the community that have provided you with the assistance already), which is also okay.

1 hour ago, teraßyte said:

@Gary The database checker usually detects that kind of thing but it looks like there's some specific code in place to specifically skip INT/MEDIUMINT columns that should be BIGINT. Other people will surely run into the same issue at some point. Maybe you could bring it up with the developers?

 

See file /system/Application/Application.php on line 2846:

/*  If the only difference is MEDIUMIT or INT should be BIGINT UNSIGNED - that's where we changed the member ID column. We don't need to flag it */

[...]

 

I will send this up to be investigated by our dev team.

[David..]

10 minutes ago, Gary said:

Think of it like having warranty on a vehicle. If you own a Volkswagen and decide to install an aftermarket part, the Volkswagen dealership will not take responsibility for it, and you'll likely void your factory warranty. If you were to replace that part with a genuine product, then they will work on your vehicle (just like we will continue providing support on your issue once you revert everything back using unmodified files). If you don't want to do that, then that's completely fine as the dealership will just refer you to another unbranded workshop to work on your vehicle (in this case, the community that have provided you with the assistance already), which is also okay.

That is understandable, except in this case I’ve modified my cup holders so Volkswagen shouldn’t deny servicing the actual problem.

As I mentioned, the modified files are minor and only affect the API & Oauth. This should not make it so the whole community is unable to be supported, especially as you can see in this topic, the issue was entirely unrelated to the file modifications.

[Gary]

I do understand that too, but if we are helping some people and not others, it would just open up Pandora's box. How minor is one person's modifications over another? Where do we draw the line?

The issue was obviously not related to the file modifications you made in this scenario. If they are that minor or insignificant, you can remove the modifications, have our team diagnose the issue for you, then add the modifications back into your file/s once it was confirmed that it was something else completely different that was causing the issue.

We just won't (and in some cases, can't) diagnose issues anyone has if there are modifications to the core files.

[Marc Stridgen]

3 hours ago, David.. said:

That is understandable, except in this case I’ve modified my cup holders so Volkswagen shouldn’t deny servicing the actual problem.

In you scenario here, David, the cupholders are some CSS changes you have made. The core files are the engine that runs your site. We will issue support, all we ask is that thoe modified files you are running are reverted to be stock while we look at the issue.

I would note, this is the same for themes, plugins, applications etc. We always ask for things to be tested without those modifications. We're certainly not saying we will not give support. We are simply asking you to ensure we can issue that support in the correct manner.

[David..]

9 hours ago, Gary said:

it would just open up Pandora's box.

I understand.

9 hours ago, Gary said:

If they are that minor or insignificant, you can remove the modifications, have our team diagnose the issue for you, then add the modifications back into your file/s once it was confirmed that it was something else completely different that was causing the issue.

They are insignificant in terms of the whole software, and this problem, but they are significant & required for my community to run.

In fact, the main change is allowing Oauth redirects to be URIs instead of only URLs. Something which should be by done by default. Around 7 lines of code are commented out.

Specifically:

		if ( $redirectUri )
		{
			//if ( !\in_array( $redirectUri, $allowedRedirectUris ) )
			//{
			//	throw new \IPS\Login\Handler\OAuth2\InitException('oauth_err_invalid_redirect_uri');
			//}
			//else
			//{
				$obj->redirectUri = \IPS\Http\Url::external( $redirectUri );
			//}
		}

9 hours ago, Gary said:

you can remove the modifications, have our team diagnose the issue for you, then add the modifications back into your file/s once it was confirmed that it was something else completely different that was causing the issue.

This is what I was willing to do in a previous support topic but the issue here is that once the modifications are removed the Oauth is broken and inaccessible for seemingly hours until someone from IPS looks into the issue, and even longer if they have to escalate.

This is not an ideal solution for us, and that's why I refrain from asking support from staff.

6 hours ago, Marc Stridgen said:

In you scenario here, David, the cupholders are some CSS changes you have made. The core files are the engine that runs your site. We will issue support, all we ask is that thoe modified files you are running are reverted to be stock while we look at the issue.

I would note, this is the same for themes, plugins, applications etc. We always ask for things to be tested without those modifications. We're certainly not saying we will not give support. We are simply asking you to ensure we can issue that support in the correct manner.

You are correct, so just replace cupholders with anything else insignificant that would not affect the entirety of the car, or the issue at hand.

Just to be clear: I'm referring to my case here, I don't know what others do to their modified files.

[Marc Stridgen]

19 minutes ago, David.. said:

Just to be clear: I'm referring to my case here, I don't know what others do to their modified files.

This is part of our SLA, so unfortunately we do need to insist if you have modified files, they are reverted before we can provide support. I understand your frustration, but we cant be checking through a persons changes to see if they may affect part of a site. We also have many many occasions where its "It cannot possibly be that" where we find it is.

Just as a note here, you really should be modifying via the plugin system provided for that purpose. We would never advise on changing files in any scenario 

[David..]

2 minutes ago, Marc Stridgen said:

Just as a note here, you really should be modifying via the plugin system provided for that purpose. We would never advise on changing files in any scenario 

This is something I have sought to accomplish but was told that it was not possible which left me no choice but to continue using the file modifications.

Quote

Hello,

unfortunatelly we can't plug in into this place, due to hardcoded IPS overload classes only:

That oauth isn't inside IPS files and has own class:

 

[teraßyte]

Depending on what you're trying to do there might be some kind of possible workaround using plugins. 🤔

I can't be sure without knowing what exactly you're trying to accomplish doing those edits though.