gohugoio/hugo · error
%q: %w
Error message
%q: %w
What it means
Generic page-error wrapper from pageMetaSource.wrapError when the source file (m.f) is nil (page.go:784). It prepends the page's logical path (%q) to an inner error so the failing page is identifiable even when no file metadata is available to attach a richer file-position annotation.
Source
Thrown at hugolib/page.go:784
type renderStringOpts struct {
Display string
Markup string
}
var defaultRenderStringOpts = renderStringOpts{
Display: "inline",
Markup: "", // Will inherit the page's value when not set.
}
func (m *pageMetaSource) wrapError(err error, sourceFs afero.Fs) error {
if err == nil {
panic("wrapError with nil")
}
if m.f == nil {
// No more details to add.
return fmt.Errorf("%q: %w", m.Path(), err)
}
return hugofs.AddFileInfoToError(err, m.f.FileInfo(), sourceFs)
}
// wrapError adds some more context to the given error if possible/needed
func (ps *pageState) wrapError(err error) error {
return ps.m.wrapError(err, ps.s.h.SourceFs)
}
func (ps *pageState) getPageInfoForError() string {
s := fmt.Sprintf("kind: %q, path: %q", ps.Kind(), ps.Path())
if ps.File() != nil {
s += fmt.Sprintf(", file: %q", ps.File().Filename())
}
return s
}
View on GitHub (pinned to 52c9bd7908)
Solutions
- Read the inner %w after the colon — that is the actionable error.
- If the page is synthetic/adapter-generated, check the data source feeding it.
- If you expected a file-backed page, investigate why FileInfo is nil (early construction failure upstream).
Defensive patterns
Strategy: try-catch
Try / catch
if err := page.WrapError(srcErr); err != nil {
// no file metadata; act on errors.Unwrap for the real cause
cause := errors.Unwrap(err)
} Prevention
- For synthetic/adapter pages, ensure upstream construction succeeded so the inner error is meaningful.
- Use the path prefix in the message to locate the page, then fix the inner cause.
When it happens
Trigger: Any page-level error where the page has no backing FileInfo (m.f == nil) — e.g. a synthetic/adapter page or a page constructed in memory — and wrapError is called to add context. The wrapped %w is the originating error.
Common situations: Content-adapter/data-driven pages, headless or programmatic pages, or error paths reached during early page construction before a file is bound. Seeing this often means the real cause is in the inner %w; the path prefix just names the page.
Related errors
- [%s] page %q: " + format + ": %w
- invalid Page received in Ref
- invalid Page received in RelRef
- failed to create page from file %q: %w
- failed to create page meta from file %q: %w
AI-assisted analysis of gohugoio/hugo@52c9bd7908 (2026-08-09).
Data as JSON: /api/errors/4c0b0219bc38cfe5.
Report an issue: GitHub.