Scheduled publishing fields
See original GitHub issueThe scheduled publishing fields are a bit unintuitive and their names are a bit inconsistent with the terminology we use elsewhere in wagtail.
More specifically: (try and answer these questions without looking at the code)
- We have two
go_live_at
fields. One onPage
and one onPageRevision
. What is the difference between these? go_live
means publish andexpire
means unpublish. Why did we make up these new words?- We don’t publish pages, we publish revisions. So what does
Page.go_live_at
actually do? Which revision will it publish?
Heres what I propose:
- Remove
Page.go_live_at
- Rename
Page.expire_at
toPage.unpublish_at
- Rename
PageRevision.approved_go_live_at
toPageRevision.publish_after
(named “after” instead of “at” as publishing entirely depends on whether it’s in moderation or not)
Issue Analytics
- State:
- Created 9 years ago
- Comments:8 (6 by maintainers)
Top Results From Across the Web
Scheduled Publishing - Hygraph
Hygraph gives you the ability to schedule content publishing, and unpublishing as one off, or as a collection (referred to as a "release")....
Read more >Scheduled publishing | Contentful Help Center
Schedule an entry to be published or unpublish at a certain time and date. Create multiple scheduled actions on an entry at different...
Read more >Automate Publishing with Wordpress Scheduled Posts
Automating content publishing on WordPress can save you significant time. Learn about WordPress scheduled posts and eliminate manual tasks.
Read more >Scheduling pages for publishing | Kentico 11 Documentation
If time zones are enabled, the day and time values in the Publish from/Publish to fields are displayed in a format relative to...
Read more >How to schedule post publishing in WordPress - A2 Hosting
Scheduling the publishing date and time for a post ... To schedule when WordPress publishes a new post, follow these steps: ... Click...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hi guys. While on this subject… I’ve ran into a few situations where I’ve needed to pull out a list of ‘latest’ things onto a homepage. Those things could have been recently published for the first time, or recently updated.
In other plain Django and other Django-based CMSs I’ve used, this would always be solved by having a last_updated DateTimeField with auto_now=True, but in Wagtail, the revisions process complicates things a little. It seems that the
first_published_at
field is readily available on the Page, but alast updated at
field isn’t. There’slast_revision_created_at
, but that’s not quite the same thing, because for the front end, that date isn’t relevant… it’s the date the latest revision was ‘published’ that is relevant.I know that, technically, I can work that date out by accessing the Pages revisions, but then, the
Revision.approved_go_live_at
date is what I really need, but that’s always NULL unless the publishing was delayed, so I’ve got to get that OR theRevision.created_at
(I think), OR resort toPage.latest_revision_created_at
?So, essentially, what would normally just be
Page.objects.all().order_by('-last_updated')
is a very complicated set of queries and sub-queries.What would be really nice is a
last_revision_published_at
DateTime field on thePage
model, that would represent when the page was last ‘publicly’ updated. Is is possible for that to be reliably populated?Here’s a reference from the source code, I couldn’t find real docs: https://github.com/wagtail/wagtail/blob/master/wagtail/core/models.py#L251