Bonaparte

Ok thanks for explanation, so category RTFM😅 Best regards

Hello, today we finally upgraded our license key to the classic license model. Changing this and the payment worked out well and everything is fine from the renewal of the key itself. The only weird thing we currently see in our account here at Invision is the reported next Renewal Date with a value of "25 October 2025" (8 month from now). We would kindly ask if our perception here is wrong as we would have expected the renewal being somewhere in 2026 & would like to clarify this right now and not just complain later on. Best regards.

Thank you very much - the topic can be put as solved / closed then from my side.

Ok, so the column is deprecated and can be ignored when the default backend is being used? Thanks for clarification!

No errors, but by design this may be bad for the affected peoples' credentials (under some worst case preassumptions: Users using the same credentials for other sites) if the site would be hacked & attackers could re-use the credentials. I am aware of re-using the same credentials over multiple sites is a bad practice of users but as the provider of the platform I would like to assure the safety for user's data (I am also aware of MD5 hashes could be de-hashed with rainbow tables when the salts would be retrieved by the attackers.). Edit: Just default Auth Method enabled, as I just joined later, I can't tell if other Auth backends have been enabled in the past. Anyways I would like to bring it into the right state.

I am currently working on getting a self-hosted Invision Community upgraded from 4.3.6 to the latest 4.7.19 on our test environment - everything is working fine so far and I was able to successfully upgrade to the latest 4.7.19, but I identified plenty of NULL valued `members_pass_salt` fields (~33k of ~180k users in `ibf_core_members`, Query was "SELECT count(*) from `ibf_core_members` WHERE `members_pass_salt` IS NULL;"). I checked the `joined` columns earlierst and latest dates of the affected lines and those are spread between 2004-2024 (but the latest member with issue was still created under 4.3.6 in our production environment). The self-hosted Invision platform is 20 years old, so I think they came from a Invision Community v3 - just mentioning that I found some similar, but helpful topics as I searched before posting. As my (obvisously AdminCP enabled) account is "luckily" also affected, I tried (in the upgraded 4.7.19) with the password-reset functionality to set me a new password in the hope of the function setting a password hash aswell if empty - but with no luck. Questions: Is there a way to bulk fix from Invision AdminCP? If 1. is not possible, what would be needed to fix the issue to have all `members_pass_salt` populated? My solution approach in mind would be: Retrieve the list of members being affected for later notification SELECT `name`,`email`,`members_pass_salt` FROM `ibf_core_members` WHERE `members_pass_salt` IS NULL; Update all rows with NULLed fields: -- UPDATE Statement to set all found rows with NULL valued `members_pass_salt` fields to strong 22 char long salt values: UPDATE `ibf_core_members` SET `members_pass_salt` = ( SELECT GROUP_CONCAT( CHAR( CASE WHEN RAND() < 0.7 THEN FLOOR(48 + (RAND() * 74)) -- Alphanumeric (48–122) ELSE FLOOR(33 + (RAND() * 15)) -- Special chars (33–47) END ) ORDER BY RAND() SEPARATOR '' ) FROM ( SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9 UNION ALL SELECT 10 UNION ALL SELECT 11 UNION ALL SELECT 12 UNION ALL SELECT 13 UNION ALL SELECT 14 UNION ALL SELECT 15 UNION ALL SELECT 16 UNION ALL SELECT 17 UNION ALL SELECT 18 UNION ALL SELECT 19 UNION ALL SELECT 20 UNION ALL SELECT 21 UNION ALL SELECT 22 ) t ) WHERE `members_pass_salt` IS NULL; Examples of the salts: A1bC!3dE$fG%hI2jK@lM^n xY#9z8&7w!6vU*5tR^3q1p @mZ2d#5f6g$7k!9n3o^4L8 r1t^u2v3w$x5y6z7!A#9B8C Send the affected users a notification via Email for informing them of the need to change their password to be able to login again. Would that work as a fix? I am open to any recommendations for improvements / hints / knowledge. Also I hope I did search well enough before creating my thread here. Best regards.

Thanks for the information.

Thank you very much for all the clarification! Then I think I am mostly fine with my attempts of the upgrade process.

@teraßyte thanks for the reply, also regarding your experiences of the past. As this Invision Board community is an old one already (started 2004), and stuck with the updates from 4y ago, I just want to assure I am not losing anything from the old database schemas. But if I understand the upgrade process correct (and tested successfully) to just copy over the latest available 4.7.19 & then let the manual upgrade process upgrade the db schemes accordingly. It may just be related to our test root just having PHP 7.4 as the minimum version available, as the live environment still uses 7.3 - and I think the old version of Invision Board may only be certified to work with 7.1 - 7.3.. Even if the process is working out so far for doing the upgrade after cloning from our outdated live to our test environment, I just wanted to assure I am not having any unknown losses in the process. My hopefully last stupid question in that regard: If in the live environment all tasks were recently executed within their expected scheduling, I may just consider the 503 I am getting as some weirdo bug then, right?

503 GET /forum/index.php?app=core&module=system&controller=serviceworker&v=****************&type=admin&loggedIn=false HTTP/1.1 that is the 503 I am getting from the php 7.4 backend within our 4.3.6 installation. Besides the app=core&module=system&controller=serviceworker call, I am not getting other 503s. The File permissions in the httpdocs are suffficiently set, also the tasks.php is chmoded with 0777 and cronjobs were configured. But I couldn't identify that any long-running tasks were shown in the UI, nor did I see the cli tasks.php background command being working on tasks - the process is stopped in an instant without any exception or other message.

To add: I really would like to achieve this step for quality reasons, as our contract with Invision doesn't allow for direct email support: I would even pay a fee of 10 USD or so for getting us the old version installer package 😄

Thanks @SeNioR-, that is why I would like to request this from the vendor if it can be achieved as a one-time delivery per request. Additionally I can just recommend to allow customers to retrieve all recent versions for such cases - could be easily achieved with putting the download links within every release page. I am an IT professional, so I know the risks of running outdated installations - but my / our case is to to explicitly verify the installation contents from the httpsdocs folder are all correct before we would like to take the next steps of our migration towards latest Invision Board version. As I am right now having the feeling that the Background tasks may not be able to be run correctly but I can't pin it down further from the error log entries on PHP level right now..

Hello Support team, tl;dr: Is there a way to retrieve older version of Invision Board software, even if it is considered deprecated? Exact one needed would be v4.3.6 From the Release Page there is unfortunately no link to the older releases Background of my request: Recently I took over the administration of an Invision Board installation which wasn't upgraded in a long time, so the platform (self-hosted) & Invision software are outdated. Right now our Invision Board is running in version 4.3.6 & I am working with a clone of our live version within our test instance (separated root server with newer OS specs to allow latest Invision Versions) to test the migration & later upgrade of the Invision Board application. As I have seen some error log entries regarding some calls towards the core serviceworker not working out correctly, I would like to copy the original installation files to see if some .php file of Invision Board were possibly damaged or (in the past unintentionally) altered.

Extra info: When the forums are set as the default application: forum/index.php > forum index forum/index.php?/forums/ > portal forum/index.php?/portal/ > portal When the portal is set as the default application, they all go to the portal. Problem therefore seems to be with how it handles the "forum/index.php/?/forums/" link. The fact that this redirects to the portal even when the forums are the default application, seems to cause the problem.

Hi Mike, First of all, thank you for all your work on the portal! Today I installed the latest version of the portal (v1.6.0) on our forum (v4.1.15). Before we had v1.5.3. However, I have encountered following issue: Everything works fine until I set the portal as the default application. When I do this both the 'portal' and 'forum' links in the 'browse menu' lead back to the portal. I couldn't find a solution, so now I have put temporary the forum as the default application and then both links are behaving normal. Do you have any idea what could be wrong? We didn't have this problem with v1.5.3 of the portal.