[WHIT-2990] Change news article lead image payload from image to images with type#11189
Open
lauraghiorghisor-tw wants to merge 2 commits intomainfrom
Open
[WHIT-2990] Change news article lead image payload from image to images with type#11189lauraghiorghisor-tw wants to merge 2 commits intomainfrom
lauraghiorghisor-tw wants to merge 2 commits intomainfrom
Conversation
lauraghiorghisor-tw
changed the title
lauraghiorghisor-tw
changed the title
lauraghiorghisor-tw
force-pushed
the
change-payload-for-lead-images
branch
6 times, most recently
from
d663312 to
d6d2365
Compare
| assert_equal expected_payload, edition.lead_image_payload(lead_usage) | ||
| end | ||
|
|
||
| test "#lead_image_payload does not include a caption, if caption is nil" do |
Contributor
Author
There was a problem hiding this comment.
This is changing now, since we are always sending the caption. As far as I can tell, it makes no difference to FE, and it's now been allowed in publishing API -> alphagov/publishing-api#3924. This is consistent with the "intention" introduced by the "caption_enabled" configuration, i.e. "no caption key" should mean it is disabled, and "nil caption" should mean it is enabled but - intentionally - missing.
Previously we were using this definition instead, which allowed null, but we were always dropping the nulls in whitehall anyway by using compact on the payload, so that did not make much sense.
| { | ||
| high_resolution_url: placeholder_image_url, | ||
| url: placeholder_image_url, | ||
| sources: Whitehall.image_kinds.fetch("default").versions.map { |v| [v.name.to_sym, placeholder_image_url] }.to_h, |
Contributor
Author
There was a problem hiding this comment.
Replicating this same url as was agreed to do, like we do with svgs as well.
| high_resolution_url: default_lead_image.url(:s960), | ||
| url: default_lead_image.url(:s300), | ||
| } | ||
| return default_lead_image.publishing_api_details.merge(type: lead_image_usage.key, caption: nil) |
Contributor
Author
There was a problem hiding this comment.
I don't know (yet) what we want to do with FeatureImageData so I only added sources and content_type to that method, preferring to inject type and caption here. That model does not have type yet, nor caption directly. Caption is provided on some of the models that use FeatureImageData (such as Feature), but not on Organisation, which we care about here.
lauraghiorghisor-tw
force-pushed
the
change-payload-for-lead-images
branch
from
d6d2365 to
820b1cf
Compare
lauraghiorghisor-tw
force-pushed
the
change-payload-for-lead-images
branch
from
820b1cf to
600d89a
Compare
This will be used in a future commit to compute the lead image payload. `FeaturedImageData` is the model used for the organisation default news image, which is used as a lead image fallback. The `publishing_api_details` method sits on the `Image` model for regular images, so it would have made sense to put it on the "parent" model for `FeaturedImageData`, i.e. `Organisation` in this case. Nonetheless, there are many models using this `_Data` class, not just `Organisation`, so it is more convenient to place it straight on the `FeaturedImageData` for the time being. We can reconsider this at a later stage when more `FeatureImageData` usages need to be made consistent with this new payload shape, so I have made no attempts to unify concerns at this point.
… 'type' lead, with 'sources'
To ensure a consistent image payload across types, we are bringing the lead image payload in line with that of the other non-embeddable images, such as topical events' headers and logos, and history pages' sidebar.
The change is from sending a singular `details.image` to sending `details.images` with a `type` to identify the `usage`, and a hash of `sources` corresponding to the various image variants, rather than the `url`, `high_resolution_url`, `medium_resolution_url` we were sending prior. Since the code is scoped to config-driven document types, this change only affects news articles. History pages have been dealt with separately, and republished.
This change is accompanied by changes in publishing API, Frontend, and the metadata component (which looks for a url). All these changes will require a 2-step release: an expand to allow both payloads, then a contract after republishing. All news articles will require republishing for the change to take effect.
Note on the payload specifics:
- We have agreed with Frontend owners that, in order to keep the API consistent, and the FE code relatively simple, we will send the `sources` hash with all the variant keys, even for cases where the image is not truly "versioned". In the case of lead images, that's the placeholder image, which we now send replicated for all the versions ("default" kind's versions: s960, s712, s630, s465, s300, s216). This also ensures the system can expand in the future, if we then provide a versioned placeholder image. This is in line with what we do for svg images elsewhere, which only generate one asset variant.
lauraghiorghisor-tw
force-pushed
the
change-payload-for-lead-images
branch
from
600d89a to
5558a04
Compare
| person.image.republish_on_assets_ready | ||
| end | ||
|
|
||
| test "#publishing_api_payload returns image sources and content type" do |
Contributor
There was a problem hiding this comment.
This is still a thing to do I think?
Suggested change
| test "#publishing_api_payload returns image sources and content type" do | |
| test "#publishing_api_details returns image sources and content type" do |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Change news article lead image payload from single image to images of 'type' lead, with 'sources'
To ensure a consistent image payload across types, we are bringing the lead image payload in line with that of the other non-embeddable images, such as topical events' headers and logos, and history pages' sidebar.
The change is from sending a singular
details.imageto sendingdetails.imageswith atypeto identify theusage, and a hash ofsourcescorresponding to the various image variants, rather than theurl,high_resolution_url,medium_resolution_urlwe were sending prior. Since the code is scoped to config-driven document types, this change only affects news articles. History pages have been dealt with separately, and republished.This change is accompanied by changes in publishing API, Frontend, and the metadata component (which looks for a url). All these changes will require a 2-step release: an expand to allow both payloads, then a contract after republishing. All news articles will require republishing for the change to take effect.
Note on the payload specifics:
sourceshash with all the variant keys, even for cases where the image is not truly "versioned". In the case of lead images, that's the placeholder image, which we now send replicated for all the versions ("default" kind's versions: s960, s712, s630, s465, s300, s216). This also ensures the system can expand in the future, if we then provide a versioned placeholder image. This is in line with what we do for svg images elsewhere, which only generate one asset variant.Note on
FeaturedImageDatachanges:sourcespayload for theFeaturedImageDatasince that's the model underlying the fallback organisation image. Thepublishing_api_detailsmethod sits on theImagemodel for regular images, so it would have made sense to put it on the "parent" model forFeaturedImageDataas well, i.e.Organisationin this case. Nonetheless, there are many models using this_Dataclass, not justOrganisation, so it is more convenient to place it straight on theFeaturedImageDatafor the time being.FeatureImageDatausages need to be made consistent with this new payload shape, so I have made no attempts to unify concerns at this point.Release/republish plan
details.imagespublishing-api#3890Must ensure that all News Articles have been updated while republishing, otherwise we can't merge the contract PR on FE.
Testing
Jira