Categories injected via `quarto::write_yaml_metadata_block()` are not used in listing

[Bisaloo]

I am trying to dynamically generate tags (based on whether the date is in the past or not):

```{r}
#| label: metadata-block
#| output: asis
#| echo: false
quarto::write_yaml_metadata_block(
  # We leave 7 days of delay after the starting date to account for event duration
  categories = ifelse(
    isTRUE(Sys.Date() > as.Date(rmarkdown::metadata$date, optional = TRUE) + 7L),
    "Past",
    "Future"
  )
)
```

On each individual page, the resulting categories is correctly displayed but it seems this is not taken into account in the listing. The tags are not displayed and I cannot select posts by tags.

Is this immediately clear to you or would you like a repo with a reprex?

[CarwilB]

Reprex here:

---
title: "Article title"
output: html_document
---

 ```{r}
#| label: write-yaml-metadata-block
#| output: asis

doc_author <- "Author Name"
doc_date <- "2025-03-26"

quarto::write_yaml_metadata_block(
  list(
    author = doc_author,
    date = doc_date
  )
)

Results in:

[CarwilB]

There's a fairly simple underlying bug here. Run interactively, the function inserts an extra hyphen into its output:

Input:

quarto::write_yaml_metadata_block(
     list(
         author = "John Doe",
         date = "2025-03-01"
     )
 )

Output:

[1] "---\n- author: John Doe\n  date: '2025-03-01'\n---\n"
attr(,"class")
[1] "knit_asis"
attr(,"knit_cacheable")
[1] NA

[Bisaloo]

@CarwilB, I think that's a different issue. My issue is specifically about categories and listings. I will submit a reprex later today.

Could you submit a separate issue for your problem please?

[Bisaloo]

Here is a reprex:

https://github.com/Bisaloo/quarto-dynamic-categories

This post uses a dynamically generated category (via quarto::write_yaml_metadata_block()) and it's displayed correctly on the post page: https://hugogruson.fr/quarto-dynamic-categories/posts/welcome/

But it's not visible in the listing: https://hugogruson.fr/quarto-dynamic-categories/

[cderv]

I don't think this is related to Quarto R 📦

There is a high chance that the categories field only works when provided in the front matter and/or is only considered before document computations happen, as it is project-related. I am thinking the latter if listing resolution is happening too soon and metadata isn't there.

This needs to be confirmed, but it looks like a feature request in Quarto CLI to get support for such a workflow.

I'll check with your reprex to understand how this works internally.

[cderv]

Categories are read from Document meta

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

Lines 1172 to 1177 in 32836c3

	const categories = documentMeta?.categories
	? Array.isArray(documentMeta?.categories)
	? documentMeta?.categories
	: [documentMeta?.categories]
	: undefined;

which is only the YAML metadata that are inside the source file

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

Line 1084 in 32836c3

const docRawMetadata = target?.markdown.yaml;

this happens in listing reading from source file in the project

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

Lines 248 to 251 in 32836c3

	for (const listing of listings) {
	// Read the metadata for each of the listing files
	const { items, sources } = await readContents(source, project, listing);

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

Lines 156 to 161 in 32836c3

	// Read and resolve listings from the metadata
	const { listingDescriptors, options } = await readListings(
	source,
	project,
	format,
	);

So it is not a matter of order, this is a matter of how the metadata considered for listing are read, and for now, it works on initial markdown parsed, not the intermediate after engine execution it seems.

[cderv]

Considering how metadata are merged and considered

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

Lines 1084 to 1093 in 32836c3

	const docRawMetadata = target?.markdown.yaml;
	const directoryMetadata = await directoryMetadataForInputFile(
	project,
	dirname(input),
	);
	const documentMeta = mergeConfigs(
	project.config,
	directoryMetadata,
	docRawMetadata,
	) as Metadata;

One trick would be to write from your cell to _metadata.yml in the post folder

```{r}
#| label: metadata-block
#| output: asis
#| echo: false
yaml::write_yaml(
  list(categories = "news"),
  file = "_metadata.yml"
)
```

This would be picked up when reading the listing information and it is done effectively after execution.

This would be a workaround for this specific use case.

[cscheid]

FYI, I've created a metadata label; as part of the 1.9 work we are going to try and clean up and standardize metadata resolution in quarto-cli. If you see related issues, feel free to add the label