Bug Description
src/schema/article.ts builds the author from settings only:
ts
author: {
"@id": ids.person,
name: settings.personName || siteName,
},
EmDash entries carry entry.data.bylines (an array of credits, each with a byline (displayName, avatar) and optional roleLabel) already hydrated on the entry, and already rendered by the official blog template in the article meta column. The schema never reads them, so every article emits the same author regardless of who is credited.
This compounds with the settings UI: when siteRepresents is "organization", the person* fields are hidden, so personName is unreachable and the author falls back to siteName. The graph then declares publisher → Organization "Acme" and author → a Person named "Acme" — a company as the author of every post.
The mismatch is the real problem. On a post credited to two bylines a reader sees:
John Doe Amazon — Editorial
while the JSON-LD on the same response says:
json
"author": { "@id": ".../#/schema.org/Person", "name": "Amazon" }
Google's structured data policies require markup to represent visible content; mismatches risk the markup being ignored or treated as misleading. This is arguably worse than emitting no author at all.
Two changes would fix it: show the person* fields regardless of siteRepresents (relabelled as the default author rather than the site entity, with the site entity still governed by siteRepresents), and prefer entry.data.bylines for the author node when present, falling back to the settings-derived Person.
Steps to Reproduce
- Admin → SEO settings → set Site represents = Organization, Organization name = "Acme".
- Note that the Person section disappears from the settings page.
- Create a post, assign one or more bylines, publish.
- curl -s / | grep -o '"author":{[^}]*}'
- Compare against the byline names rendered on the same page.
Expected Behavior
publisher is the Organization; author is a Person (or array of them) built from the entry's bylines, matching what the page displays.
Actual Behavior
author is a Person named after the organization, on every post, regardless of bylines which contradicts the visible byline on the same response.
Severity
High (feature completely broken)
EmDash Version
0.31.1
Plugin Version
0.12.0
Bug Description
src/schema/article.ts builds the author from settings only:
ts
author: {
"@id": ids.person,
name: settings.personName || siteName,
},
EmDash entries carry entry.data.bylines (an array of credits, each with a byline (displayName, avatar) and optional roleLabel) already hydrated on the entry, and already rendered by the official blog template in the article meta column. The schema never reads them, so every article emits the same author regardless of who is credited.
This compounds with the settings UI: when siteRepresents is "organization", the person* fields are hidden, so personName is unreachable and the author falls back to siteName. The graph then declares publisher → Organization "Acme" and author → a Person named "Acme" — a company as the author of every post.
The mismatch is the real problem. On a post credited to two bylines a reader sees:
John Doe Amazon — Editorial
while the JSON-LD on the same response says:
json
"author": { "@id": ".../#/schema.org/Person", "name": "Amazon" }
Google's structured data policies require markup to represent visible content; mismatches risk the markup being ignored or treated as misleading. This is arguably worse than emitting no author at all.
Two changes would fix it: show the person* fields regardless of siteRepresents (relabelled as the default author rather than the site entity, with the site entity still governed by siteRepresents), and prefer entry.data.bylines for the author node when present, falling back to the settings-derived Person.
Steps to Reproduce
Expected Behavior
publisher is the Organization; author is a Person (or array of them) built from the entry's bylines, matching what the page displays.
Actual Behavior
author is a Person named after the organization, on every post, regardless of bylines which contradicts the visible byline on the same response.
Severity
High (feature completely broken)
EmDash Version
0.31.1
Plugin Version
0.12.0