Conversation
sonnybaker
changed the title
sonnybaker
changed the title
Fixing a typo
Fixing _another_ typo...
|
This would be great. Is this still alive? :) |
|
This would be an amazing solution to a problem we have right now. We are not happy with how pages are identified by Wagtail, so we would like to introduce another PageIdentifier. Right now we can have a ParentalKey to another Model but that handling is just not elegant for something that should essentially be a CharField. I think this would add a lot of value and possibilities to Wagtail Development. And with django-swappable-models there is even some experience here. |
|
Thank you @sonnybaker for taking a crack at this, I can only imagine it being very tough to write an RFC for this. Linking to historical discussion for reference: Feature request: Swappability of main models #11381 @mattlinares @NotANormalNerd, and anyone who wonders where this is at – if you want to see this happen,
We’re not particularly good at this RFC process but if there’s movement I’m sure the core team will make efforts to support this. |
|
Hi @thibaudcolas! Thanks so much for resurrecting this. It's fair to say Wagtail has come on a little bit since I wrote this back in 2020, so there's obviously a lot more to factor in now (new revisions sytem and comments immediately spring to mind). We're keen to get behind this at at Hactar, so would love to work on the PR/epic with the guidance of the core team if there's an appetite for it to move forward. |
|
Please note, we have closed the PR wagtail/wagtail#5457 & raised an issue to reflect that goal instead wagtail/wagtail#11440 It might be worth updating this RFC to reflect that in the links section. |
|
A use-case that could benefit coderedcorp/wagtail-seo#43 (comment) |
thibaudcolas
left a comment
thibaudcolas
left a comment
There was a problem hiding this comment.
We’re proposing moving forward with this in RFC 113: Wagtail 7.4 roadmap updates - tentatively for the August 2026 release.
The RFC has lots of valuable info! For a change that has such an impact on backwards compatibility, we’ll need more upfront planning of the possible incompatibilities.
| use in the `auth` library has shown it to be stable, relying on a private API is still a risk, and another solution may be preferable. | ||
| * Would mean updating core migrations. | ||
| * Page revisions will need to be adapted to work with generic foreign keys. | ||
| * Could present issues when adding (or removing) fields from the abstract Page base (ie. clashing attribute names). |
There was a problem hiding this comment.
I don’t understand why this would be any more of an issue with a swappable base vs. the current model of adding fields to specific page types?
| * This is a major change to Wagtail, and must be tested thoroughly. It would be be best soft-launched | ||
| as an experimental feature, to collect user feedback. |
There was a problem hiding this comment.
I’m not clear how that would work. This would require pretty extensive rework of existing code, including in packages, likely only suitable for new projects? If this is only suitable for new projects, I assume we could get plenty of testing done without shipping this even experimentally?
| * Swappable models is an _intentionally undocumented_ (or "stealth alpha") feature - | ||
| [User models were the pilot program for this](https://code.djangoproject.com/ticket/19103). Though its | ||
| use in the `auth` library has shown it to be stable, relying on a private API is still a risk, and another solution may be preferable. |
There was a problem hiding this comment.
This seems irrelevant to me; Wagtail users are very happy with swappable image/document models.
| manner as Django does with [custom user models](https://docs.djangoproject.com/en/3.0/topics/auth/customizing/#changing-to-a-custom-user-model-mid-project). | ||
|
|
||
| ## Open Questions | ||
| * How do we implement this in a way that is frictionless for new starters? |
There was a problem hiding this comment.
A key factor will be whether we want this to be implemented in project starter templates or no.
|
|
||
| ## Open Questions | ||
| * How do we implement this in a way that is frictionless for new starters? | ||
| * What are the implications for third-party packages? |
There was a problem hiding this comment.
I imagine every single one that interfaces with pages will need to change its code (and migrations?) to be compatible?
8 participants
Rendered