Jump to content

Stuart Silvester

Invision Community Team
  • Posts

    3,654
  • Joined

  • Last visited

  • Days Won

    27

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Projects

Release Notes v5

Forums

Events

Store

Gallery

Everything posted by Stuart Silvester

  1. This issue was specific to changes in later versions of PHP 8.0 and 8.1. Whatever you are seeing, will not be the same issue. Can you share some of your system logs showing the error?
  2. Randy's comment certainly was helpful, the majority of people that pay for self-hosting wouldn't have any idea what type of PHP handler they use.
  3. Yes, we use caching at a few levels. Check back soon and it should have cleared.
  4. 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.
  5. The reason it works this way is because some email clients/email delivery services will automatically follow links in the emails. This could cause a bad experience for the end-user since the email is automatically verified (whether it was valid and delivered or not) and the one-time validation URL would no longer be valid.
  6. The report has been triaged and should be assigned to a developer soon.
  7. Thanks! This is a PHP bug that's fixed in 8.1.10 - https://bugs.php.net/bug.php?id=81263
  8. Which version of PHP 8.1 are you using where the issue is present?
  9. We'll be decreasing the verbosity of some of the logging in future releases
  10. Personally, when I'm theming or updating CSS for something on my site, I'm in the browser inspector for most of time. Looking at how the relevant rules interact with each other and determining which change I want to make to achieve my goal.
  11. The EU VAT service updated their API. I sent them an email a few weeks ago and received a response on Thursday. We've made the required changes which should be in the next monthly release.
  12. 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.
  13. You should be adding any custom CSS to the custom.css file instead of editing the CSS distributed by other apps. You'll only give yourself headaches upgrading them in future.
  14. Unfortunately that's the nature of these types of things now causing fatal errors. Matt did a pass of some stuff that wasn't consistent in our own code but in future non-major releases we're going to be mindful to avoid changing method signatures unless we really need to - sometimes it's just not possible to avoid.
  15. It's not related to the filename, it's related to the file contents in specific contexts. You'll notice if you open that file directly in your web browser, it renders perfectly.
  16. We've still got an open bug report for this. Essentially it appears to be a bug in Chromium where it has issues rendering gradients under specific circumstances.
  17. 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.
  18. 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.
  19. 4.7.2 onwards does check the status with the Marketplace as detailed here: We however don't know whether an app/plugin needs disabling until the new core files are present on your system. They're used for real-time comparisons and tests to determine if there's going to be a fatal error. The app scanner isn't a requirement for developers to be able to test their code and ensure it works with PHP 8.1, they'll see the fatal errors occur when testing.
  20. I have created a support ticket for you so we can look further into that app that was disabled Unfortunately due to PHP 8+ changes it has to be this way. If you update and you have something that isn't compatible with the codebase, you will have a completely unusable site.
×
×
  • Create New...