I have a Django project that employs modeltranslation. On the development box, it registers 10 models and works flawlessly.
On the production server, when started it notifies that it has registered "0" models (instead of 10) and doesn't throw any exceptions. However when any admin page that shows a should-be-registered model is visited, the NotRegistered exception is thrown.
All non-admin pages, and admin pages that don't include translated models work without problems.
Suggestions are highly appreciated.
Moving the modeltranslation folder from the project folder into the packages folder resolved the issue.
have a look into your database, i would bet that "syncdb" did not add the required colums/tables
if you have no production data on the database: simple delete it and re-sync it
Related
Django 1.11
If I click Groups in Django admin site, I can see a list of groups. Namely, the address is http://localhost:8000/admin/auth/group/
I monitor the CPU usage in terminal. Python is consuming 4-5 % now.
I have organized 4 groups. So, if I click any group, the server just calculating something for several minutes. The address now is like http://localhost:8000/admin/auth/group/6/change/
Maybe about 5 minutes the server is calculating something. And Python is now consuming 100 % of CPU resources.
Well, Django admin is analyzing something.
I have about 23-25 models. Well, this is not a very big number of models.
Each model is 3 standard permissions (add, change, delete). And I created one permission myself in the Meta class of a model.
So, as soon as "Change group" page is in front of me with available permissions and chosen permissions, CPU consumption by Python is again 4-5 %.
Could you comment on this? Is it curable?
Came across this issue when using django debug toolbar with the built in django admin app. The change/update page was incredibly slow locally (sometimes it would not load at all) but if I set DEBUG=False (thus turning the debug toolbar off) it worked as expected. In my particular case, I didn't need the debug toolbar for the admin app so I disabled it for only those admin URLS like so:
# settings.py
DEBUG = True
def show_toolbar(request):
# disable debug toolbar for built in admin app urls only
if request.path.startswith('/admin'):
return False
else:
return True
DEBUG_TOOLBAR_CONFIG = {
'SHOW_TOOLBAR_CALLBACK': show_toolbar,
}
We're using the same setup as Max Malysh:
Django 1.11
A custom User model based on django.contrib.auth.models.AbstractUser
The custom user model set in the settings via AUTH_USER_MODEL variable
We've got the same issues and I think I found the issue, or at least the module which is causing the delays. It has nothing to do with Django and/or the DEBUG mode itself, because I think the issue is within the debug_toolbar.
If you deactivate the debug_toolbar application and debug_toolbar.middleware.DebugToolbarMiddleware middleware, it works like a charm.
I didn't had the time to reverse-engineer it, but I'll have a look at it when I find the time. In the meantime and as a workaround, deactivate the debug toolbar if you don't need it.
Sorry, it's not a final solution yet, but I thought I'll share my findings in case they can help somebody.
Cheers
Domi
EDIT/UPDATE: It has something to do with the Template panel of the Debug Toolbar. If you deactivate it, you'll have a much faster response time!
I've encountered the same problem when adding a new group with Debug=True in settings.py.
The same code works fine with Debug=False.
Some background information:
We use Django 1.11
We use custom user model inheriting from AbstractBaseUser
There are ~30 models registered on the admin site
Django debug toolbar output:
I was experiencing this same problem, but probably for a different reason than the OP was.
If you have a large number of Users, look at your admin.py and make sure that you are not displaying Users inline on the Group admin page. That can cause very slow loading of the Group admin page if the Group has a large number of users in it.
I have a huge... challenge in front of me. For about a week or two I've been migrating 1.5.5 django project to 1.7.1. A huge jump, many deprecated variables, methods and so on.
In 1.5.5 there were some south migrations done but not everywhere, as it was not implemented from the beginning. So let's say there are no migrations, they have to be created.
Also there is a wish to add a cms to the already upgraded project, but with django-cms-3.0.7 I constantly encounter some issues with migrations, south existing etc.
Is there a CMS that I can use with this app that won't be bothered by migrations and django version?
All I want to edit is the static content (text, images, maybe adding videos) before user logon. No integration with models. Just some info pages.
Any suggestions?
A maybe oversimplified solution for this could be django-front. Create your static pages and add the fields you want to edit. You edit it with a wysiwyg editor. I use it for my terms of service/privacy policy.
You will probably be always bothered by migrations and django version when using an app that brings extra functionality, but the apps should not be hard to upgrade and normally they have a warning/walk through when an important change on their arquitecture/functionality has happened.
That being said, i don't think migrations change dramatically now. The change to include them in the django project was an important (and needed) one.
If you want something even more simple (and time resistant) just create a model for your pages and render it on your template:
class Content(models.Model):
html_content = models.TextField()
image_content = models.ImageField()
Register that model to your admin and that should do the trick. For simple applications this may be enough.
I just delayed my first Django app via Heroku and I'm having an issue that's proving very difficult to resolve. I have django-registration and profiles installed and apparently something runs afoul unless the 'django.contrib.sites', and SITE_ID is removed from settings. Unfortunately, when content is submitted by a user to be displayed, I'm getting the following error:
TemplateSyntaxError at /Caught AttributeError while rendering: 'Settings' object has no attribute 'SITE_ID'.
Only when deleting the user submitted content via the admin does the site reestore.
Adding django.contrib.sites and SITE_ID back just kills the whole app. These issues did not arise during initial development, but only began when the app was deployed. Looking to see if anyone has any insight or advice on how to resolve this.
What kind of error do you get when you add SITE_ID in the settings file?
This problem usually occurs when there is a discrepancy with data in the table django_site. Check if your dev and prod database have the same values in that table. Some models may refer to some Django models that use the Site models itself, and unless they cannot find a valid django.contrib.sites.models.site instance in the database, they will raise an exception. This happens if using the FlatPage models for instance.
My django site was functioning before I installed Lion and had to reinstall everything related to development. Since then, I have deleted and recreated my database, but one of my two installed apps is being ignored in syncdb. Those tables are not present in my database.
This post suggested there might be an import error. I can import the app in question using manage.py shell, so I don't think that's it.
Both apps are definitely installed (verified by debug toolbar). Any other suggestions? I'm relatively new to Django, having been mostly an iOS developer for the past couple of years.
https://docs.djangoproject.com/en/dev/ref/models/options/#app-label
If a model exists outside of the standard models.py (for instance, if the app’s models are in submodules of myapp.models), the model must define which app it is part of.
What it doesn't mention is that they also have to be imported somewhere during the model registration phase.
We're running a Django website with rough 45 install Django admin classes. The handler is mod_fastcgi. Every once in a while about half the admins disappear from /admin/ screen. Touching the production.fcgi file restores everything to normal, but we have yet to determine the underling cause.
Any thoughts on what the underlying issue might be?
Django turns off admin for the model when it encounters an exception in admin. Examine admin code and make proper exception handling.