[Fixed]-Add functionality to Django FlatPages without changing the original Django App


Your approach is fine – you just don’t see the result because the old flatpage model is registered in the admin and the new one isn’t. Here’s what you might do in your new app’s admin.py (using less ambiguous naming than what you’ve got above):

from django.contrib import admin
from django.contrib.flatpages.admin import FlatPageAdmin
from django.contrib.flatpages.forms import FlatpageForm
from django.contrib.flatpages.models import FlatPage

from models import ExtendedFlatPage

class ExtendedFlatPageForm(FlatpageForm):
    class Meta:
        model = ExtendedFlatPage

class ExtendedFlatPageAdmin(FlatPageAdmin):
    form = ExtendedFlatPageForm
    fieldsets = (
        (None, {'fields': ('url', 'title', 'content', 'sites', 'order')}),

admin.site.register(ExtendedFlatPage, ExtendedFlatPageAdmin)

Obviously there are a few things going on here, but most importantly the FlatPage model is being unregistered and the ExtendedFlatPage model is being registered in its place.



And the method in your post doesn’t work because… ?

If for some reason you really need to fiddle with the builtin FlatPage class and edit it dynamically, you can hook to the class_prepared signal:



Here’s how you’d do it with a class_prepared:

from django.db.models.signals import class_prepared
from django.db import models

def alter_flatpages(sender, **kwargs):
    if sender.__module__ == 'django.contrib.flatpages.models' and sender.__name__ == 'FlatPage':
        order = models.IntegerField()
        order.contribute_to_class(sender, 'order')


Put this in, say, ‘signals.py’ in the same directory as your settings.py, and add ‘signals’ to the top (this is important, to make sure the signal handler gets installed in time) of the INSTALLED_APPS list .

However, this still won’t get the field displayed in Admin, because there’s a custom ModelAdmin class for FlatPages which explicitely lists the fields. So after it gets registered in the flatpages app, you’d need to unregister it somewhere (admin.site.unregister) and register a ModelAdmin of your own.



  1. In your settings.py change the location of the migrations folder for the django.contrib.flatpages app to another folder than the default one. For example:


MIGRATION_MODULES = {'flatpages': 'yourproject.flatpages.migrations'}

Keep in mind that you have to create empty __init__.py files within the folders yourproject, flatpages and migrations to make Python treat those dictionaries as packages.

  1. Execute the makemigrations management command to populate the initial migration to your MIGRATION_MODULES folder. It should look similar to the default one.

  2. Within the apps.py of one of your apps (preferably the one using the flatpages feature) add oggy’s class_prepared solution:


from django.apps import AppConfig
from django.db.models.signals import class_prepared
from django.db import models

def alter_flatpages(sender, **kwargs):
    if sender.__module__ == 'django.contrib.flatpages.models' and sender.__name__ == 'FlatPage':
        meta_description = models.CharField(max_length=255, blank=True, null=True)
        meta_description.contribute_to_class(sender, 'meta_description')

class TexteConfig(AppConfig):
    name = 'marlene.texte'

    def __init__(self, app_name, app_module):
        super().__init__(app_name, app_module)
  1. Add another migration by executing makemigrations again. This time you have added the CharField meta_description to the model. migrate to apply the changes to the database.

  2. Modify the FlatPageAdmin:


from django.contrib.flatpages.admin import FlatPageAdmin
from django.contrib.flatpages.models import FlatPage

class MarleneFlatPageAdmin(FlatPageAdmin):
    fieldsets = (
        (None, {'fields': ('url', 'title', 'content', 'meta_description', 'sites')}),
        (_('Advanced options'), {
            'classes': ('collapse',),
            'fields': ('registration_required', 'template_name'),

admin.site.register(FlatPage, MarleneFlatPageAdmin)

The biggest drawback of this solution is that if Django adds new migrations to the flatpage app in the future you are responsible for managing them. I would advise everyone not to use the flatpage app no matter if seems a good fit for your current situation.

Leave a comment