Stuart Silvester

This has been fixed for our next beta.

This has been fixed for our next beta

This issue will be fixed in the next beta.

This issue will be fixed in the next beta.

This has been fixed for our next beta

Calling /downloads/files/{id}/download does increment the download count and stores a log of the download (if enabled), just like downloading via a browser would. -- Make sure the category is set to retain logs of downloaded files.
If you're looking for better protection of files on disk for Downloads, I would recommend using something like Amazon S3 for storage. S3 supports signed URLs and does not allow direct access to files uploaded via Downloads.

Thanks for the info on the server. I use BunnyCDN because they are very cheap! They claim they will soon have S3 service, so I will give them some time to make that happen. 

@Stuart Silvester you are amazing! I just tested this (Thats why I am replying late) and this works! Thank you so much guys! You both just made my day!

Assumption made:
the notification is generated by a background task on the relevant site Theory:
Task method is set to CRON The CRON task itself is using PHP 7.4.x for PHP, while the site itself is using a different version Resolution:
Modify the CRON details in your scheduler

The report has been triaged and should be assigned to a developer soon.

Thanks!
This is a PHP bug that's fixed in 8.1.10 - https://bugs.php.net/bug.php?id=81263

The report has been triaged and should be assigned to a developer soon.

Thanks!
This is a PHP bug that's fixed in 8.1.10 - https://bugs.php.net/bug.php?id=81263

Can confirm it's working now on 8.1.10

As you may have noticed, we've been doing a lot of work to prepare Invision Community to use PHP8 as the minimum version.
If you are an Invision Community Cloud client, then you do not need to worry about any of this, and can happily click out of this topic.
For those who host Invision Community on their own servers, then please read on.
PHP7 is now end of life and from November, PHP will no longer offer security updates. PHP8 is a major update which brings many changes including how errors are either logged and means that what was a harmless notice or log entry is now a fatal error which Invision Community cannot capture.
We have introduced the application and plugin scanner to ensure that your site is not "bricked" (unrecoverable from a fatal error) when you upgrade to PHP8 although you currently have the option to re-enable any disabled applications or plugins.
From the November 2022 release, we will require PHP8.0 as the minimum version. If you are currently using PHP7 then you must contact your host and plan your PHP8 upgrade to ensure compatibility with Invision Community from November onwards.

We are rolling out dismissible AdminCP banners to those who are currently on PHP7.
If you are unsure what version of PHP your server is running, simply log into your Admin CP then navigate to System > Get Support and check out the PHP version block.


The November release of Invision Community will also mean that you are no longer able to re-enable plugins the application scanner disables. We continue to work on this tool to refine its error checking and logging verbosity.
If you have any questions, please let me know below.
 

Thanks!
This is a PHP bug that's fixed in 8.1.10 - https://bugs.php.net/bug.php?id=81263

Hey Adlago,
I don't work at IPS (despite that cute cartoon avatar I have), so I'm able to tell you that you're doing it wrong. You should never have been editing the default CSS files, and it's unfortunate that the product allowed it all this time.
I assure you, you can do everything you did before. It'll be even better than before, actually, because it won't break on every upgrade.

Maybe y'all develop differently to me, but personally I wouldn't browse through a random CSS file to find classnames - there's no context (beyond the classname anyway; you don't get any of the cascade, inherited properties etc. that might affect it).
It makes much more sense to use the web inspector to see what is actually being applied to the element you want to change.
It may be a difficult transition at first but i would consider this an opportunity to improve your own development process.

You can add your custom rules to your own custom CSS file, CSS is a cascading language that inherits and overrides rules defined by other stylesheets.

You can safely ignore that log if you don't have Commerce installed. Our logging is a bit verbose for this version so we have extra diagnostic information if needed and we'll be scaling some of that back in future releases.

We'll be decreasing the verbosity of some of the logging in future releases
 

This is EXACTLY what makes it the right solution. This file was specifically created for this purpose. It even says so when you open the file. 
/** * This file is for your custom CSS. * This file is not modified or overwritten during upgrades */ This describes the purpose and why changes should only be made there.
You have no argument against that, because there is none. You are essentially just in denial. You are saying “if I was allowed to do it the wrong way in the past, you better let me keep doing it the wrong way”. And ironically, this practise is NOT an argument to revert the change, but instead an argument to make sure that this practise is indeed being stopped.