Overview - Ghost

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
30108
277ccd36 Fixed bulk tag add ignoring a supplied slug when matching existing tags ref https://linear.app/ghost/issue/ONC-1945/incorrect-count-on-tags The lookup for an existing tag derived the slug from the name alone, while Tag.add honours a slug supplied alongside it. A tag carrying both therefore looked itself up under one slug and was created under another, so supplying the slug of a tag that already existed produced a near duplicate with a "-2" suffix rather than reusing it. Deriving the slug from the supplied slug first, falling back to the name, matches the precedence in Tag.onSaving and keeps the two halves in agreement.
by Michael Ba...
Succeeded
30108
651eaae5 Fixed bulk tag add creating a second tag with an existing name ref https://linear.app/ghost/issue/ONC-1945/incorrect-count-on-tags A tag supplied by name was always created, so adding one whose name already belonged to a tag produced a near duplicate carrying a "-2" slug, because only tags.slug is unique and not tags.name. Repeating the action kept adding more. Saving a post reuses the existing tag in this situation, so bulk add behaved differently to the rest of the editor. It now looks the tag up first. The lookup is on the slug the name generates rather than the name itself. Slugs are unique and already lowercased, so a name differing only by case resolves to the same tag on both MySQL and SQLite, whose collations disagree on whether a string comparison is case sensitive.
by Michael Ba...
Succeeded
30108
58944a61 Added coverage for non-object entries in the bulk tag list ref https://linear.app/ghost/issue/ONC-1945/incorrect-count-on-tags The invalid tag cases covered null but no truthy non-object, so the branch rejecting values such as a bare string, number or boolean was never exercised. No behaviour changes, these already returned a 400.
by Michael Ba...
Succeeded
30108
7ff33a6e Fixed bulk tag add returning a 500 for malformed tag input ref https://linear.app/ghost/issue/ONC-1945/incorrect-count-on-tags The addTag validation checked the shape of each tag but not the types of the fields it then read. A null entry passed the object check, because typeof null is object, and threw on the following property access. A non-string id or name passed through and threw further down. Both surfaced as a 500 for what is a malformed request. Values are now rejected whenever they are supplied and not a string. Treating only null and undefined as absent matters here, because a falsy value such as 0 or false is a supplied value that would otherwise skip the check and reach the model.
by Michael Ba...
Succeeded
30108
8530d686 Fixed bulk tag add returning a 500 for malformed tag input ref https://linear.app/ghost/issue/ONC-1945/incorrect-count-on-tags The addTag validation checked the shape of each tag but not the types of the fields it then read. A null entry passed the object check, because typeof null is object, and threw on the following property access. A non-string id or name passed as truthy and threw further down. Both surfaced as a 500 for what is a malformed request. Completing the checks in the loop that already rejects the other invalid forms means these return a 400 like the rest. No valid request changes behaviour.
by Michael Ba...
Succeeded
30108
dd759a93 Fixed bulk tag add creating two tags from one repeated name ref https://linear.app/ghost/issue/ONC-1945/incorrect-count-on-tags bulkEdit accepts tags by name as well as by id, and every name-only entry was created before the ids were deduplicated. Passing the same new name twice therefore created two tags - the second picking up a "-2" slug, since only tags.slug is unique, not tags.name - and applied both to every selected post. Deduplicating up front by id, or by lowercased name where there is no id, means a repeated name is created once. The lowercase comparison matches how the post model already deduplicates tags on save.
by Michael Ba...
Succeeded
30108
52a8c635 🐛 Fixed inflated post counts on tags ref https://linear.app/ghost/issue/ONC-1945 The bulk "Add tag" action inserted a `posts_tags` row for every selected post without checking whether the post already had the tag. `posts_tags` has no unique constraint, so re-applying a tag to a selection that already carried it silently created a redundant row per post Those rows are invisible everywhere in the product, because the read path deduplicates by tag `id` before anything renders them. The one place they leak through is the tag post count, which counted join rows rather than distinct posts and so reported roughly double This PR fixes both halves. The bulk action now filters out post/tag pairs that already exist, matching the guard already in place in the users service, and also deduplicates the requested tags so passing the same tag twice in one request no longer inserts twice. The count now uses `countDistinct` so it reports posts rather than links Counting distinct matters independently of the write-side fix: it makes existing affected sites report correctly on upgrade, without a data migration. Removing the redundant rows would change which tag is primary on some posts, and therefore post URLs on sites using a `{primary_tag}` permalink, so leaving them in place is the lower-risk option
by Michael Ba...