Nothing will happen when you upgrade from v4 to v5 regarding storage location. This is a deprecation warning for a future release. When, we don't know yet.

They keep removing more and more features. soon this software will be stripped down to the bare minimum. How are we supposed to store large amounts of files? In my community, we host a lot of large attachments.

Edited December 11, 2024Dec 11 by PanSevence

Well, the feature is not removed yet.

Second, I constantly evaluate if the money is worth it or not. Currently, for me, it is. No doubt. So, if the future removal of this feature is critical for you start looking for alternatives. Start now, so you have a plan B if it comes into action, even if it's long away.

 

How are we supposed to store large amounts of files?

If I understand it correctly, you store it like you do now. You just don’t use MULTIPLE locations, but one. So, let’s say you have only attachments on S3 and everything else in your website’s /uploads folder, you would move the stuff from the uploads folder to your S3 location too. 

Yes, that is correct

Currently, I store my files for Downloads outsite webroot. Only these files, nothing else. This prevents direct linking to the file itself. As a user you always have to use the software to reach the files. Do you have any plans how the files are protected against direct linking or is this already implemented?

Explanation: I bought your complete package in 2009 and somewhere it was suggested that for Downloads you should use a folder outside webroot to protect against direct linking. But please don't ask me where I read that here... 🙂

Edited December 11, 2024Dec 11 by Hatsu

 

Nothing will happen when you upgrade from v4 to v5 regarding storage location. This is a deprecation warning for a future release. When, we don't know yet.

...but the v5 settings (that are in place now) as far as I read it, will not allow any movement from various individual locations (s3), after the upgrade to v5

so any changes to file storage locations really need to be done before upgrade to v5?

 

 

 

 

 

...but the v5 settings (that are in place now) as far as I read it, will not allow any movement from various individual locations (s3), after the upgrade to v5

so any changes to file storage locations really need to be done before upgrade to v5?

I think you can’t add NEW storage locations anymore. Moving is still there. It has to be. After all, that’s what they want you do to. 

 

Do you have any plans how the files are protected against direct linking or is this already implemented?

Download settings (both 4 and 5):

Lots of good feedback here.

Our aim was to reduce the complexity of all the various locations people can choose to store files. We have seen tickets where people have multiple /uploads/{name}/ folders with theme resources in one, screenshots in other and often they change their minds and move them about, often with tasks locking up and issues until the move is finished.

In v5, we wanted to simplify that remove the ability to spread files all over a web server when really you should only ever need one location. There isn't really a reason to have some files on disk, and some in S3 for example. It overcomplicates the software and can get people into trouble.

That said, the inability to specify a path outside of the web root is valid, and we'll have a think about that.

On upgrade to v5, multiple file storage locations will remain, but you won't be able to add any new ones. We're not moving files around on upgrade as that would cause all kinds of issues.

 

...

That said, the inability to specify a path outside of the web root is valid, and we'll have a think about that.

...

Thank you.

 

Lots of good feedback here.

Our aim was to reduce the complexity of all the various locations people can choose to store files. We have seen tickets where people have multiple /uploads/{name}/ folders with theme resources in one, screenshots in other and often they change their minds and move them about, often with tasks locking up and issues until the move is finished.

In v5, we wanted to simplify that remove the ability to spread files all over a web server when really you should only ever need one location. There isn't really a reason to have some files on disk, and some in S3 for example. It overcomplicates the software and can get people into trouble.

That said, the inability to specify a path outside of the web root is valid, and we'll have a think about that.

On upgrade to v5, multiple file storage locations will remain, but you won't be able to add any new ones. We're not moving files around on upgrade as that would cause all kinds of issues.

Can understand the reasoning for a one location approach but I would prefer if each app such as gallery, forum/attachments, cms etc still keeps its own individual folders, even it's under a single uploads such as /uploads/gallery/

the main reason being for own use is backup reasons, but also maintenance and trouble shooting as I have large numbers of files in each folder app

which if there was all-in folder, where all files from all apps went in say a '/uploads/monthly_2024_11/' feel it could be very unwieldy imo

 

 

 

 

 

 

Edited December 11, 2024Dec 11 by sound

 

Can understand the reasoning for a one location approach but I would prefer if each app such as gallery, forum/attachments, cms etc still keeps its own individual folders, even it's under a single uploads such as /uploads/gallery/

As mentioned by Matt in the message you quoted there, this was to reduce the complexity of what people can choose, and reduce issues within the platform.

I will never use it as long as it only supports AWS, there must be cheap alternatives.

 

As mentioned by Matt in the message you quoted there, this was to reduce the complexity of what people can choose, and reduce issues within the platform.

Will this be removed for both cloud clients and self-hosted? Maybe just add a warning in the ACP that changing the storage location could break the site.

 

Well, the feature is not removed yet.

Second, I constantly evaluate if the money is worth it or not. Currently, for me, it is. No doubt. So, if the future removal of this feature is critical for you start looking for alternatives. Start now, so you have a plan B if it comes into action, even if it's long away.

Yes, I am considering various options. Currently, I really like IC5, and I will definitely stay with it for a few more years to see how everything unfolds.

I am closely observing the new Vitnode software, which could be an ideal alternative for self-hosting users in the future if the Invisoon team completely abandons this version or continues to limit it further.

 

Yes, I am considering various options. Currently, I really like IC5, and I will definitely stay with it for a few more years to see how everything unfolds.

I am closely observing the new Vitnode software, which could be an ideal alternative for self-hosting users in the future if the Invisoon team completely abandons this version or continues to limit it further.

With Invision Community v5, we've removed the ability for self-hosted English users to type the 16th letter of the alphabet.

I'm literally taking the P here.

 

Can understand the reasoning for a one location approach but I would prefer if each app such as gallery, forum/attachments, cms etc still keeps its own individual folders, even it's under a single uploads such as /uploads/gallery/

the main reason being for own use is backup reasons, but also maintenance and trouble shooting as I have large numbers of files in each folder app

which if there was all-in folder, where all files from all apps went in say a '/uploads/monthly_2024_11/' feel it could be very unwieldy imo

I see where you're coming from but is it really any easier? Instead of inspecting the source code and seeing /uploads/monthly_2024_12/file.jpg and then going to that one folder, you're seeing /uploads/gallery/file.jpg and then going to that folder.

It might feel odd to have different kinds of files mixed up, but it's all 0s and 1s on a disk somewhere and the software can figure it all out so you don't need to worry about it.

 

With Invision Community v5, we've removed the ability for self-hosted English users to type the 16th letter of the alphabet.

I'm literally taking the P here.

There's no point in hiding the truth. Please answer my question: when I have so many attachments that one server can't handle them, I need to use storage servers.

Edited December 12, 2024Dec 12 by PanSevence

 

There's no point in hiding the truth. Please answer my question: when I have so many attachments that one server can't handle them, I need to use storage servers.

We handle hundreds of terabytes of attachments without issue. 

 

I see where you're coming from but is it really any easier? Instead of inspecting the source code and seeing /uploads/monthly_2024_12/file.jpg and then going to that one folder, you're seeing /uploads/gallery/file.jpg and then going to that folder.

It might feel odd to have different kinds of files mixed up, but it's all 0s and 1s on a disk somewhere and the software can figure it all out so you don't need to worry about it.

While I don't argue with the 0 and 1 part it's sometimes easier to find something in your files when you know where to look. F.e. I coincidentally found an orphaned Downloads file which should long have been deleted but somehow wasn't. I agree that shouldn't happen. I agree for us as users of your software it shouldn't make a difference. But I think your approach is a bit too technical and doesn't consider how human beings work sometimes 🙂

I agree that the current storage system is overwhelming and not very user friendly. If I remember correctly when I moved my Downloads files outside web root I moved everything of Downloads out of web root which of course didn't work because the screenshots weren't available in the browser then.

But I think there is some kind of compromise 🙂

 

Please answer my question: when I have so many attachments that one server can't handle them, I need to use storage servers.

That’s a claim, not a question. 😉 But seriously, it’s not even related to deprecating multi-location storage. Even in the current system, you can’t split one type of content (e.g. attachments) between multiple storage locations when they fill up your disk space. You would obviously have to get a storage solution that is scalable, whether it’s with your hosting provider or an external solution like S3. 

 

We handle hundreds of terabytes of attachments without issue. 

So how can we do this if it will be deprecated in the future?

 

So how can we do this if it will be deprecated in the future?

You should use a service like S3, B2, or countless others designed for mass-media storage.

 

So how can we do this if it will be deprecated in the future?

Nothing is being deprecated.

If you are looking to store multiple TBs of data, then either get a disk big enough or better, find a storage solution designed to scale with your needs, like B2, S3. These are not expensive services.

I'm a little taken aback that IPS is referencing Backblaze as a formally supported solution by the company.  Was this ever announced in your documentation? I would have strongly considered them as a storage solution if I knew.  

I was always under the impression that IPS only supported Amazon S3. And although the third party community provided an informal plugin for S3 compatible storage, this was never officially supported by IPS.  

To the topic at hand, I could care less if IPS wants to group all storage into one.  My only ask is that IPS retains top-level folder categories of at least Attachments vs Gallery vs Downloads.  This is the one benefit that I currently have of different storage buckets, and I periodically need to investigate content / DMCA takedowns so this organization helps tremendously. 

Backblaze is S3-compatible. It, and every other S3-compatible service, can be used right now. However, we are adding a direct Backblaze integration for those who don't know that but it's really just a copy/paste of the S3 integration with wording changed to say Backblaze instead of AWS S3.