#26762 closed Bug (wontfix)
Allow using parts of flatpages without install the app
Reported by: | Vlastimil Zíma | Owned by: | Vlastimil Zíma |
---|---|---|---|
Component: | contrib.flatpages | Version: | 1.9 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Our application uses it's own version of django.contrib.flatpages
. To reduce the amount of code needed to reuse flatpages (which is a lot, but that's another issue) we reuse as much code from flatpages as we can - e.g. FlatpageForm
, render_flatpage
and so on. We don't have django.contrib.flatpages
in INSTALLED_APPS
and we really don't want to do that, since it raises a whole other set of issues. It works fine in Django 1.8, but stops to work when we switch to Django 1.9 with error
RuntimeError: Model class django.contrib.flatpages.models.FlatPage doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.
The error itself doesn't quite make sense, since we don't use FlatPage
model at all, it just gets loaded.
There is simple fix which allows flatpages to be at least somewhat reused even in 1.9, that is defining the app_label
in FlatPage
.
-
django/contrib/flatpages/models.py
diff --git a/django/contrib/flatpages/models.py b/django/contrib/flatpages/models.py index 69e84f8..abb19c1 100644
a b class FlatPage(models.Model): 25 25 sites = models.ManyToManyField(Site, verbose_name=_('sites')) 26 26 27 27 class Meta: 28 app_label = 'flatpages' 28 29 db_table = 'django_flatpage' 29 30 verbose_name = _('flat page') 30 31 verbose_name_plural = _('flat pages')
I'm aware that this is sort of hotfix, since it doesn't solve underlying issue, but it would allow flatpages to be used as a library.
Change History (8)
comment:1 by , 9 years ago
Summary: | Can't reuse code from django.contrib.flatpages → Allow using parts of flatpages without install the app |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 9 years ago
Personally, I share the carljm's concern ticket:21719#comment:10 that the #21719 causes too many imports to be moved inside functions, which leads to code that is not as tidy as it should be.
comment:3 by , 8 years ago
Has patch: | set |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:4 by , 8 years ago
I also share the concerns expressed in #21719. I made the changes related to that ticket very reluctantly to avoid blocking the 1.7 release.
I would prefer to make the Flatpage model swappable.
comment:5 by , 8 years ago
I proposed to close #26401 as wontfix: https://code.djangoproject.com/ticket/26401#comment:8
comment:6 by , 8 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
comment:7 by , 8 years ago
I such case, it should be noted in documentation. When I search a solution of the above mentioned error, I should be able to find out the MIGRATION_MODULES
workaround.
comment:8 by , 8 years ago
MIGRATION_MODULES
trick doesn't work for tests in 1.9. Test database creation runs migration with run_syncdb=True
which suppresses the effect of MIGRATION_MODULES
override. That results either in conflicts with my own migrations or it creates database different from the one on production.
I found no way to suppress the syncdb
in test database creation.
I guess it's in the same spirit as #26401 (same request for the auth app). I guess moving the import of the
FlatPage
model to inner imports might be the more correct solution.