Add external page link to "Read next" sidebar on ResourcePage

[johnnyporkchops]

Summary (required)

• Add a RichTextBlock to the related_pages ("Read next") section on ResourcePage templates, allowing editors to add an external link in addition to the existing internal PageChooserBlock.

• Adjust temp[late logic to accommodate

• We chose a RichTextBlock to give editors the versatility to add an external link as well as pretty much any other content they might need to add here.

• The seemingly extraneous looping in the template is necessary because the PageChooserBlock is inside a ListBlock, requiring looping to separate them into <li>s on the front end.. Attempts to simplify template logic by switching from a ListBlock to a singular block in the model would group existing database entries for PageChooser ListBlocks into one <li> on the front end.

• Resolves Wagtail wish list: In resource page template, allow the "related page" to be an external link #3794

Impacted areas of the application

modified: home/models.py
modified: home/templates/home/resource_page.html

Screenshots

Wagtail admin:

---

Rendered page:

How to test

Content team: This is published on feature space at: https://fec-feature-cms.app.cloud.gov/

Developers:

• checkout and run feature/3794-external-related-page-ResourcePage
• Go to an existing ResourcePage with Read next sidebar , add Related pages, and External Pages to the "Related Page" and preview/publish to confirm that both show.
  • Example page: http://127.0.0.1:8000/admin/pages/9858/edit/
• Create a new ResourcePage and confirm Related Pages section allows to add both internal and external links in an interspersed order.

Note on migrations: This is an example of a models.py streamfield change that does not require a migration to run properly, but would make a new migration file upon running makemigrations., referncing the added block name for the streamfield (but nothing actually changes in the databae) . Rather than push up a migration file for this, It can wait and will get picked up/added next time someone does a crucial makemigrations/migrate for a more substantial models.py change (i.e: upcoming CommissoinerItem model addition. Reference: wagtail/wagtail#3710

---

[dorothyyeager]

This is exactly what we needed @johnnyporkchops. Much appreciated! Thanks!

If you want to see the test page I created, it's at https://fec-feature-cms.app.cloud.gov/help-candidates-and-committees/keeping-records/best-efforts-test-page/. Worked great.

[kathycarothers]

This looks great. Thank you @johnnyporkchops

[lbeaufort]

@johnnyporkchops I'm going to go ahead and merge this since we have content team approvals and we have a 13.4 ticket for the content team to test the wagtail upgrade next week.

Can you keep an eye on this please? ⬇️

Note on migrations: This is an example of a models.py streamfield change that does not require a migration to run properly, but would make a new migration file upon running makemigrations., referncing the added block name for the streamfield (but nothing actually changes in the databae) . Rather than push up a migration file for this, It can wait and will get picked up/added next time someone does a crucial makemigrations/migrate for a more substantial models.py change (i.e: upcoming CommissoinerItem model addition. Reference: wagtail/wagtail#3710

[lbeaufort]

I rebased this off the latest develop changes locally to make sure the wagtail upgrade didn't break anything, and the tests pass. Thanks for your work on this @johnnyporkchops!