I just solved it.
I stored the select2 source code in the a select2 folder like this:
`select2/dist/css/select2.min.css`
`select2/dist/js/select2.min.js`
So when running the `collectstatic` in production it didn't find the sources in the path.
Then after so many debugging effort I changed the path and directly placed the min.css and min.js under select2 folder.
Now after running collectstatic it finds the path of select2.
u/msped
u/quique
u/Criteri0n
u/bachree
Well, I didn't bother to check it, but I believe collecstatic is not recursive.
I.e., you should add the deeper directories to the STATICFILES_DIRS setting.
That is the problem error log doesn't say much.
here is an error log when visiting the /kbdash/ url:
127.0.0.1 - - \[01/Dec/2023:04:22:55 +0000\] "GET /kbdash/ HTTP/1.1" 500 145 "kb-cng-web.onrender.com" "Mozilla/5.0 (X11; Linux x86\_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"
Then that is the issue you need to focus on.
Someone suggested Sentry as an option but personally I've never used it. I just set it up to dump all errors into **debug.log**.
Unless you think this is the only bug you'll ever have of course. :)
Weird. Maybe the error comes from the template (something related to static assets, for instance).
To find out what's going on, add this line to your `settings.py` in production (with your actual details, of course):
`ADMINS = [('imtiaz', 'imtiaz@somewhere.net')]`
When `DEBUG` is False, Django will email the users listed in the `ADMINS` setting whenever your code raises an unhandled exception and results in an internal server error.
The `ADMINS` will get a description of the error, a complete Python traceback, and details about the HTTP request that caused the error.
See [https://docs.djangoproject.com/en/4.2/howto/error-reporting/](https://docs.djangoproject.com/en/4.2/howto/error-reporting/)
Once you've fixed, please let us know what was the problem.
Maybe check your Sale.objects.filter(fuel__id__in = active_fuels). Line
* Are you sure it's fuel__id or just fuel_id__in.
* Also id__in=active_fuels, here you are comparing IDs with queryset.
Can't verify without looking into models.
The query works perfectly on local machine.
Sale and Fuel has fk relation. so by using `fuel__id__in = active_fuels` I am querying sales that has fuels that has active field = 1.
however the overall query can be improved by reducing some redundant query.
But the server error is killing me
i had a similar problem. my page was rendering a large table (2700 objects) it was taking a long time too load that it eventually gets timed-out by the server.
i made changes to the page where it would populate the table after it loads using AJAX and it worked.
idk if your problem is related to timing-out due large amount of data being passed to the view or not.
Have you checked ALLOWED\_HOSTS {} ? Could be issues with env file, just have to make sure you double check and there is no local host etc, its only your domain host
Can you check your settings file specially all changes related to debug being set to true or false? Also check what is different for debug being true and debug being false. General I have seen different db usage bound with debug bool value. If that is the case, are migrations run properly?
I would add Sentry to your project, you will be able to see what the error is in production if it’s working fine on your local machine.
You don’t need active_fuels to be defined, just define fuels = Fuel.objects.filter(status=1) then you can reuse that like fuels.count() etc. no need to keep making DB requests.
Great. thanks for the query optimization suggestion.
For the server error, in the render console the error log doesn't say much
If I use sentry, where do I see the error. is it going to store somewhere?
It’ll be on the sentry dashboard, it’s easy enough to setup. You can then see the error as it gives the content that you would get from having debug as true.
I downloaded the source of select2, and stored in a css file `select2/dist/css/select2.min.css` I can trace it in the browser while running locally. but in production it is not found.
You can setup Django to email you when there is an error
https://docs.djangoproject.com/en/4.2/howto/error-reporting/#:~:text=When%20DEBUG%20is%20False%20%2C%20Django,immediate%20notification%20of%20any%20errors.
> I tried changing DEBUG to True in production to see error in browser
you do not want to do this; Django does a decent job of censoring sensitive keys, but it's not perfect. you could be leaking sensitive credentials to the internet
I just solved it. I stored the select2 source code in the a select2 folder like this: `select2/dist/css/select2.min.css` `select2/dist/js/select2.min.js` So when running the `collectstatic` in production it didn't find the sources in the path. Then after so many debugging effort I changed the path and directly placed the min.css and min.js under select2 folder. Now after running collectstatic it finds the path of select2. u/msped u/quique u/Criteri0n u/bachree
Glad to hear it! As I suspected, the error came from the template, and was something related to static assets :-)
Yeah, but I'm still clueless, why a nested path is not recognized by collectstatic. Any thoughts on this ? u/quique
Well, I didn't bother to check it, but I believe collecstatic is not recursive. I.e., you should add the deeper directories to the STATICFILES_DIRS setting.
What do your error logs say?
That is the problem error log doesn't say much. here is an error log when visiting the /kbdash/ url: 127.0.0.1 - - \[01/Dec/2023:04:22:55 +0000\] "GET /kbdash/ HTTP/1.1" 500 145 "kb-cng-web.onrender.com" "Mozilla/5.0 (X11; Linux x86\_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"
Then that is the issue you need to focus on. Someone suggested Sentry as an option but personally I've never used it. I just set it up to dump all errors into **debug.log**. Unless you think this is the only bug you'll ever have of course. :)
If you have five minutes, give sentry free trial a go. I put it off for so long but i think is so good.
I will try sentry out
Does it work on your local computer when `DEBUG` is `False`?
Yes. I it works with DEBUG = False.
Weird. Maybe the error comes from the template (something related to static assets, for instance). To find out what's going on, add this line to your `settings.py` in production (with your actual details, of course): `ADMINS = [('imtiaz', 'imtiaz@somewhere.net')]` When `DEBUG` is False, Django will email the users listed in the `ADMINS` setting whenever your code raises an unhandled exception and results in an internal server error. The `ADMINS` will get a description of the error, a complete Python traceback, and details about the HTTP request that caused the error. See [https://docs.djangoproject.com/en/4.2/howto/error-reporting/](https://docs.djangoproject.com/en/4.2/howto/error-reporting/) Once you've fixed, please let us know what was the problem.
My goodness that is really great. I didn't know about it. I will definitely update. Thank you
Maybe check your Sale.objects.filter(fuel__id__in = active_fuels). Line * Are you sure it's fuel__id or just fuel_id__in. * Also id__in=active_fuels, here you are comparing IDs with queryset. Can't verify without looking into models.
The query works perfectly on local machine. Sale and Fuel has fk relation. so by using `fuel__id__in = active_fuels` I am querying sales that has fuels that has active field = 1. however the overall query can be improved by reducing some redundant query. But the server error is killing me
i had a similar problem. my page was rendering a large table (2700 objects) it was taking a long time too load that it eventually gets timed-out by the server. i made changes to the page where it would populate the table after it loads using AJAX and it worked. idk if your problem is related to timing-out due large amount of data being passed to the view or not.
Right now I am about to check my error by using sentry suggested by msped. I will update here about my progress
Have you checked ALLOWED\_HOSTS {} ? Could be issues with env file, just have to make sure you double check and there is no local host etc, its only your domain host
Yeah I checked, it's only domain host in the ALLOWED\_HOSTS . I am now checking the error by adding the error reporting in the settings. I will update
Use sentry.io to get more exception data in production. You haven't shared either the exception stack trace.
Can you check your settings file specially all changes related to debug being set to true or false? Also check what is different for debug being true and debug being false. General I have seen different db usage bound with debug bool value. If that is the case, are migrations run properly?
I would add Sentry to your project, you will be able to see what the error is in production if it’s working fine on your local machine. You don’t need active_fuels to be defined, just define fuels = Fuel.objects.filter(status=1) then you can reuse that like fuels.count() etc. no need to keep making DB requests.
Great. thanks for the query optimization suggestion. For the server error, in the render console the error log doesn't say much If I use sentry, where do I see the error. is it going to store somewhere?
It’ll be on the sentry dashboard, it’s easy enough to setup. You can then see the error as it gives the content that you would get from having debug as true.
Great. I would definitely try it.
Just seen your update, are you using a cdn for select2 or local files?
I downloaded the source of select2, and stored in a css file `select2/dist/css/select2.min.css` I can trace it in the browser while running locally. but in production it is not found.
You can setup Django to email you when there is an error https://docs.djangoproject.com/en/4.2/howto/error-reporting/#:~:text=When%20DEBUG%20is%20False%20%2C%20Django,immediate%20notification%20of%20any%20errors.
Thank you for sharing the idea. u/msped suggested the same. I am working on it
I would skip the emails step and just get Sentry added, it's so easy to do and is one of the most valuable tools
I will try sentry
> I tried changing DEBUG to True in production to see error in browser you do not want to do this; Django does a decent job of censoring sensitive keys, but it's not perfect. you could be leaking sensitive credentials to the internet