25👍
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.unregister(FlatPage)
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.
7👍
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:
http://docs.djangoproject.com/en/dev/ref/signals/#class-prepared
Edit
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')
class_prepared.connect(alter_flatpages)
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.
0👍
- In your
settings.py
change the location of the migrations folder for thedjango.contrib.flatpages
app to another folder than the default one. For example:
settings.py
:
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.
-
Execute the
makemigrations
management command to populate the initial migration to yourMIGRATION_MODULES
folder. It should look similar to the default one. -
Within the
apps.py
of one of your apps (preferably the one using the flatpages feature) add oggy’sclass_prepared
solution:
apps.py
:
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)
class_prepared.connect(alter_flatpages)
-
Add another migration by executing
makemigrations
again. This time you have added theCharField
meta_description
to the model.migrate
to apply the changes to the database. -
Modify the
FlatPageAdmin
:
admin.py
:
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.unregister(FlatPage)
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.
- 'admin' is not a registered namespace in Django 1.4
- Django widget override template
- Django __call__() missing 1 required keyword-only argument: 'manager'