Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#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


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/

    diff --git a/django/contrib/flatpages/ b/django/contrib/flatpages/
    index 69e84f8..abb19c1 100644
    a b class FlatPage(models.Model): 
    2525    sites = models.ManyToManyField(Site, verbose_name=_('sites'))
    2727    class Meta:
     28        app_label = 'flatpages'
    2829        db_table = 'django_flatpage'
    2930        verbose_name = _('flat page')
    3031        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 Changed 4 years ago by Tim Graham

Summary: Can't reuse code from django.contrib.flatpagesAllow using parts of flatpages without install the app
Triage Stage: UnreviewedAccepted

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.

comment:2 Changed 4 years ago by Vlastimil Zíma

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 Changed 4 years ago by Vlastimil Zíma

Has patch: set
Owner: changed from nobody to Vlastimil Zíma
Status: newassigned

comment:4 Changed 4 years ago by Aymeric Augustin

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 Changed 4 years ago by Aymeric Augustin

comment:6 Changed 4 years ago by Tim Graham

Resolution: wontfix
Status: assignedclosed

#27109 is the ticket to make the Flatpage model swappable.

#26401 confirmed that you can disable creation of the model with: MIGRATION_MODULES = {'flatpages': None}

comment:7 Changed 4 years ago by Vlastimil Zíma

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 Changed 4 years ago by Vlastimil Zíma

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.

Note: See TracTickets for help on using tickets.
Back to Top