Website Admin Guide :: R-Ladies organizational guidance

How the site is built

Mon, 01 Jan 0001 00:00:00 +0000

The RLadies+ global website is a Hugo site. Not a blogdown site, not a Quarto site — a plain Hugo site that uses a custom theme called hugo-rladiesplus, vendored under themes/hugo-rladiesplus/. If you have worked on a Hugo site before, the layout will feel familiar. If you have not, the rest of this page will give you the mental model you need before you start poking at templates. The theme started life as a fork of Hugo Initio and has since been rewritten on top of Tailwind CSS v4 and Alpine.js.

Theme assets and npm bundling

Mon, 01 Jan 0001 00:00:00 +0000

When you clone the website repo and run hugo server, the site just works. You did not install Node. You did not run npm install. The chapter map renders. The events calendar renders. The dark-mode toggle works. That is on purpose, and the way it is achieved is worth understanding before you start changing things. The constraint that shaped the build Most of the people who contribute to the RLadies+ website are not full-time front-end engineers. They are R-using volunteers who want to fix a typo, add a chapter entry, or write a blog post. Asking them to install a JavaScript toolchain just to preview a markdown change would push most of them away.

The directory: where members live and how the site uses them

Mon, 01 Jan 0001 00:00:00 +0000

The RLadies+ directory looks, from the outside, like one page on the website: https://rladies.org/directory/. A grid of member cards, three filters, a click-through to a profile. Underneath, it is a small pipeline that touches three repositories, one Airtable base, two GitHub Actions, and a handful of cross-references that make the same person show up in five different places without anyone editing five different files. If you are new to the site, the directory is the most important data source to understand. It is also the one most likely to surprise you, because the canonical data does not live in this repo.

Shortcodes, callouts, and render hooks

Mon, 01 Jan 0001 00:00:00 +0000

Markdown is the writing surface. Hugo, Tailwind, and the theme’s render hooks are what turn it into a styled page. Most of the time you do not need to think about that — write prose, write headings, link things, embed an image. Sometimes you do. This page covers the things you can reach for that are not standard markdown. Render hooks: the magic that happens automatically Three pieces of markdown behave a little differently on this site than on a vanilla Hugo install, because the theme defines render hooks that intercept them.

A tour of the sections

Mon, 01 Jan 0001 00:00:00 +0000

The site has a lot of pages. Most of them fall into a small number of patterns, and each pattern has its own template, its own data sources, and its own quirks. This page is a guided tour: section by section, what it is, where its layout lives, what feeds it, and what to know before you change it. Home Layout: _default/index.html. The homepage is composed of six partials, each rendering one strip:

Dark mode and theming

Mon, 01 Jan 0001 00:00:00 +0000

The site has a dark mode. It is not a separate stylesheet, not a runtime CSS swap, not a third-party library. It is a single CSS class on , twenty lines of JavaScript loaded inline, and Tailwind’s dark: variant. Knowing the few moving parts will make it obvious where to add support for new components and where to fix bugs. What the user experiences A toggle in the navigation switches between light and dark. The first time a visitor lands on the site, the theme matches their operating system preference (prefers-color-scheme). The first time they click the toggle, their choice is stored in localStorage under the key theme and used on every subsequent visit. If the OS preference changes while the user has not yet expressed an explicit preference, the site follows along.

SEO, social previews, and accessibility

Mon, 01 Jan 0001 00:00:00 +0000

You will probably never write SEO metadata by hand on this site. The theme generates Open Graph cards, Twitter cards, hreflang alternates, JSON-LD structured data, and the site’s robots/sitemap configuration from front matter and site params. This page explains where the generation happens so you can debug a wrong-looking Slack preview or fix a missing alt-text complaint without grepping templates. What gets generated, and from what partials/head/meta.html is the shared head block for every page. It computes:

GitHub Actions and CI

Mon, 01 Jan 0001 00:00:00 +0000

The website’s CI is a small constellation of workflows in .github/workflows/. Some of them build and deploy. Some run quality checks. Some sync data from external systems on a schedule. This page lists every workflow, what it does, and what to know when it fires on your PR. Building and deploying Production build build-production.yaml builds and deploys the live site to https://rladies.org/. It runs on every push to main and twice a day on a cron (45 */12 * * *) so timezone-relative content like upcoming events stays fresh.

Reviewing pull requests

Mon, 01 Jan 0001 00:00:00 +0000

Most weeks, the bulk of website team work is reviewing pull requests. Some are blog posts. Some are typo fixes. Some are a translation team member adding a Spanish version of a page that was written in English last month. Some are a contributor adding their first chapter. A few are us — fixing something we broke. Reviewing well is mostly about reading what GitHub Actions has already told you, then doing the parts CI cannot — actually loading the preview, checking the words make sense, deciding whether the change belongs. This page walks through how to do that without missing things.

Blog Administration

Mon, 01 Jan 0001 00:00:00 +0000

Working on the Blog Administration Team for R-Ladies consists of mainly two tasks: Serve as Editor for incoming blog posts Recruit possible Authors for contributing to the blog. There has not been much work done on the blog, and we would like to change that. This guide is a work in progress and is likely to change once we have a more team working towards making the blog more active.

Creating a pretty URL

Mon, 01 Jan 0001 00:00:00 +0000

The site supports “redirect” pages — content files that exist only to bounce visitors from a clean URL on rladies.org to somewhere else. This is how rladies.org/form/blog-post becomes a long Airtable form URL, how rladies.org/positconf24 jumps to a Slido during a conference, how the directory update form keeps working under three different historical paths. The pattern is small and self-contained, but it solves a real problem. Forms move. URLs change. Slack messages, printed flyers, conference slides, and other community sites linking to us are everywhere we cannot edit retroactively. A redirect on our own site is the one URL we always control — change it once, every old reference still works.