Stuart Silvester

Hi, Please respond to one of the emails we sent to you, unfortunately we cannot address billing issues via our Community.

Yes, that was specific to sorting the category/album by Caption or Rating. We have addressed the issue with sorting by recently updated (specifically, when more than one image has the same timestamp). This fix is available via a new patch. It can be installed from the support page of your AdminCP.

Since you're upgrading too, you'll need to complete that process (that's why you're seeing a missing table). The issue with PHP sessions will need to be fixed with whomever manages your server. It could be something like a misconfigured path for storing PHP sessions, or the path isn't writable. The host will know more about that. `TEXT_ENCRYPTION_KEY` is only used for some areas, such as storing username and password data in Commerce, or storing the answers to the security question MFA. If you don't use either of those, you don't need to worry about that.

4.7.4+ requires a minimum of PHP 8 (4.6 required PHP 7.4+), it will not work on PHP 7. You will need to update to PHP 8.0 or 8.1 and then perform a manual upgrade.

Not really, I was talking about a theoretical 'now' thing. I would refer you to Matt's post above

I would recommend taking a look at this post from @Charles he's looking for specific feedback about Cloud from those that aren't at the moment interested (and that's also fine, it won't be suitable for everyone).

We solved your issue via the ticket you created. Short story is, HTTP 500 error was being caused by an incompatible 3rd party application.

4.5.x will only work on PHP 7.2/7.3/7.4. The syntax error is because the code is not compatible with PHP 5. After ensuring your server meets the latest requirements via the requirement checker, you can perform a manual upgrade to the latest version -

I think it's worth pointing out that this is a Cloud feature that we've had advertised as coming soon on our pricing page for a while. That may seem like an obvious 'win', but when you factor in ongoing costs, support overhead, refactoring all of our code to allow this to work. You would most likely be looking at a cost greater than one of the Cloud packages with the feature.

I wanted to provide some background on why we've made this change. We were experiencing some reliability issues with the future publishing functionality across the platform in 4.7.7, and we had to revert some recent fixes for bugs and go back to a known state. During that testing, we repeatedly ran into issues with publishing new items with dates in the past, which is why we made the decision to disable the ability to add new items to the past. In older versions, setting a publish date was something specific to Pages, then we expanded it to cover more areas. If you have any specific use cases for this feature, please let us know. Your input will help us determine the best way to move forward and ensure that our platform meets the needs of all our users. I did see how @Dreadknux uses this functionality to backdate press releases and articles for legacy consoles.

Thank you for bringing this issue to our attention, CodingJungle. We understand your frustration and apologize for any inconvenience this may have caused you. However, it's important to note that when customers manually write custom code to interact with our framework, it's their responsibility to ensure that it's compatible. While we do our best to provide support and address issues as they arise, we cannot guarantee that every possible combination of custom code will work seamlessly with our framework. We appreciate the solution you came up with and shared with us. Moving forward, we will do our best to improve the framework and ensure that our customers have a smoother experience. I did look further today to see if there's something we could implement to at least stop this causing a fatal error. I've committed an idea and put it to the rest of the development team for review. I can't guarantee we'll proceed with it after review and testing, but it looks hopeful.

It's part of a minor new feature we were introducing in 4.7.7. It wasn't working very well so we disabled it and will revisit it in a later release.

You're including code in your custom project that requires PHP 8 to run, you'll need to use PHP 8. It has been clearly advertised that we were moving to PHP 8 as a minimum version, we gave months of notice. Your developer has to be responsible to keep your project up to date, PHP 7 has reached end of life and likely contains security vulnerabilities that have not been patched. The only way to downgrade would be to restore a backup that was created before your upgrade.

Likely further out, we've still a fair amount of work to do with PHP 8.1 [and PHP 8.2]. The timeline on the PHP Supported Versions page would be a good one to follow.

Your forums are in a folder called /forums/. You'll need to go into that folder to see the Invision Community files.

Invision Community 4.7.4+ requires a minimum of PHP 8.0. Each release will have more PHP 8 specific code in it.

It would be worth checking that your custom code is using PHP 8 and not PHP 7

No problem!. I see where the confusion is now. 4.7.4 made PHP 8.0 the minimum required version.

This issue has been addressed in a new version, upgrading will solve this. Invision Community 4.6.0+ supports PHP 8

We're aware of some issues with slowness on some endpoints, this is causing timeouts on the client (AdminCP) side. We're continuing working to resolving the issue.

The constants are documented in the init.php file // Enable test/sandbox mode for Commerce payment gateways? // Sets all payment gateways into test/sandbox mode and makes a generic "Test Gateway" // which just acts as if a payment was successful available. Is used in development // so they can be tested without actually taking any money. If you enable that constant, you will not be able to get paid any real money since gateways will use the sandbox versions (where applicable)

Bump3 I've logged an internal bug report so we can evaluate further. We do want to move more towards the native browser lazyload (such as we've done in Gallery) however we need to consider the trade-offs. The native functionality also has the same drawback as this bug where it won't work on dynamically loaded content.

Sorry, yes. To clarify, it would be a hard limit based on server variables. Yes, Rikki moved on recently The biggest Gallery changes were indeed the visual overhaul, including an entirely new front page. The changes also include performance and usability improvements such as shrinking the amount of Javascript used and migrating to browser native lazyload functionality. There's more of an overview here: Make note of the last line of the blog too!

1/2. We do want to improve the Gallery submission process, but I'll look into whether we can add a hard limit per batch for now. 3. Our next beta should have some sorting fixes included. Do you have any logs for slow queries? We have a number of fairly large galleries on Cloud and we're not seeing any slowness currently. It may be something specific to your MySQL/MariaDB version or just the horsepower behind the server. Any slow logs would be useful though. No, this is specifically for one member submitting lots of images at once.