Avoid a website listing parsing an invalid thumbnail image from an empty meta image of its item which does not even consider it as a preview image

[yhkee0404]

Description

I added some tests which explain this description.

Rendering a website document where metadata key image has a value of an empty string "" has no problem. It works as well as if there were no such key set, and a preview image, if exists, is successfully chosen as a thumbnail image on a website listing:

quarto-cli/tests/docs/smoke-all/2025/03/07/issue-12222/posts/preview-image-and-empty-meta-image/index.qmd

Lines 13 to 18 in 81a5d78

	image: ""
	---
	Testing images.
	

However, rendering another document that sets the aforementioned document as one of its listing contents fails to find a thumbnail image, and it refers to itself since the empty string is parsed as the relative path to itself:

quarto-cli/tests/docs/smoke-all/2025/03/07/issue-12222/index.qmd

Lines 1 to 4 in 81a5d78

	---
	title: "Listing Example"
	listing:
	contents: posts

This causes an infinite loop of rendering a website listing on quarto preview.

The inconsistent rendering behavior between those two website documents results from the following two blocks of lines:

quarto-cli/src/project/types/website/website-meta.ts

Lines 298 to 314 in 42a13e1

	function pageMetadata(
	format: Format,
	extras: FormatExtras,
	): Record<string, unknown> {
	const pageTitle = computePageTitle(format, extras) as string;
	const pageDescription = format.metadata[kDescription] as string;
	const pageImage = format.metadata[kImage]
	? format.metadata[kImage] as string
	: undefined;
	return {
	[kTitle]: pageTitle,
	[kDescription]: pageDescription || format.metadata[kAbstract] ||
	format.metadata[kSubtitle],
	[kImage]: pageImage,
	};
	}

quarto-cli/src/project/types/website/listing/website-listing-read.ts

Lines 1125 to 1130 in 7408297

	const imageRaw = documentMeta?.image as string | boolean;
	const image = imageRaw !== undefined && typeof imageRaw === "string"
	? pathWithForwardSlashes(
	listingItemHref(imageRaw, dirname(projectRelativePath)),
	)
	: undefined;

pageImage ignores both an empty string or undefined, which leads to successful detection of a preview image. On the contrary, image discards only undefined or anything other than string, and parses an empty string into the relative path to the listing item because it is a string.

This pull request fixes the special parser that website listings use to parse the thumbnail images from their items' preview images, in order to make it correspond to the individual renderer that the very items use to parse their preview images and ignores an empty meta image, since their final rendering is supposed to have a higher priority over their listings on other documents.

Checklist

I have (if applicable):

• filed a contributor agreement.
• ensured the present test suite passes
• added new tests

[cscheid]

Hi there - thank you for the PR and the tests!

I want to merge this for 1.7. But I'm wondering about the tests confirm that the preview issue is fixed. The added tests check that the rendering happens as expected, but they don't check that the preview issue is fixed.

@cderv, any ideas? I think this is a pretty hard one to do, because it would involve starting a preview server, editing a file, and then testing if the preview server doesn't go in an infinite loop.

At the same time, I would love for us to have a more robust infrastructure to test preview issues.