11tyx5: Five Whitestone Foundation Sites, Eleventy, and the Long Open Web

Launching one site feels good. Launching five at once feels like a very specific mix of systems thinking, code soup, and questionable sleep habits. In this case it also turned out to be the right call — and it turned out to be just the beginning.

Over the last year I rebuilt a whole family of Whitestone Foundation sites with Eleventy: JCRT, The New Polis, Journal of The New Polis, Esthesis, and The Whitestone Foundation. JCRT's attached religioustheory publication stream came along with that work too, because once you start cleaning up a journal's publishing architecture, the side rooms are part of the house whether you planned for them or not.

This was never just a redesign. It was a content migration, a metadata cleanup job, a URL preservation campaign, a search rebuild, a workflow reset, and a practical test of how far minimal computing can take an academic publishing network. That last part matters to me. I did not want to swap one fragile setup for another one with nicer CSS and a cooler README. I wanted sites that could stay online, stay editable, stay searchable, and stay legible for a long time.

But the original launch was only the first chapter. This post is the update.

Since those five sites went live, I have kept iterating — on jcrt.org especially, but across the whole network. I split the JCRT repository in two, thanks to a conversation with Brennan. I integrated Zotero harvestability metadata across every site in the network, thanks to Martin Paul Eve. I rolled out standard.site machine-readable discovery metadata. And I have a Version 3 redesign for The Whitestone Foundation in progress, plus a plan to work with KC Commons on persistent DOI numbers for the journals. The network keeps moving.

If you spend time around #11ty, #indieweb, or #webdev, you know how often web conversations drift toward novelty. New frameworks, new pipelines, new dashboards, new layers, new reasons to rebuild the rebuild. I like new tools as much as the next person, but these sites needed something more grounded than that. They needed a durable publishing system built from plain files, boringly reliable URLs, and FOSS projects that respect the open web. They needed it at launch, and they still need it now.

Why I Launched Five Sites at Once #

The sane version of this story would involve one migration at a time.

Start with one site. Learn the lessons. Refactor the process. Move to the next. That is good project management advice, and I ignored it almost immediately.

I went after five sites together because they already behaved like a network. They shared editors, institutional context, design history, hosting assumptions, and publishing problems. If I solved JCRT in isolation, I would still have to solve journal structure for journal.thenewpolis.com, blog logic for thenewpolis.com, organization pages for thewhitestonefoundation.org, and a more expressive art-and-theory design language for esthesis.org. The details differ, but the actual questions were the same:

• How should content live on disk?
• What metadata should be required?
• How do authors get represented across sites?
• What should URLs look like if we want them to stay useful?
• How do we make search work across a distributed publishing network?
• What does a low-maintenance editorial workflow actually look like?

Once I saw that clearly, doing one site at a time started to look less careful and more misleading. I did not need five unrelated solutions. I needed one coherent publishing approach with room for variation.

That is why I treated the project as 11tyx5. Shared architecture, shared lessons, different visual identities, different editorial rhythms.

The Five Sites, Five Different Jobs #

One reason this project stayed exciting, even when the build logs were rude, is that each site gave me a different problem to solve.

JCRT was the heavyweight. It carried the deepest archive, the messiest historical layers, the most fragile old URLs, the heaviest PDF baggage, and the most academic pressure around citations, indexing, and long-term access. JCRT is where every bad decision from multiple web eras shows up in one place. That is not a complaint. That is what history looks like on the web. The JCRT GitHub repository tells the same story in commit history: hundreds of cleanup passes, metadata fixes, search patches, and structural improvements layered over months of work.

Journal of The New Polis — tracked in its own repository — gave me a cleaner laboratory for journal patterns: issue pages, article pages, contributor metadata, and a saner content tree. It let me test approaches that JCRT also needed, but without making every experiment carry the full weight of a late-1990s archive.

The New Polis, now in its own actively maintained repo, worked as the faster-moving publication layer. Categories, essays, navigation, feeds, and editorial workflow all mattered there in a slightly different way. A journal can tolerate a little ceremonial structure. A magazine-style site has to move.

Esthesis, housed in esthesis-v2, was where I allowed more personality. I did not want a network of cloned sites with different logos pasted into the same template. Esthesis needed a stronger artistic and typographic voice while still living inside the same general publishing philosophy.

The Whitestone Foundation — its repository here — needed the opposite energy. It had to feel clear, stable, and institutional without turning into a dead bureaucratic shell. It is the parent site. People should be able to understand what the organization is, what it publishes, and where to go next without fighting the interface. A new Version 3 of the site is coming — more on that below.

That spread is exactly why doing all five together was productive. The differences forced better abstractions. The shared problems forced discipline.

Minimal Computing Was the Actual Method #

I talk a lot about minimal computing because it has changed the way I think about web publishing. I do not mean "minimal" in the sense of trendy beige websites that mistake emptiness for elegance. I also do not mean some fake monkish purity where every JavaScript file is treated like a moral failure. I mean the working method described by the GO::DH Minimal Computing group and especially the minimal computing ontology: minimal design, minimal cost, minimal maintenance, minimal obsolescence, maximum justice.

That framework fits academic publishing better than a lot of enterprise software ever will.

A journal or cultural publication does not need a stack that looks impressive in a venture capital pitch deck. It needs to remain editable by future humans. It needs to survive staff changes, budget constraints, broken plugins, old citations, and that one weird article from 2004 whose HTML structure seems to have been assembled in a fever dream. Minimal computing starts from necessity. It asks what a project actually needs in order to endure.

For these sites, that translated into a few practical commitments.

Content should live in formats that are readable without specialized software. Markdown, YAML, JSON, and ordinary files win here.

URLs should be predictable and stable. If someone cites an essay, I want a decent chance that the link will still work years from now. Human-readable archive paths such as /archives/24.2/lastname/ are a feature, not a compromise.

The publishing system should be understandable. I do not want a site that only functions when the original builder remembers the secret handshake.

Migration paths should stay open. If I need to move a site later, I want content that can travel.

Performance matters, but performance is not the whole story. A fast site that is impossible to maintain is just a different flavor of bad idea.

Minimal computing also lines up with what I love about the #indieweb. Keep ownership close to the publisher. Prefer open formats. Avoid unnecessary dependency on platforms that can disappear, get acquired, or quietly decide your project is too small to matter. Use tools that respect the web as a publishing medium instead of treating websites like captive apps.

Why Eleventy (Now Build Awesome) Was the Right Tool #

Eleventy keeps proving itself to be the kind of tool I want to build with. It gives me enough power to handle complex publishing structures, but it does not force me into framework theater. I can use templates, data files, collections, filters, and build logic without pretending every site needs to become a JavaScript spectacle or a startup pitch.

One quick note on naming: Eleventy recently rebranded as Build Awesome. The tool is the same, the community is the same, and the #11ty hashtag is still where you will find the people building with it. I use "Eleventy" throughout this post because most of this work predates the rename, but Build Awesome is what you should look for going forward.

For this project, Eleventy solved a few problems at once.

It let me build journals, blogs, author pages, archive indexes, organizational pages, feeds, and sitemaps inside one general model.

It plays well with file-based content. That matters when you are moving years of articles out of HTML, SHTML, and WordPress into a structure that humans can still inspect and edit.

It kept me close to the output. I like being able to reason about what the final HTML will look like.

It also has one of the healthiest communities in web publishing. The #11ty crowd is unusually generous. I have learned a lot from official docs, community posts, issue threads, examples, and projects like 11ty Bundle. A lot of FOSS survives because people are willing to explain things clearly to strangers. Eleventy has that energy, and when you are elbow-deep in a 1999 journal archive that matters.

My stack is not ascetic for the sake of purity. I use what I need. On these sites that included Eleventy, Nunjucks, markdown-it, Luxon, Pagefind, a mix of utility scripts, and Decap CMS where a browser-based editorial layer made sense. The build got more honest too. In JCRT the main build now runs Eleventy with SKIP_IMAGE_PROCESSING=1, then runs Pagefind as a second step, and even caches the Pagefind index when the content signature has not changed. That is not glamorous. That is me refusing to waste minutes of my life for no reason.

Doing the Migration Work Instead of Talking About It #

The glamorous version of web migration is a screenshot of an old site next to a new site. The real version is archaeology.

JCRT in particular came from multiple eras of publishing logic. Some material was hand-built HTML. Some came through SHTML patterns. Some lived in WordPress. Some had inconsistent metadata. Some had weird formatting artifacts from Word. Some had PDFs that mattered a lot to the editorial history, whether or not PDFs are anyone's idea of mobile bliss.

The first step was getting content out of legacy containers and into plain text workflows. Python scripts helped with the first passes on old HTML and SHTML. Regular expressions helped more than AI did, which is a sentence I have had reason to say a lot lately. Export tools for WordPress helped too, but never in a magical one-click way. There was still cleanup to do around footnotes, shortcodes, headings, links, front matter, and all the weird little historical decisions that only reveal themselves after export number four.

That cleanup matters more than people admit. Migrations fail quietly when teams treat content as if it will automatically normalize itself once it enters a static site generator. It will not. Someone still has to decide what the canonical title is, which date belongs on the page, how authors should be named, where files belong, and whether the page should keep its old slug.

A huge amount of this project was exactly that kind of stewardship work. Fix the text. Fix the metadata. Fix the paths. Fix the assumptions. Then do it again until the structure starts to feel boring in a good way.

Separate Content From Presentation, or Pay Later #

One of the best decisions in this whole effort was keeping content and presentation more clearly separated.

That sounds obvious, but old publishing systems have a way of blurring every boundary. Content lives half in the CMS, half in templates, half in custom fields, and somehow three halves later you have a site no one wants to touch.

By moving toward plain content repositories and treating templates as templates, I could normalize front matter, clean media, and reason about data without destabilizing design every five minutes. That also made collaboration better. The more explicit the content model became, the easier it was for other people to help without needing telepathy.

This mattered a lot for multi-author work. JCRT and the related sites needed better author handling, especially for essays and issues with several contributors. In jcrt-v2 I finally made peace with the fact that semicolons are policy. The splitAuthors() helper now treats ; as canonical, normalizes stray and, &, and Oxford-comma lists, slugs the names, and lets archive templates, collections.authors, author pages, and search all point at the same person without improvising. That sounds small until you have hundreds of pages and multiple editorial eras all spelling collaboration differently.

That is the kind of improvement readers do notice, even if they never name it. Better author representation improves navigation, attribution, internal linking, search, and citation metadata.

Search, Metadata, and the Case for Boring Infrastructure #

A lot of the exciting work on these sites was, frankly, boring infrastructure. I mean that as praise.

Search had to improve. Metadata had to improve. Feeds had to improve. Sitemaps had to improve. Redirects had to improve. Those are not the flashy parts of a relaunch, but they are the difference between a site that looks updated and a site that actually works as a publication. They are also the difference between "nice launch" and "Google Scholar can actually see the thing."

With JCRT, I spent a lot of time thinking about archives as archives. If a site has years of essays, issue structures, author pages, PDFs, and citations floating around the web, you cannot treat search or metadata as afterthoughts. That is how you end up with dead links, ghost pages, and the slow disappearance of your own publication history.

Pagefind became a big part of the answer. It gave me a way to provide fast, local search without handing the whole job off to a third-party service. For the broader site network, I also worked with shared data patterns like allsites.json, append-only canonical records, and cross-site search weighting so the publications could feel distinct while still participating in one ecosystem. On the Whitestone side, that ranking logic is intentionally opinionated: jcrt.org/archives outranks journal.thenewpolis.com, which outranks jcrt.org/religioustheory, which outranks the broader magazine and organizational sites. That is not favoritism. That is information architecture.

I also became more serious about canonical data, structured front matter, and stable sitemap generation. The metadata stack now has to do real work: Dublin Core, JSON-LD, microformats, Open Graph, citation_* tags, and feed outputs that can travel. JCRT now exposes OAI-DC and DOAJ XML through sitemap endpoints, because journals live or die by whether machines can understand them as well as humans can. JCRT became the reference implementation here, and the Whitestone Foundation, New Polis, Journal of The New Polis, and Esthesis repos are being pulled toward that same baseline so the network behaves like a family instead of five cousins who all forgot each other's names.

The same goes for redirects. The dream is not to have the trendiest site in 2026. The dream is for a citation from 2011 to still land on the right page in 2036. That is a web development problem. It is also an editorial ethics problem.

Why files.jcrt.org Matters — and Why Brennan Was Right #

One of the more practical moves in the JCRT rebuild was separating heavy file concerns from the main publication logic. Large PDFs and file collections create weird pressure inside a build pipeline. They slow things down, complicate Git history, and make a content repo feel heavier than it needs to be.

I want to be honest about where this idea came from: Brennan. When I was deep in build-time frustration — watching jcrt-v2 crawl through another full rebuild because of asset overhead — Brennan encouraged me to think clearly about the problem and suggested splitting the repository. His encouragement and support made a real difference when I was second-guessing whether the overhead was just something I had to live with. It was not. The solution was to separate concerns at the repo level.

That meant spinning up jcrt-files as a dedicated CDN repository for files.jcrt.org. The main site repo (jcrt-v2) focuses entirely on the Eleventy build: templates, content, metadata, search, and output. The jcrt-files repo handles the heavy archive — PDFs, citation files, images, and downloadable assets that would otherwise bloat Git history and drag the build into the mud.

The results were immediate:

• Reduced churn in the main site repository — commits are about content and templates, not binary files.
• Faster builds because Eleventy is not tripping over large archive assets.
• Clearer separation between editorial workflow and file archiving.
• A better mental model of what belongs where.

In practice the implementation uses redirect bridges for /images/*, /docs/*, /citations/*, and archive PDFs so the public URLs stay clean and friendly while the heavy lifting moves out to files.jcrt.org. From a reader's perspective nothing changed. From a maintainer's perspective the whole thing got dramatically saner.

The jcrt-files repo has since become its own active workspace: tagging PDFs with proper metadata, adding canonical URLs, updating citation files, fixing Cloudflare Worker routing, and making sure the file delivery layer stays reliable. That is work that deserves its own space, and now it has one.

PDF still matters in academic publishing. A clean separation means those files stay first-class without letting them drag the publishing site's build into the mud.

Making These Sites Harvestable by Zotero #

One of the most rewarding recent additions across the whole Whitestone network is Zotero harvestability.

If you do academic work and you do not use Zotero, you should. It is a free, open-source reference manager that collects, organizes, and cites sources. The Zotero browser connector is particularly powerful: it can detect when you are on a supported web page and harvest citation metadata automatically. If the page has the right metadata, Zotero captures it as a "Blog Post" or "Journal Article" with proper author, date, title, and publication fields. If the page does not have it, Zotero captures it as a generic "Web Page" — less useful for researchers and far less useful for the journal.

I owe the approach I used to Martin Paul Eve, whose article "Making Blog Posts Harvestable by Zotero and Preserving Case in Citation Fields" laid out a clean RDFa-based method. Martin's guide explained exactly how to add the right combination of metadata to make pages register correctly in Zotero's type detection — and critically, how to preserve capitalization in citation fields so titles do not get mangled by citation software.

The core of the implementation involves two things. First, adding a prefix attribute to the <html> element:

<html prefix="zotero: http://www.zotero.org/namespaces/export#">

Second, adding the right <meta> tags in the head: zotero:itemType to declare the content type, citation_author, citation_publication_date, citation_public_url, prism.publicationName, and citation_language. The key insight from Martin's article is what not to include: citation_title and citation_journal_title can force the wrong item type, so those are deliberately omitted on blog-style posts.

I rolled this out across all five sites in the Whitestone network — JCRT, The New Polis, Journal of The New Polis, Esthesis, and The Whitestone Foundation — adapting the Eleventy pattern to fit each site's template structure. Each site's SEO partial now conditionally emits the Zotero block for post and article pages. The result: when a researcher visits any of these sites and clicks the Zotero connector, they get a properly typed citation with correct author, date, and publication metadata ready to drop into their reference manager.

This kind of metadata work is invisible to most readers and invaluable to researchers. Academic publishing that wants to be taken seriously as a scholarly resource cannot afford to skip it.

Adding Standard.Site Discovery Metadata #

Another significant addition across the Whitestone network is standard.site — a machine-readable discovery layer built on the AT Protocol.

Standard.site uses a sequoia.json configuration file and a .well-known/site.standard.publication endpoint to make a site's content machine-readable and discoverable through the AT Protocol network. For publishing sites, this means content can be discovered, syndicated, and interacted with through AT Protocol-native tools, including Bluesky. It is another piece of the "open web by default" philosophy — another way to make sure these publications do not depend on proprietary distribution channels for visibility.

The Sequoia integration across jcrt-v2, thenewpolis.com, journal.thenewpolis.com, esthesis-v2, and thewhitestonefoundation.org runs alongside the existing OAI-DC, JSON-LD, Open Graph, and feed infrastructure. It is not a replacement for any of that. It is an addition — one more doorway into the network's content for tools and readers that live on the open, federated web.

This fits the broader pattern I keep returning to: no single discovery channel should be the only channel. Feeds. Sitemaps. JSON-LD. Zotero metadata. Standard.site. The more ways content can be found and cited by machines that respect open standards, the longer it will survive platform shifts.

The CMS Question: Sveltia Looked Cool, Decap Shipped #

I spent real time trying to make the editorial layer more elegant. I was interested in Sveltia CMS. I am still interested in it. I also keep an eye on new 11ty-native CMS experiments because the idea of a tight, modern editorial interface is appealing.

But interest and production readiness are not the same thing.

For this network, Decap CMS won because it let the work move. The documentation was better for the workflows I needed. The Git-based model fit the architecture. Git Gateway and Google OAuth were easier to reason about than the stack I was trying to force around Cloudflare Worker auth experiments. Most important, it reduced editorial friction instead of adding another research project on top of an already complicated migration.

At a certain point you stop asking which tool looks most future-forward and start asking which one lets editors publish reliably this week. That is a useful question. More web projects should ask it earlier.

FOSS Did the Heavy Lifting #

One thing I want to say plainly is that this project exists because of FOSS.

Eleventy gave the publishing framework. Markdown-it handled parsing. Pagefind made local search viable. Python utilities helped with migration cleanup. Git and GitHub gave the history and collaboration layer. A long chain of maintainers, issue writers, example builders, theme makers, and docs writers made it possible for me to keep going when a build broke or a data model got slippery.

The more invisible pieces mattered too: the scripts that generate Pagefind imports, the SEO partials that emit citation_author and citation_pdf_url, the Zotero metadata blocks, the feed plumbing that keeps RSS, Atom, JSON Feed, and twtxt in the same neighborhood, the build scripts that generate OAI-DC and DOAJ XML endpoints. All of it depends on open standards, open tools, and open communities.

I do use hosted services when they solve real problems. I am not trying to cosplay purity politics on the internet. But the reason I trust this network more now is that the core publishing model is not locked inside a proprietary box. The content lives in files. The templates are inspectable. The output is HTML. If I need to move the whole thing later, I can.

That is freedom in a very practical sense. It also fits the values of the publications themselves. Open-access journals and small independent magazines should not have to choose between visibility and technical self-respect. FOSS keeps that door open.

Ongoing Work: What the Git History Actually Shows #

One of the things I appreciate about running these sites as open repositories is that the work is visible. The commit history on jcrt-v2 tells an honest story: hundreds of commits across mobile navigation improvements, favicon delivery fixes, Search Console error resolution, SEO patches, canonical URL cleanup, Duotrope badge integration with WebP conversion and a three-tier fallback chain, webfirewall configuration, and continuous Pagefind and metadata refinements.

The jcrt-files repository has its own parallel history: PDF tagging, canonical URL updates, citation file improvements, Cloudflare Worker routing fixes, and the ongoing work of making decades of PDF archives reliably accessible. Archival access is maintenance work. It does not end.

thewhitestonefoundation.org saw significant infrastructure additions: the metasearch system that aggregates content from across the network, LLM SEO metadata for machine discoverability, the allsites.json data layer that lets the parent site understand the full network, and team page updates. thenewpolis.com received major SEO optimization passes, search improvements, author additions, and logo updates. journal.thenewpolis.com and esthesis-v2 got the same Zotero and standard.site treatment plus SEO passes and schema improvements.

Every one of those commits is a choice about what the publication deserves. I keep making those choices because the alternative — a site that slowly stops working and slowly becomes invisible — is not acceptable for publications this important.

The Whitestone Foundation Version 3 Is Coming #

The current Whitestone Foundation site served its purpose well, but Version 3 is in active development in the thewhitestonefoundation-v3 repository.

Version 3 builds on the same Eleventy and minimal computing foundation but with a significantly cleaner design and better representation of the organization's full mission. The parent site needs to make clear what Whitestone Foundation is, which publications it supports, who the team is, and how to engage — all without fighting the interface.

The organizational page is the anchor of the network. When it is strong and clear, readers navigate confidently to JCRT, The New Polis, Journal of The New Polis, and Esthesis. When it is stale or confusing, everything downstream suffers. Version 3 is about making sure the anchor holds.

Designing for Long Life #

The phrase I kept coming back to while building these sites was long life.

I want these sites to age well.

I want them to remain comprehensible to future collaborators.

I want them to keep serving readers on ordinary devices with ordinary connections.

I want them to survive shifting platform fashions.

I want them to preserve the publication record instead of treating archives like attic clutter.

That goal affects design choices, content modeling, and infrastructure choices all at once. It is why I care about plain text, low-friction builds, stable URLs, HTML-first publishing, search that does not depend on a cloud black box, and keeping complexity where complexity earns its keep.

It also affects aesthetics. I do not think minimal computing means making every site look stripped down or timid. esthesis.org should still feel alive. thenewpolis.com should still feel like a publication with momentum. thewhitestonefoundation.org should still feel coherent and welcoming. Long-life design is not anti-style. It just asks style to cooperate with maintenance, readability, and public access.

What This Work Has Taught Me #

The biggest lesson from 11tyx5 is that shared infrastructure can create momentum instead of flattening identity.

All five sites now make more sense to me as a group and as individual publications. They have stronger boundaries. They also have a better common language. The Zotero integration, standard.site metadata, OAI-DC feeds, and shared Pagefind infrastructure all reinforce that language. When I add something to jcrt-v2 that works, I know where else it belongs.

I learned that migration work gets easier once you stop chasing perfect tools and start building dependable habits.

I learned, again, that plain files are a gift.

I learned that archives demand respect — and that respecting them means continuing to work on them, not just migrating them once and moving on.

I learned that build performance matters, and sometimes the right answer is architectural. Splitting the repo was not a hack. It was a clarity move.

I learned that metadata is audience. When the metadata is right, researchers find the work. When it is wrong, the work disappears behind a search result that says "Web Page" instead of "Journal Article."

I also learned that if you are going to do a weirdly ambitious web project, it helps to work with people who can tell you when your repo habits have become nonsense — and who will encourage you when you are worried about build times at midnight.

Thanks, and What Comes Next #

I owe a lot of this work to collaborators and communities.

Thanks to Brennan for encouragement, support, and the idea of splitting the JCRT repository into a site repo and a separate assets CDN. That conversation made a real difference. When I was frustrated with build times and second-guessing whether the architecture was workable, Brennan helped me see the solution clearly. The jcrt-files repository exists because of that conversation.

Thanks to Martin Paul Eve for his article "Making Blog Posts Harvestable by Zotero and Preserving Case in Citation Fields". That post gave me exactly what I needed to roll out Zotero harvestability across the entire Whitestone network. Martin's clear explanation of the RDFa prefix approach and the key tags required saved me a significant amount of reverse engineering. I am grateful for it, and I am grateful that he published it openly for anyone trying to do the same work.

Thanks to the editors, authors, and organizers who trusted the process while the infrastructure was changing under their feet. Thanks to the broader #11ty, #indieweb, and FOSS communities for continuing to prove that the open web still has builders who care about durability as much as novelty.

There is still more to do. There always is. JCRT in particular will keep receiving archive, metadata, and performance work because a site that old is never really finished. The Version 3 redesign of The Whitestone Foundation is in progress. And the next major milestone I am working toward is DOI number integration — working with KC Commons to assign persistent Digital Object Identifiers to journal content across the network. DOIs matter for academic citation permanence and indexing in places like CrossRef, Google Scholar, and JSTOR. Getting them right is the kind of infrastructure work that academic publishing depends on, and it is the logical next step for a network that already has clean URLs, structured metadata, Zotero harvestability, and OAI-DC feeds in place.

The important shift has already happened. These publications are no longer trapped in a pile of inherited workflows. They have a modern stack, portable content, better search, stronger metadata, Zotero integration, AT Protocol discoverability, and a much better chance of still being online, legible, and useful years from now.

That is the part I am proud of.

Not that I launched five sites at once, though I am proud of that too.

I am proud that the result is more durable, more open, and more alive. And I keep making it better.