RFC 75: Live-only specific models #75
Conversation
gasman
force-pushed
the
live-only-specific-models
branch
from
b0382dc
to
2667b53
Compare
|
|
||
| ## Model-level operations | ||
|
|
||
| In the proposed new model, non-live pages (including ones submitted for moderation, or awaiting go-live) will be represented as `wagtailcore_page` records with `live` set to False and `content_type` set to `BlogPage`, but with no corresponding `blog_blogpage` record. `wagtailcore_pagerevision` will track changes to the page content as it does now. |
There was a problem hiding this comment.
but with no corresponding
blog_blogpagerecord.
For sites upgrading, would we remove the specific page records for draft pages?
There was a problem hiding this comment.
I think so, yes - it would be good to have a single consistently-used representation and not have to deal with a special case for 'legacy' data. (Could be a bit tricky to do that in a wagtailcore migration, though, and the reverse migration is another matter altogether...)
| blog_page.body += '...updated' | ||
| blog_page.save_revision() | ||
|
|
||
| (It would really be a good idea for Wagtail to provide a helper function for automated edits combining the above two cases, so that the necessary change happens on draft and / or live revisions as appropriate. But that's out of scope for this development) |
There was a problem hiding this comment.
Something like this would be really helpful to have accessible from data migrations. These usually need to update both the live and latest draft versions at the same time.
| Taking a page from draft state to published will require adding a `blog_blogpage` record to the existing `wagtailcore_page` record. Formally supporting this is [currently an open issue in Django](https://code.djangoproject.com/ticket/7623), but this can be achieved as follows: | ||
|
|
||
| page = Page.objects.get(id=123) | ||
| blogpage = BlogPage(body="some specific content") | ||
| blogpage.page_ptr = page | ||
| blogpage.path = page.path | ||
| blogpage.depth = page.depth | ||
| blogpage._state.adding = False | ||
| blogpage.save() | ||
|
|
||
| The `blogpage._state.adding = False` line is needed to ensure that the uniqueness check on the `path` field excludes the existing page record. | ||
|
|
||
| Unpublishing a page would require dropping the `blog_blogpage` record while preserving the `wagtailcore_page` record. This may require a direct SQL query (to be confirmed). |
There was a problem hiding this comment.
One potential complexity here would be page class inheritance with multiple levels, e.g. Page -> BlogPage -> SpecificKindOfBlogPage -> EvenMoreSpecificBlogPage. Dropping the child data may be able to take advantage of Model.delete(keep_parents=True).
If this ability to safely upcast/downcast pages between model types gets added, it also opens the door to broader possibilities around changing an existing page's type, which would be amazing (see wagtail/wagtail#4949 and wagtail/wagtail#7378).
There was a problem hiding this comment.
The keep_parents=True option looks like exactly what we need here - good catch!
Rendered
This RFC proposes a change to the database representation of unpublished pages, where the database record for the specific page model is omitted. This is a pre-requisite for auto-saving (if we don't want the limitation of only being able to auto-save page revisions that completely pass validation).