Replies: 4 comments 2 replies
-
Related comment: #7227 (comment) |
Beta Was this translation helpful? Give feedback.
-
I really like the solution! The proposed routing changes are especially tidy. Just wondering what the implications are for enforcing URL uniqueness? Do we just keep ensuring |
Beta Was this translation helpful? Give feedback.
-
Nice! The extension to the treebeard 'move' method might need to call |
Beta Was this translation helpful? Give feedback.
-
Any clue if any progress was made on this in the meantime? |
Beta Was this translation helpful? Give feedback.
-
In this discussion, I'd like to propose a new method for customising a page's URL path. This would provide a simpler method to override the URL path up to and including the page's slug (which isn't possible with
RoutablePageMixin
).For example, it's common to have to prefix a blog post's slug with the date it was posted on:
https://mysite.com/blog/2021/02/01/my-blog-post
Currently, the only supported way is to override the pages
get_url_parts
androute
methods. This method is (partially) described in the docs here.There are a few problems with this method, however:
The main goal of implementing the new method would be to make it no longer necessary to fetch specific pages to get a URL. This would improve performance in the admin listings and API, it would also reduce the chance of mistakes caused by forgetting to do this in a plugin or custom code.
Proposal
I'd like to propose replacing this with a new method by adding a
url_path_component
field toPage
. This will replace theslug
for the purpose of routing to pages. It would be set programmatically rather than editable in the admin and would default to the value of theslug
field.For example, this is all that would be needed to implement the date in URL customisation for blog posts:
No need to override
route()
, no need to worry about sub-pages, and the value is saved on thePage
model so the correct URL can be generated without.specific
.Implementation notes
Routing
The route method would be updated to search for sub-pages using the
url_path_component
field instead ofslug
. The difference is we now need to account for the fact thaturl_path_component
can contain'/'
characters.This could be done with negligible performance impact* by updating our existing query to search for all the potential options and pick the most specific one.
For example, here's the current routing implementation:
wagtail/wagtail/core/models/__init__.py
Lines 816 to 825 in 247030d
To account for components that contain a
/
, we could change this to:* If we can remove the need for anyone to override
route()
we could massively improve performance by removing this.specific
callBeta Was this translation helpful? Give feedback.
All reactions