Manage assets

Home
Assets

Last updated: 18 Dec 2024

Get an asset’s ID

If the asset URL starts with /media, the asset ID is in the URL. For example, for the URL https://assets.publishing.service.gov.uk/media/65f2c1110e1c2f8c4dffaa53/my_file.jpg, the ID is 65f2c1110e1c2f8c4dffaa53.

For assets that do not start /media, obtain the ID by running the following rake task:

k exec deploy/asset-manager -- rake assets:get_id_by_legacy_url_path[SLUG]

For example, for https://assets.publishing.service.gov.uk/government/uploads/uploaded/hmrc/realtimepayetools-update-v23.xml", you would pass /government/uploads/uploaded/hmrc/realtimepayetools-update-v23.xml as the argument.

Remove an asset

When looking to remove an asset, keep in mind that some cases can be fixed less destructively, by setting a redirect or replacement. It depends on the case and user need. For Whitehall assets, see the known bugs section below. For more information on the asset state machine, see this documentation.

Remove an asset via the originating publishing app

Where possible, you should guide the user to remove the asset in the publishing application that originally uploaded the file, via the UI. Deleting an asset from Asset Manager without removing the record from the publishing application can surface broken links to the user. If the content is published, remove the attachment in a new draft of the edition, make your changes, and republish.

For superseded content, we recommend preserving the attachment’s relationship with the parent document, on the publishing app. You should only delete the asset in Asset Manager, using the assets:delete rake task described below.

Remove an asset directly in Asset Manager

If it isn’t feasible to remove the asset in the publishing app, you can use these steps to remove the asset from assets.publishing.service.gov.uk in Asset Manager.

Get the asset ID.
Decide if the asset can be marked as deleted or whether all traces need to be removed (e.g. if it contains secret information).

To soft delete the asset (i.e. mark the asset as deleted in Asset Manager’s database, but retain the file in cloud storage), run:
```
k exec deploy/asset-manager -- rake assets:delete[ASSET_ID]
```
To delete all traces of the asset (including the file from cloud storage), run:
```
k exec deploy/asset-manager -- rake assets:delete[ASSET_ID,true]
```
For “Whitehall” Assets (paths starting with /government/uploads/system), use the assets:whitehall_delete rake task instead:
```
k exec deploy/asset-manager -- rake assets:whitehall_delete[ASSET_PATH]
```
Add a query string to the URL (e.g. ?cache-bust=12345) to bypass the cache and check that the asset responds with a 404 not found.
Wait 5 minutes for the cache to clear, or purge it yourself.
Verify that the URL returns a 404 response without using a query string.
Request removal of the asset from Google’s search results:
- Go to the Google Search Console
- Click ‘New request’
- Select ‘To refresh Google’s outdated result for a webpage that has changed’
- Click ‘Next’
- Enter the page URL and click ‘Submit’
Remove the asset from the Google Cloud Platform (GCP) mirror:
- Log into the GCP console.
- Go to the GOVUK Production project under the DIGITAL.CABINET-OFFICE.GOV.UK organisation.
- Select Cloud Storage -> Browser, go to the govuk-production-mirror bucket.
- Navigate to the file, then delete it.

Remove the asset from the Amazon Web Services (AWS) mirror:

gds aws govuk-production-poweruser aws s3 rm s3://govuk-production-mirror/assets.publishing.service.gov.uk/<slug>

Redirect an asset

Sometimes it might be necessary to manually redirect an asset, for example if an associated document wasn’t unpublished correctly.

Ideally, the redirect should be done in the publishing application that originally uploaded the file (e.g. Whitehall).

If it isn’t possible or desirable to redirect the asset in the publishing app, use these steps to remove the asset in Asset Manager:

Get the asset ID.

Run the following rake task:

k exec deploy/asset-manager -- rake assets:redirect[ASSET_ID,REDIRECT_URL]

For Whitehall assets you will have to run:

k exec deploy/whitehall_redirect -- rake assets:redirect[LEGACY_PATH_URL,REDIRECT_URL]

Upload an asset

Some publishing apps such as Mainstream Publisher do not provide the facility for editors to upload assets such as images and PDFs. In these rare cases, we can upload assets to asset-manager manually and give the URL to content editors to embed.

Production assets are replicated to staging and integration nightly, so it is best to simply perform the upload directly in production.

If the pod terminates at any point during this process (e.g. a deployment occurs), you will need to start again as the /tmp directory is specific to the pod.

Get the name of an asset-manager app pod.

POD=$(kubectl get pods -l app=asset-manager -o name | head -1)
echo $POD

Upload the file to the pod’s /tmp directory:
```
k cp my_file.jpg apps/$POD:/tmp
```
Run the create_asset command on the same pod:
```
k exec -it $POD -- bin/create_asset /tmp/my_file.jpg
```
The output will look like the following:
```
Saved!
Asset id: 65f2c1110e1c2f8c4dffaa53
Asset name: my_file.jpg
Asset basepath: /media/65f2c1110e1c2f8c4dffaa53/my_file.jpg
```
The asset should now be available at https://assets.publishing.service.gov.uk/{base-path-from-previous-output}, for example https://assets.publishing.service.gov.uk/media/65f2c1110e1c2f8c4dffaa53/my_file.jpg.

Replace an asset

If you need to replace the file of an existing attachment, follow these steps.

The replacement file must have a different filename to the one it is replacing.

Where possible, you should do the replacement in the publishing application that originally uploaded the file, for example Whitehall.

When a manual replacement in the UI is not possible, for example in the case of a bug related to superseded data, you can rerun the whitehall replacement update manually. See section below on known bugs.

If it isn’t possible or desirable to replace the asset in the publishing app, use these steps to remove the asset in Asset Manager:

Get the name of an asset-manager app pod.

POD=$(kubectl get pods -l app=asset-manager -o name | head -1)
echo $POD

Upload the file to the pod’s /tmp directory:
```
k cp my_file.jpg apps/$POD:/tmp
```
Open an app console on that same pod:
```
k exec -it $POD -- rails c
```
Find the asset by its ID (see “Get an asset’s ID”):
```
asset = Asset.find(asset_id)
```
Check the asset is what you think it is.

Replace the file:

asset.file = Pathname.new("/tmp/filename.ext").open
asset.send(:store_metadata)
asset.save!

If the attachment is a PDF that was originally uploaded in Whitehall, update the page count field in Whitehall:

k exec -it deploy/whitehall-admin -- rails c

attachment_data = Asset.find_by(asset_manager_id: asset_id).assetable # e.g. 57a9c52b40f0b608a700000a
attachment_data.update(file_size: 123, number_of_pages: 28) # file_size in bytes

Whitehall known asset bugs

There are a few known bugs in Whitehall, that cause assets to be live when they should not be. These are currently (end of 2024) being worked on, and a data clean up has been run. In case you see anything that matches the patterns below, here’s how you can fix it. You can still just delete the asset, but this approach is less destructive and more aligned with the intended behaviour.

On a new draft of a published edition, if the user replaces a previously published attachment, then deletes it, and publishes the draft. The original asset remains live. However, the attachment is deleted, so the user does not know anything has gone wrong.

The problem seems to be that the deleted replacement’s draft state is not set to false.

NB: The issue is specific to assets with draft replacements. Do not change the replacement unless it is in draft! The original asset must only serve superseded editions. To check that the original asset is not used on a public edition run, from a Whitehall console:
```
   # This should be an array of "superseded" and nil ("deleted" state) attachables.
   Asset.find_by(asset_manager_id: <your_asset_manager_id>).assetable.attachments.map(&:attachable).pluck(:state)
```
Fix the replacement asset by running the following code from an Asset Manager console:
```
   replacement = Asset.find(<your_asset_manager_id>).replacement
   replacement.destroy! # if not already deleted
   replacement.draft = false
   replacement.save!
```
On a draft of a published edition, the user replaces a previously published attachment at least two successive times, without saving the draft first (or in between). The original asset remains live.

To fix this, you can populate the replacement_id manually, mimicking the behaviour that happens on publish. After a publish event, all the assets in a chain of replacements will point to the last one. This fix is preferable to a deletion, especially if a redirected is needed anyway. You can extract the required replacement_id by following the chain of AttachmentData replaced_by_ids until the last. In a Whitehall console, run:
```
   original_attachment_data = Asset.where(asset_mnager_id: <your_asset_manager_id>).first&.assetable
   next_attachment_data1 = AttachmentData.find(original_attachment_data.replaced_by_id)
   next_attachment_data2 = AttachmentData.find(next_attachment_data1.replaced_by_id)
   AssetManager::AssetUpdater.call(<your_asset_manager_id>, { "replacement_id" => next_attachment_data2.assets.first.asset_manager_id })
```