Forums

When I add new item to my site from admin panel, I have this error. Why? I read one topic, and one man wrote, that he have this problem on upload img. So, I think, I to, but how I can solve this problem? My model is my portfolio work, so it contains of name, about text, preview image, big image and link to this site

DartBein and I have been discussing this over email, and it looks like there are two problems:

1. A general Internal Server Error: until we put in a fix just now, PythonAnywhere had a limit of about 128KB for uploads to users' web applications -- this was a default that we'd not been aware of. We've now bumped that up to 2MB -- and can bump it up further if people want. Just leave a comment below.

2. A message like "Incorrect string value: 'some-unicode' for column 'change_message' at row 1 ". DartBein's Django app was set up to work in a language that uses non-latin characters. Our "Create database" button creates databases with the latin1 character set (which we should change) and so when Django tried to write non-latin text to the "messages" table it uses to keep a log of what people do in the admin app, it failed. This is a pain to fix. You can change the default character set for the database by creating a MySQL console and then running

   alter database DATABASENAME character set utf8
   

   ...but that will only affect new tables. So then you need to go through all of the existing tables and do

   alter table TABLENAME convert to character set utf8;
   

   Alternatively, if it's a new app, and you don't mind deleting all of the data, you might just want to run

   ./manage.py reset auth
   

   ...to recreate the auth tables. And perhaps the same for the other apps.

This fix now allows 2MB web2py uploads! Thanks PythonAnywhere! :)

You're welcome :-)

It might be nice if this were exposed as a variable that we could set ourselves per domain just like the static files support.

Nice idea, I'll put that on the list. Not sure how easy it would be to do, though -- the uwsgi config is per-web-app, but IIRC this was in the nginx config, which is generic...

It's on the list, that works for me...☺

Also, it would be important to check whether the data is cached anywhere, or streamed directly to people's web apps - if it's cached (as I suspect it might be) then setting it excessively high might be open to abuse.

Unfortunately there probably use legitimate use-cases for large uploads, such as an online gallery where users can upload a large zip file of photos. These cases are probably rare enough that it's worth waiting to see whether any pop up in practice, though. Might be worth a FAQ entry in the meantime (probably a generic "what are the system limits" entry which covers upload sizes, request header limits, disk quotas, etc.)

Nice idea -- thanks, Cartroo.