Editing the Diligent Services website

This site is a small Quarto site. Every page is a plain text file you can edit by hand. You do not need to be a programmer to update the words, the contact details, or the colors. This guide walks through the common changes step by step.

Golden rule: edit the text, preview it, then publish. Nothing you type goes live until you run the publish step at the bottom.

1. Which file is which page?

To change this page… Edit this file
Home index.qmd
Services services.qmd
About Us about.qmd
Contact contact.qmd
Support support/index.qmd
Blog (the list) blog/index.qmd
A blog post the matching file in blog/
The menu, footer, contact email/phone _quarto.yml
Colors and fonts styles/custom.scss
The “made with AI” note (G611) _g611.qmd

Each .qmd file starts with a small block between --- lines (the “front matter”, which sets the title) followed by the page text written in Markdown.

2. Change the words on a page

  1. Open the file from the table above in any text editor.
  2. Below the --- block, edit the text. Markdown basics:
    • ## A Heading makes a section heading.
    • - item makes a bullet. **bold** makes bold text.
    • [link text](contact.qmd) makes a link to another page.
  3. Save the file, then preview (section 5) and publish (section 6).

Keep these lines exactly as they are wherever they appear, they are required:

  • Diligent Services is a DBA of Carmelita Enterprises Inc.
  • the CSLB license number 1132892

4. Change the colors or fonts

Open styles/custom.scss. The top section has a short list of named colors with comments, for example:

$ds-cream:  #FBF9F4;  // page background (warm off-white)
$ds-brass:  #9A6B1E;  // the one warm accent (buttons, active nav, rules)

Change a # hex value to recolor the site, then preview. To change a font, update the two font-family lines here and the Google Fonts <link> near the bottom of _quarto.yml so the new font actually loads.

5. Add a blog post

  1. Copy an existing post in blog/ to a new file, e.g. blog/my-new-post.qmd.
  2. Edit the front matter at the top: title, date, description, and the categories.
  3. Write the post in Markdown below the front matter.
  4. Preview, then publish. The post appears on the Blog page automatically.

(There is a longer how-to post already in the blog: “How to Create and Publish a Quarto Blog Post”.)

6. Preview your changes locally

From a terminal, in the project folder:

quarto preview

This opens the site in your browser and refreshes as you save. Press Ctrl+C to stop. Use this to check your edits before publishing.

7. Publish to the live site

The live site does not update automatically when you save or push, you have to publish it. The site runs on the company’s web server (Hetzner). The steps:

  1. Commit and push your changes to GitHub (git add <files you changed>, git commit -m "update copy", git push).

  2. Connect to the server over SSH (the login key is stored in the company 1Password under “Hetzner | root | diligentservices.io”).

  3. On the server, run the safe publish script:

    cd /var/www/diligentservices/diligentservices-quarto
./publish.sh

    publish.sh backs up the current live site, pulls, renders, and — if any step fails — automatically restores the previous version, so the live site is never left half-broken. It prints the previous commit so you can roll back later. The web server serves the rendered _site/ folder directly; no restart needed.

    (Raw steps it runs, if you ever need them by hand: git pull, then source .venv/bin/activate — required, or the computational blog posts fail — then quarto render.)

Review before publish. Public, client-facing copy should be read over (and, for blog posts, approved by Sam) before this publish step. When in doubt, preview and ask first.

8. Roll back a bad change

Every published version is just a git commit, so nothing is ever truly lost — you can always put the previous version back, usually in under a minute. On the server:

cd /var/www/diligentservices/diligentservices-quarto
git log --oneline          # find the last good commit (publish.sh also prints it)
./rollback.sh <commit>     # e.g. ./rollback.sh dc8e93d

rollback.sh checks out that commit and re-renders, so the live site looks exactly like it did then. When you’ve fixed the problem and want to move forward again:

git checkout main && ./publish.sh

9. House rules

  • No client names or project specifics on the public site unless you have written permission. Keep capability copy generic.
  • Keep the DBA legal line and the CSLB 1132892 number wherever they appear.
  • Keep the /support page live with a working email link, an app store requires it.
  • The AI-authorship note (_g611.qmd, shown on Support) stays for any page that is largely written with AI help.