Jump to content

David..

Clients
  • Posts

    1,214
  • Joined

  • Last visited

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Posts posted by David..

  1. 30 minutes ago, Matt said:

    You can ignore the support tool warning. We will revue member ID columns and increase to bigint where they are not already. 

    Hi Matt! Thank you for replying and hope you're having a Merry Christmas!

    Is this something that would require resolution on my live board the coming days, or would I have wait until the next IPS release? I can also upgrade them to bigint myself if you could get me a list of all the member_id columns.

    Looking forward to your next reply.

  2. On my community, member IDs now surpass the 8 digit value and because of this, there are numerous issues with new registrations.

    It started with them being unable to create a new account, which thankfully was resolved here: https://invisioncommunity.com/forums/topic/471135-new-accounts-unable-to-be-created/#comment-2919659

     

    After resolving the registrations, because of the member IDs surpassing 8 digits, it also caused issues with nexus, posts (both partially fixed but IPS complaining as seen below) and seems like I cannot start new PMs. When trying to make a new post or PM now, it double posts but the posts do not actually show which may be causing issues with the database. The same issue can also be seen via PM.

     

    While changing to BIGINT(20) solves the issue, IPS support seems to be complaining about there being an issue with the database:

    There are some problems with your database. Normally it is safe to try to fix these problems automatically however if your community is large, you may want to run the necessary queries manually. If so, the queries to run are:
    
    UPDATE `core_validating` SET `member_id`=0 WHERE `member_id` IS NULL;
    ALTER TABLE `core_validating` DROP INDEX `member_id`, CHANGE COLUMN `member_id` `member_id` BIGINT UNSIGNED NOT NULL DEFAULT 0 , ADD KEY `member_id` (`member_id`);
    UPDATE `core_pfields_content` SET `member_id`=0 WHERE `member_id` IS NULL;
    CREATE TABLE `core_pfields_content_new` LIKE `core_pfields_content`;
    ALTER TABLE `core_pfields_content_new` DROP INDEX `PRIMARY`, CHANGE COLUMN `member_id` `member_id` BIGINT UNSIGNED NOT NULL DEFAULT 0 , ADD PRIMARY KEY (`member_id`);
    INSERT IGNORE INTO `core_pfields_content_new` SELECT * FROM `core_pfields_content`;
    DROP TABLE `core_pfields_content`;
    RENAME TABLE `core_pfields_content_new` TO `core_pfields_content`;
    UPDATE `forums_posts` SET `author_id`=0 WHERE `author_id` IS NULL;
    ALTER TABLE `forums_posts` DROP INDEX `author_id`, DROP INDEX `topic_id`, CHANGE COLUMN `author_id` `author_id` BIGINT UNSIGNED NOT NULL DEFAULT 0 , ADD KEY `author_id` (`author_id`,`post_date`,`queued`), ADD KEY `topic_id` (`topic_id`,`queued`,`post_date`,`author_id`);
    UPDATE `nexus_invoices` SET `i_id`='' WHERE `i_id` IS NULL;
    ALTER TABLE `nexus_invoices` CHANGE COLUMN `i_id` `i_id` INT NOT NULL AUTO_INCREMENT ;

     

     

     

    Hopefully someone from the IPS team ( @Matt, @Daniel F & others) can take some time to look into this or at least tell me where all the member ID columns that need to be changed to BIGINT are. This should be escalated as it seems to be a bug with the IPS software itself as pointed out by @teraßyte here: https://invisioncommunity.com/forums/topic/471135-new-accounts-unable-to-be-created/?do=findComment&comment=2919579

     

    I have made sure the access information is up to date. Sorry this had to happen on Christmas day, but it is out of my control.

    Thank you.

     

  3. 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:

     

  4. 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.

  5. 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.

  6. 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.

  7. 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!

  8. 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. 

     

  9. 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.

  10. 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.

  11. 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}

     

  12. On 10/11/2022 at 4:36 PM, Marc Stridgen said:

    This issue has been resolved in the recently released 4.7.3 version. Please upgrade to resolve this. If you are then still experiencing problems, please let us know.

    I am still experiencing this problem.

     I’m not entirely sure, but it may be related to topics created via the API.

  13. 6 minutes ago, Marc Stridgen said:

    It is only showing the topic, and just under is a preview of the latest reply on that topic

    In my case, it arranges topics by recent activity, posts. It doesn’t arrange topics by start date.

    So with that, it seems like it’s arranging by posts rather than topics.

×
×
  • Create New...