Suggestion: Allow uploads to the site

[Astuur]

I know that initially there was an agreement not to allow uploads.
But I think it would help a lot for many users if they could at least upload some screenshots
to demonstrate a problem or a certain situation.
Especially the graphicians need to show their suggestions, not describe them.
An additional advantage I see in the fact that we can keep access to the material,
whereas the site posters now turn to, do not store for an unlimited amount of time.

[kaputtnik (franku)]

> I know that initially there was an agreement not to allow uploads.

What were the reasons for this agreement? I know there was a problem with limited Inodes but this has been fixed.

We may could implement something like shown here at the bottom: https://www.file-upload.net/tools.php ...didn't test it...

[SirVer (sirver)]

On the second version of the website we did allow uploads and had a ton of problems with bits uploading torrents and porn pictures.

Even github does not allow arbitrary files for fear of abuse.

I am not in favor of this feature.

Am 22.08.2017 um 19:54 schrieb kaputtnik <email address hidden>:

>> I know that initially there was an agreement not to allow uploads.
>
> What were the reasons for this agreement? I know there was a problem
> with limited Inodes but this has been fixed.
>
> We may could implement something like shown here at the bottom:
> https://www.file-upload.net/tools.php ...didn't test it...
>
> --
> You received this bug notification because you are subscribed to
> Widelands Website.
> https://bugs.launchpad.net/bugs/964452
>
> Title:
> Suggestion: Allow uploads to the site
>
> Status in Widelands Website:
> Confirmed
>
> Bug description:
> I know that initially there was an agreement not to allow uploads.
> But I think it would help a lot for many users if they could at least upload some screenshots
> to demonstrate a problem or a certain situation.
> Especially the graphicians need to show their suggestions, not describe them.
> An additional advantage I see in the fact that we can keep access to the material,
> whereas the site posters now turn to, do not store for an unlimited amount of time.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/widelands-website/+bug/964452/+subscriptions

[GunChleoc (gunchleoc)]

We would need to restrict it to certain file extensions and limit the file sizes. We could also have a requirement of x minimum posts.

[SirVer (sirver)]

But why? Hosters are ubiquitous. Imgur, Dropbox, drive.

I think this is feature creep - we cannot support it well. We have quite limited space on our server and we have to pay for bandwidth.

> Am 23.08.2017 um 10:39 schrieb GunChleoc <email address hidden>:
>
> We would need to restrict it to certain file extensions and limit the
> file sizes. We could also have a requirement of x minimum posts.
>
> --
> You received this bug notification because you are subscribed to
> Widelands Website.
> https://bugs.launchpad.net/bugs/964452
>
> Title:
> Suggestion: Allow uploads to the site
>
> Status in Widelands Website:
> Confirmed
>
> Bug description:
> I know that initially there was an agreement not to allow uploads.
> But I think it would help a lot for many users if they could at least upload some screenshots
> to demonstrate a problem or a certain situation.
> Especially the graphicians need to show their suggestions, not describe them.
> An additional advantage I see in the fact that we can keep access to the material,
> whereas the site posters now turn to, do not store for an unlimited amount of time.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/widelands-website/+bug/964452/+subscriptions

[kaputtnik (franku)]

So some more reasons ;)

Most users do not want to upload images or other stuff. But from time to time the question for file upload raises. The answers are always the same:

- Add it to bug xy on launchpad. You have to create an account for that.
- Use a file/image hoster like yz

What about a wikipage 'File uploads' where we

1. Explain why we do not provide file uploads
2. Explain when one could use launchpad
3. Give some example file/image hoster
4. Provide the markup to get the image into the forum.

I am not a fan for point 3, but since i spend a lot of time to find one without registration, this could be helpful.

Doing so we could point to the wikipage from the forum and mark this bug as won't fix.

[GunChleoc (gunchleoc)]

We already allow uploading images to the wiki, so that might be another option - bandwidth could become a concern, though. I have no idea what to put under 3., because I've always had my own homepage.

[kaputtnik (franku)]

Yes the wiki comes also to my mind... some sort of a special wiki page where people can upload images.

Another approach would maybe to have some sort "user wikipages". A wikipage bound to a specific user where one could upload some things, tell some storys, play with the wiki syntax, give game tips and so on. We could restrict the total amount of uploadable things and can also proof the textual content for spam like we do for pybb right now. Such 'user wikipages' are only editable for the user the page is bound with. For all other users they are readable.

An easier approach is maybe to give the possibility for uploading on a users profile page. So the possibility for uploading is not that present as in the forum and i believe only a few people would find it at all (unless some one points in the forum to this possibility).

I have also a website but i didn't want to use this for widelands, because the link contains the address of my website. The webspace i formerly had was unfortunately deleted in January this year by the hoster :-(

Nevertheless i think we should have a solution for this bug, even if it would be marked as won't fix. SirVer is the maintainer of the server, so he has the last word :-)

[SirVer (sirver)]

> Such 'user wikipages' are only editable for the user the page is bound with. For all other users they are readable.

We are responsible for the content we host. So we would need to make sure that notifications are sent for each edit in such a page so we can review them - the same as for the current wiki right now.

> SirVer is the maintainer of the server, so he has the last word :-)

I only pay for the server and I do it as contribution for Widelands. I will carry any consensus.

A simple solution might be to attach images to posts in the forums, similar to how we can attach them to the wiki. We can even reuse the wlimages application for this. We already monitor the forums by reviewing each post and the images cannot be changed under us. Should space become limited we can always reconsider.

Disadvantage is that we do not get error logs this way.

[kaputtnik (franku)]

> A simple solution might be to attach images to posts in the forums,
> similar to how we can attach them to the wiki.

The current implementation of pybb does just allow this. The images are saved under media/pybb/attachments/ . All what to do is to enable the setting PYBB_ATTACHMENT_ENABLE and add the needed folders which will not be created on demand.

Didn't looked what happens if a user get deleted, if the image get deleted as well.

As GunChleoc says: We could also have a requirement of x minimum posts before a user get the possibility for uploading. Say allow uploads only after 5 posts.

> Disadvantage is that we do not get error logs this way.

Can you explain?

[SirVer (sirver)]

> We could also have a requirement of x minimum posts before a user get the possibility for uploading. Say allow uploads only after 5 posts.

I am not a fan of this. It would mean spammers will just spam a few posts before posting attachements. It also alienates new user that signed on to report a bug with a screenshot or so.

>> Disadvantage is that we do not get error logs this way.
> Can you explain?

What I meant was this: if we reuse the wlimages app to allow uploading of images, we will not have the ability to upload log files, only images.

I mean, we could enable PYBB_ATTACHMENT_ENABLE and see if we run into trouble? Should we run into trouble and we need to disable it again, we will probably loose all attachement links though.

What do you think?

[GunChleoc (gunchleoc)]

I think that we should go with PYBB_ATTACHMENT_ENABLE.

If disabling loses us links, so will external hosting when people clean up or discontinue their sites - we have no control over that at all.

[kaputtnik (franku)]

The uploaded files get named with the id of the post. So adding a post with id 9145 the attached file get named '9145.0'. This information is also stored in the model 'pybb.Attachment'. If a post get deleted the entry in the model 'Attachment' get deleted but the file remains.

So uploaded files stay on the server even if the user got deleted (with every post he wrote). In case of rare space it should be possible to delete unwanted files on the server.

Before enabling attachments i think we should add some code to automatically delete the attached file if a post (or a user) get deleted.

[GunChleoc (gunchleoc)]

> Before enabling attachments i think we should add some code to
automatically delete the attached file if a post (or a user) get
deleted.

+1

[kaputtnik (franku)]

Currently access to attachments is only allowed for logged in users. For not logged in users this means:

- clicking on a link containing an attachment shows the login view first
- if the attachment is used inside a post (e.g. ), the image isn't shown

Imho, a normal visitor (not logged in) should get also access to attachments. What do you think?

[GunChleoc (gunchleoc)]

 >Imho, a normal visitor (not logged in) should get also access to attachments. What do you think?

Agreed.

[Toni Förster (stonerl)]

We should run ClamAV and check every upload though. Also uploads shouldn't be allowed, if the user has less than a certain amount of posts, e.g. 3.

[kaputtnik (franku)]

There are some django applications which uses ClamAv, but i am not very convinced about virus scanning. It may lead into false security-feeling: "Oh this is scanned for viruses by widelands.org... then it is save!"

[GunChleoc (gunchleoc)]

We could still can and not tell the user about it.