Cocktails Template

A P1 Template for cocktail recipe pages, read from a live Herradura recipe (herradura.com/en-us/blog/cocktail/horseshoe-margarita/).

Same caveat as Products Template: this is a spec to build in the editor, not code to check in: see Can a template’s layout be defined in code?

Reference structure

Name: “Horseshoe Margarita”
Tagline: “Simple ingredients, crisp flavor.”
Description: a short paragraph (“Bright and refreshing for after work drinks or rooftop launch parties.”)
Ingredients: a bulleted list: “2 parts Tequila Herradura,” “1 part freshly squeezed lime juice,” “½–¾ agave nectar (to taste)”
Instructions: a single paragraph, not numbered steps: “Combine all ingredients and shake with ice to chill. Strain over fresh ice and garnish with a half-salt rim and lime.”
“Best With”: lists multiple compatible products (“Silver, Reposado”), not one single featured product
“How to Make It” video: gated behind OneTrust’s Targeting consent category; confirmed live (see Cookie Consent)
Featured recipes carousel: other recipes, not this recipe’s own data (site chrome, not a template field)

Two real differences from what we documented off Jack Daniel’s equivalent page: instructions are one flowing paragraph here, not a numbered step list, and “Best With” is a list of compatible products rather than one single featured product. Neither site’s pattern is more “correct.” Pick deliberately for the P1 build rather than copying either verbatim. A numbered-step array (like Products’ profile fields) is probably the better authoring UX regardless of which site historically used prose.

Proposed field shape


interface CocktailFields {
  name: string;
  tagline: string;
  description: string;              // richtext
  heroImage: MediaValue;
  ingredients: { amount: string; name: string }[];  // array field
  instructions: { step: string }[]; // array field: recommend structured over prose
  bestWith: ProductRef[];           // multiple products, not one, see below
  howToMakeItVideo?: MediaValue;    // gated behind Targeting consent
}

The Product relationship: confirmed, no native mechanism exists

This is the cross-document relationship flagged as open in the previous version of this page, now properly investigated, not just guessed at. See Content Relationships for the platform-wide version of this finding, including a real extensibility primitive (Remote Datasources) a custom mechanism could be built on.

What’s confirmed real: products link to the recipes that feature them, and recipes link back to compatible products (bestWith), verified on both sides, on the actual Herradura site.

What’s confirmed not available natively: we searched for a P1/Puck field type that lets an editor pick another document on the same site (the mechanism this relationship would need) and found none. template-select-field.js in @pantheon-systems/puck-css picks a Template (a content type), not a document instance. The external field type exists in Puck’s core API, but P1 hasn’t shipped a ready-made “pick a page on this site” implementation of it the way it has for media (createMediaFigureBlock) or remote APIs (createDataListBlock). Every real example we found queries either an external API or the media library, never the site’s own CCR documents.

Building this ourselves is architecturally plausible (documents live at known paths, client.documents.list()/getByPath() already exist; see Workflows) but is genuinely new work, not a configuration of something P1 already provides. A custom external-type field backed by a query against this site’s own Product documents is the shape it would take. Scope this explicitly rather than assuming it falls out of the Templates API for free.

Route pattern: /recipes/:slug (Herradura’s live URL structure uses /blog/cocktail/:slug: a WordPress convention from the current site; the P1 rebuild should pick its own clean pattern rather than inheriting the /blog/ segment).

Pinned vs. editorial

Pinned: the “Best With” block structure and its links back to product pages, presumably a cross-promotion requirement, not something an editor should be able to accidentally remove.
Editorial: name, tagline, description, ingredients, instructions.