Skip to content

Conversation

@ChrisBAshton
Copy link
Contributor

Following on from PR 10912 which raises an exception if a computed base path already exists in Publishing API for a live content item that has a different content ID...

...currently, we raise an exception in that case, and the user would just see a "Server Error" message. Ideally we'd want to catch that exception and show an error message to the user instead, nudging them to edit their title.

Steps to test locally:

  1. Set up a legacy published NewsArticle, with a slug (e.g. 'foo')
  2. Try creating a new StandardEdition news article with a title that would end up generating the same slug (i.e. "Foo").

Currently, on step 2, locally I see the exception introduced in 10912.

In this WIP commit I was expecting to catch the exception and surface the error to the user, and to still be on the "new document" screen (with my inputted values retained from the form submission). But instead, the draft gets created and the slug gets enumerated (in this example, "foo--2" or something like that). I'm not sure why the code I've added in this commit causes the draft to save successfully 🤔


⚠️ This repo is Continuously Deployed: make sure you follow the guidance ⚠️

This application is owned by the Whitehall Experience team. Please let us know in #govuk-whitehall-experience-tech when you raise any PRs.

Follow these steps if you are doing a Rails upgrade.

@patrickpatrickpatrick patrickpatrickpatrick force-pushed the avoid-accidentally-overwriting-base-path branch from 3611a8f to 9de162c Compare December 8, 2025 11:44
Base automatically changed from avoid-accidentally-overwriting-base-path to main December 9, 2025 09:59
@patrickpatrickpatrick patrickpatrickpatrick force-pushed the catch-base-path-exception-and-show-user branch from fe1feb7 to f02d8a6 Compare December 9, 2025 13:52
Following on from PR 10912 which raises an exception if a computed
base path already exists in Publishing API for a live content item
that has a different content ID...

...currently, we raise an exception in that case, and the user
would just see a "Server Error" message. Ideally we'd want to
catch that exception and show an error message to the user instead,
nudging them to edit their title.

Steps to test locally:

1. Set up a legacy published NewsArticle, with a slug (e.g. 'foo')
2. Try creating a new StandardEdition news article with a title
   that would end up generating the same slug (i.e. "Foo").

Currently, on step 2, locally I see the exception introduced in
10912.

In this WIP commit I was expecting to catch the exception and
surface the error to the user, and to still be on the "new
document" screen (with my inputted values retained from the form
submission). But instead, the draft gets created and the slug
gets enumerated (in this example, "foo--2" or something like that).
I'm not sure why the code I've added in this commit causes the
draft to save successfully 🤔
@patrickpatrickpatrick patrickpatrickpatrick force-pushed the catch-base-path-exception-and-show-user branch from f02d8a6 to 4383c4b Compare December 9, 2025 13:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants