Retrieving old version install package (4.3.6)

[Bonaparte]

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.

Edited Saturday at 01:43 PM by Bonaparte

[SeNioR-]

Hello, there is no way to restore or download an older version of the software.

[Bonaparte]

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

[Bonaparte]

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 😄

[Bonaparte]

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.

[teraßyte]

Unfortunately, IPS never provides older versions for download, not even for a simple comparison. I have a folder with all versions myself, but I'm not allowed to share the package/files. 🤷‍♂️

A way to work around the sharing problem would be to hire someone with access to the 4.3.6 package and have them compare the files for you.

 

Here are a few considerations:

1. While the 2.x and 3.x versions used to require extensive file edits to install modifications, starting with version 4, there were no file edits at all. If you have third-party modifications installed (applications and/or plugins), they'll show up in your ACP. It is very rare for someone to edit the core/default files of the 4.x version.
2. I recall that "serviceworker" file had some changes/fixes at some point, but I don't recall which version exactly. However, it might simply be a bug that's fixed in a later version. 🤔
3. Since you mentioned making a test copy, I would simply try upgrading that copy to the latest 4.7.19 version and see if the issue is fixed.

 

The summary is: you most likely don't have any file edits.

[Bonaparte]

@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?

[teraßyte]

7 minutes ago, Bonaparte said:

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.

When any database table or column is missing, you'll get a warning in the ACP > Support page with a list of queries to automatically fix the issues.

If you have nothing there, you're okay. 👍

 

8 minutes ago, Bonaparte said:

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.

You would need to proceed with a manual upgrade following these steps:

1. Disable all applications/plugins in ACP (in case some are not compatible with PHP 8).
2. Upload a fresh set of files downloaded from your client area (version 4.7.19 currently).
3. Switch the PHP version to either 8.1 (recommended) or 8.0.
   • Starting from version 4.7.4 PHP 7.x isn't supported anymore.
4. Go to domain.com/admin/upgrade and follow the upgrade instructions.
5. Once the upgrade is complete check in the ACP if any applications and plugins still work (enable them 1-by-1).
   • You can also use the PHP8 Compatibility Scanner tool available in ACP > Support for further help.

 

12 minutes ago, Bonaparte said:

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?

That "serviceworker" URL is actually not a task but a backend JS script that handles the push notifications for the browser, tablets, and phones.

If any tasks are not running correctly, a big red warning will show up in your ACP to warn you about eventual issues (including the name of the task not working).

[Bonaparte]

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

[Jim M]

Sorry, we only provide the latest release.