Build a Reusable WordPress Blog Structure with Shilpi

A blog becomes harder to maintain when every article carries its own copy of the same layout. A change to the byline, reading width or related-posts section can turn into a series of individual edits. A reusable structure gives those decisions a clear home.

In Shilpi, the right structure depends on whether a post uses ordinary WordPress content or contains its own Shilpi HTML. That distinction matters more than choosing a card design. This guide explains the architecture and the checks to make before applying it to an existing blog.

Start by identifying how your posts render

Shilpi documents with their own HTML render themselves. A Single template does not automatically wrap those posts. Ordinary WordPress posts can use a matching Single template for their surrounding layout.

This means creating a new Single template alone will not restyle every existing Shilpi-authored article. Inspect a representative post first. If you want to migrate a blog to shared templates, plan that conversion separately and preserve the article content and URLs.

Give each part of the blog one responsibility

• Post content: the article’s paragraphs, headings, lists and editorial media.
• Single template: the shared article presentation for posts that use it.
• Loop template: one reusable card, repeated for matching posts.
• Archive template: the heading and results layout for a category, date or other archive.
• Part template: a reusable fragment, such as a closing call to action.

Keep the editorial content in the post. A card should link to that content and summarise it; it should not contain a separate, manually maintained version of the article.

Use the template slug that matches the route

Shilpi uses template slugs to match requests. A Single template named single supplies the broad fallback; single-post targets posts more specifically. A template called article-design may save successfully without being assigned to the route you intended.

Similarly, archive is a broad archive fallback, while home addresses the WordPress posts page. A normal page at /blog/ containing its own query loop is a different setup from a WordPress-assigned posts page. Inspect your actual configuration before changing either.

The template routing documentation explains the supported names. Read the existing template before updating it, because the same record may affect many public URLs.

Keep dynamic values dynamic

Use the current post’s title, URL, date and author values in reusable templates. Shilpi supports tokens such as {post:title} and {post:url}. For full article content inside a Single template, the designated render slot is data-shilpi-post-content.

Do not hard-code an author or publication date into a shared template. Check what happens when an excerpt or image is missing, and decide on a consistent editorial rule for those fields.

Design one card, then let the loop repeat it

A Loop template can define the image, title, date and article link once. A query loop can reference it using template=post-card, where post-card is the saved Loop template’s slug.

When building the loop markup directly, remember that data-shilpi-loop repeats the element carrying the attribute. Place it on the repeated card or on the host that names the Loop template, rather than accidentally repeating the entire outer grid.

Keep the card heading and link meaningful. Test an unusually long title alongside a short one. The layout should remain readable even when the content does not fit the sample you designed around.

Make category archives respect their query

On archive and search routes, inherit=1 reuses the current WordPress query. A separate generic latest-posts query can show unrelated articles on a category page, even if the heading names the correct category.

Add the appropriate pagination region and test a result set larger than one page. A fixed latest-posts loop is useful for a homepage section, but it is not a complete archive. Readers need a way to reach older articles as the collection grows.

Verify the structure with real content

1. Open a short article and a long article to check reading width and heading spacing.
2. Open a category archive and confirm that its results belong to that category.
3. Check a second results page and follow a card to its article.
4. Inspect a post with missing optional media or a short excerpt.
5. Test narrow screens and keyboard navigation through card links.
6. Confirm that a self-rendering Shilpi post still uses its intended layout.

These checks separate a reusable content structure from a page that only looks correct with one set of sample data.

Frequently asked questions

Do I need to convert all existing posts at once?

No. Inventory the current rendering approach, decide on a future publishing pattern, and plan any migration explicitly. A new article does not require a redesign of the whole blog.

Can I reuse a call to action across articles?

Yes. A Part template can supply a shared fragment. Keep its message relevant to the articles that include it, and remember that changing the part changes each place where it is rendered.

What should I read next?

Use the dynamic content reference while implementing the structure. Before publishing changes, follow the WordPress launch checklist.