Investigate if we can automate pending rulemaking wagtail page

[rfultz]

Summary

What we're after:
We want to utilize Wagtail CMS’s scheduled publishing and unpublishing capabilities for the Pending Rulemakings page. This functionality will ensure timely updates by automating page visibility based on predefined dates and times, similar to the scheduling process for homepage banners.

Example of pending rulemaking page

Corresponding homepage banner for pending rulemaking comments

Related issues

• Update pending rulemaking matters for comment page REG 2024-08 #6554

Action items

• A documented plan for enabling scheduled publishing and unpublishing for the Pending Rulemakings page.
  • Investigate Wagtail CMS documentation and settings for scheduling publishing/unpublishing, in the page's status menu
  • Identify any dependencies or limitations specific to the Pending Rulemakings page.
• Clear steps for implementation, including any required configuration in Wagtail CMS.
• Confirmation that the scheduling works as expected, including:
  • Proper display of the page after scheduled publication.
  • Automatic removal of the page after the scheduled unpublishing.
• Testing results to confirm no disruptions to existing content workflows or the CMS.

Completion criteria

• Scheduled publishing and unpublishing of the pending rulemaking page is implemented
• A documented plan is written in conjunction with the content team

[johnnyporkchops]

As of version 5.1, "scheduled publishing" is handled in the pages Status panel.
https://docs.wagtail.org/en/v5.1.3/reference/pages/theory.html#scheduled-publishing

Research this command: ./manage.py publish-scheduled
https://docs.wagtail.org/en/v5.1.3/reference/management_commands.html#publish-scheduled

In order for scheduled publishing to work, one has to run ./manage.py publish-scheduled twice:

• Once after the go-live date/time passes ,to publish it.
• And then once again after the expiry date/time passes to un-publish it.

However, we can access the Wagtail Scheduled Publishing fields in template code (self.go_live_at and self.expire_at ). But I am not sure how we could use that to control publishing of the page with code.

Poposed solution (Working prototype was demoed in last Sprint Demo)

1. Add an optional "rulemaking_content" field to banner model/edit-template
2. Create a new inclusion tag in the home_page.py templatetag to capture any rulemaking_content in banners
3. Rulemakiing content scheduling will then be controlled by date_active/date_inactive of the banner in which it was placed.
   • This works with both single rulemaking banners and banners for multiple rulemakings
4. Render the inclusion tag only in the specific rulemaking instance of CustomPage:

        {% if  "pending-rulemaking-matters-comment" in request.path  %}
           {% rulemaking_page_content %}
        {% endif %}

6. The rulemaking instance of CustomPage template can still be manually edited to add content when needed

---

Future Work: Once we are on Wagtail <6.1, we can also implement a Banner PageListingViewset in the admin sidebar that will allow us to show the date_active/date_inactive on the listing page so one does not have to open each banner to see the dates--making it much easier for editors to schedule and manage banners. In this example I added an add'l property to show active banners dates in green. Issue: #6629

[patphongs]

Thanks @johnnyporkchops for your work on this. I have a question about what happens if there's multiple rulemakings that are listed with different opening and closing comment period dates? Would we have to edit the page and modify the listing separately?

[johnnyporkchops]

Thanks @johnnyporkchops for your work on this. I have a question about what happens if there's multiple rulemakings that are listed with different opening and closing comment period dates? Would we have to edit the page and modify the listing separately?

@patphongs No, the rulemaking CustomPage would not have to be manually edited. I demoed this scenario to the Content team and it is probably better to demo it again so you can see, rather than attempt to explain it in writing.

[cnlucas]

Research has been logged in this ticket, ticket for implementation here