#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 , 9 years ago
| Has patch: | set |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
comment:4 by , 9 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 , 9 years ago
I proposed to close #26401 as wontfix: https://code.djangoproject.com/ticket/26401#comment:8
comment:6 by , 9 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | assigned → closed |
comment:7 by , 9 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 , 9 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
FlatPagemodel to inner imports might be the more correct solution.