Updates — Upgrading Dax Pro Without Losing Customizations

Complete guide to updating Dax Pro: how to check for new versions, download them from Gumroad, compare old and new files, safely merge changes into your customized project, and test before deploying. Includes a version control strategy that keeps updates safe.

Why Updates Matter

Dax Pro is sold with lifetime updates. When a new version releases, you receive an email from Gumroad with a download link. The new version may include:

  • Bug fixes — broken partials, CSS issues, template errors
  • New features — new sections, new components, new theme options
  • Updated dependencies — a newer .NET version, updated Decap CMS
  • Improved documentation — new chapters, corrected examples
  • Security patches — rare (static sites have few attack vectors), but possible

    • You are not required to update. If your site works and you are happy with it, you can stay on the version you purchased forever. Gumroad keeps the download link active.

    But over time, staying stale means:

  • Missing bug fixes that other users benefit from
  • Missing new features that would improve the site
  • Difficulty getting support (the first question for any bug is "are you on the latest version?")
  • Compatibility issues if you upgrade the .NET SDK or other dependencies

    • The recommendation: update quarterly, or immediately if a version fixes a bug that affects you. But update carefully — do not overwrite your customized project with a fresh download.

    This chapter covers:

    1. How updates are delivered — Gumroad, email, download

    2. What typically changes between versions — and what does not

    3. The update checklist — step-by-step process

    4. Comparing old and new files — how to see what changed

    5. Merging safely — how to bring changes into your customized project

    6. Testing before deploy — how to verify the update works

    7. Rolling back — how to recover if an update breaks the site

    8. A version control strategy — how to make future updates easy

    How Updates Are Delivered

    The Gumroad email

    When a new version is released, Gumroad sends an email to the address associated with your purchase. The email subject is typically:

    Dax Pro has been updated

    The email contains:

  • A summary of what changed
  • A download link
  • The version number (e.g., "v1.1.0")

    • The download link is the same as your original purchase link. Clicking it downloads the latest version. Previous versions are not directly downloadable — Gumroad serves the current version.

    The Gumroad library

    You can also access the download at any time:

    1. Open gumroad.com/library

    2. Log in with the email used at purchase

    3. Find Dax Pro

    4. Click Download

    5. The ZIP contains the latest version

    The version number

    Every Dax Pro release has a version number, following semantic versioning:

  • v1.0.0 — first release
  • v1.0.1 — patch (bug fix, no new features)
  • v1.1.0 — minor (new features, backward compatible)
  • v2.0.0 — major (breaking changes, requires migration)

    • Where to find the version:

  • In the Gumroad email subject or body
  • In the project's README.md (top of the file)
  • In Dax.csproj (the element)
  • In _data/metadata.yaml (if the release adds a version field — optional)

    • Before updating, check the version you are currently on. If you have already customized the project, you need to know what version you started from.

    What Typically Changes Between Versions

    Understanding what changes helps you plan the merge.

    Files that almost never change

  • Program.cs — the C# engine. Unless a release specifically mentions engine changes, this file is stable. Most Dax Pro updates do not touch it.
  • Dax.csproj — the project file. Changes only when the .NET target version changes (rare).
  • LICENSE — the license text. Stable unless legal terms change.

    • Files that sometimes change

  • templates/layouts/*.dax — layout files. Bug fixes to the markup, new sections in the layout, CSS class renames.
  • templates/partials/*.dax — partials. Similar to layouts — bug fixes, new fields, class changes.
  • _data/*.yaml — configuration data. New fields added, obsolete fields removed, defaults updated.
  • public/css/style.css — the stylesheet. Bug fixes, new component styles, responsive improvements.

    • Files that often change

  • README.md — version number, update notes, new sections.
  • content/index.md — demo content. May include new example sections or updated text.
  • content/posts/*.md — demo blog posts. May be updated to reflect new features.
  • public/admin/config.yml — Decap CMS configuration. May add new collections or fields.

    • Files that are specific to your project

    These files are yours. They do not exist in the original Dax Pro ZIP (or exist as demo content that you replaced):

  • Your custom content — content/about.md, content/privacy.md, all your posts, all your services
  • Your branding — _data/metadata.yaml with your title, description, URL
  • Your navigation — _data/nav.yaml with your menu
  • Your footer — _data/footer.yaml with your links
  • Your custom CSS — if you added rules to style.css
  • Your images — public/images/ with your photos
  • Your .git/ folder — your version history

    • Never overwrite these with a fresh download. They are the value of your project.

    The Update Checklist

    The safe update process has seven steps. Do them in order. Do not skip steps.

    Step 1: Back up your current project

    Before touching anything:

    cd ~/Projects

    cp -r dax-pro dax-pro-backup-$(date +%Y%m%d)

    Or, if using Git:

    cd ~/Projects/dax-pro

    git add .
    

    git commit -m "Backup before update to Dax Pro v1.1.0"
    

    git tag pre-update-v1.1.0
    

    git push origin main --tags

    Both approaches work. The ZIP backup is simpler; the Git tag is more recoverable.

    Do not skip this step. If the update breaks something, this is how you recover.

    Step 2: Download the new version

    1. Open the Gumroad email or gumroad.com/library

    2. Download the latest Dax Pro ZIP

    3. Extract it to a separate folder — not on top of your existing project:

    cd ~/Projects

    unzip ~/Downloads/dax-pro-v1.1.0.zip -d dax-pro-new

    Now you have:

  • ~/Projects/dax-pro — your customized project
  • ~/Projects/dax-pro-new — the fresh new version

    • Step 3: Compare the two folders

    The goal is to identify what changed in the new version so you can bring only those changes into your project.

    Using a file comparison tool:

    Command line (diff):

    diff -rq ~/Projects/dax-pro ~/Projects/dax-pro-new

    This outputs a list of files that differ. Files that are identical are omitted.

    VS Code:

    1. Open ~/Projects/dax-pro in VS Code

    2. Open a new window with ~/Projects/dax-pro-new

    3. Use the built-in compare: right-click a file in one window, choose Select for Compare, then right-click the corresponding file in the other window and choose Compare with Selected

    4. VS Code shows the diff side-by-side

    Visual diff tool (Meld, Beyond Compare):

    If you have a diff tool installed, use it for a visual overview:

    meld ~/Projects/dax-pro ~/Projects/dax-pro-new

    What you are looking for:

  • Files in templates/ that changed — these are the core updates (bug fixes, new features)
  • Files in _data/ that changed — new fields, updated defaults
  • Files in public/css/style.css that changed — style updates
  • Files in content/ that changed — new demo content (probably do not apply to your site)
  • Files in Program.cs that changed — engine updates (rare but important)

    • What to ignore:

  • Changes to demo content (content/posts/.md, content/services/.md) — your content is different
  • Changes to README.md — informational only
  • Changes to .gitignore — usually not relevant unless you have custom ignores

    • Step 4: Read the changelog

    If the new version includes a CHANGELOG.md, read it. It describes:

  • What changed
  • Why it changed
  • Whether the change requires action

    • If there is no CHANGELOG.md, the Gumroad email or the README.md summary describes the update.

    Step 5: Bring changes into your project

    For each file that changed and is relevant to your project, apply the change manually:

    For templates/layouts/.dax and templates/partials/.dax:

    1. Open the old and new versions side by side

    2. Identify the specific lines that changed

    3. Apply the change to your project's version

    Example: the new version adds a new field to home/hero.dax:

    Old:

    <h1 class="dax-hero-title">{{ hero.title }}</h1>

    New:

    <h1 class="dax-hero-title">

      {{ hero.title_prefix }} <span class="dax-hero-title-highlight">{{ hero.title_highlight }}</span> {{ hero.title_suffix }}
    

    </h1>

    Do not copy the whole file. Copy only the changed lines. This preserves any customizations you made elsewhere in the file.

    For _data/*.yaml:

    1. Open old and new side by side

    2. Add the new fields to your YAML, with appropriate values for your site

    3. Do not copy the demo values — use your own

    Example: the new version adds a footer.brand_desc field.

    Old:

    copyright: "© 2026 Dax Pro"

    New:

    brand_desc: "A short description for the footer."

    copyright: "© 2026 Dax Pro"

    Apply: add brand_desc to your footer.yaml, with your own text.

    For public/css/style.css:

    This file is the most complex. It has your custom styles and the new version's updates. There are two approaches:

    Approach A — Add the new rules at the end:

    1. Find the new rules in the new style.css (compare old vs new)

    2. Append them to the end of your style.css

    3. Do not touch existing rules

    Approach B — Merge carefully:

    1. For each changed rule, find the corresponding rule in your style.css

    2. Update only the properties that changed

    3. Preserve any custom additions

    Approach A is safer if you have made many custom CSS changes. Approach B is cleaner if you have made few.

    For Program.cs:

    If the engine changed, this is the most sensitive file. Compare the old and new Program.cs line-by-line. If the change is a bug fix or a new feature, copy the relevant method into your file. If the change is a refactor, consider whether you have custom modifications to Program.cs (most sites do not) and if not, replace the whole file.

    Dax Pro does not modify Program.cs in most releases. The engine is stable. Updates to the engine are rare and, when they happen, are documented in the changelog.

    Step 6: Test the update locally

    Before deploying:

    1. Build the updated project:

       cd ~/Projects/dax-pro
    

       dotnet run -- build

    2. Start the development server:

       dotnet run -- start

    3. Open http://localhost:8080/ in a browser

    4. Walk through every page:

    - Homepage — all sections render

    - About, Privacy, Terms, License

    - Services listing and one service detail

    - Blog listing and one post

    - Tags and one tag page

    - Contact form — visible and functional

    - Navigation — works on desktop and mobile

    5. Open DevTools (F12) and check the Console for errors

    6. Run Lighthouse (F12 → Lighthouse tab → Analyze page load) and confirm scores have not dropped

    If something is broken, do not deploy. Diagnose the issue or roll back (see below).

    Step 7: Deploy and verify

    If the local test passes:

    git add .

    git commit -m "Update Dax Pro to v1.1.0"
    

    git push

    Netlify detects the push and rebuilds. When the deploy completes, verify:

    1. Open the live site

    2. Walk through the same pages as local

    3. Check the browser console for errors

    4. Confirm nothing regressed

    If the live site is broken but local was fine, the difference is usually:

  • A file that was not committed — check git status for unstaged changes
  • A build cache issue on Netlify — trigger a cache-clearing rebuild
  • A deployment configuration issue — check the Netlify deploy log

    • Rolling Back an Update

    If the update breaks the site and you cannot fix it quickly:

    Option A — Restore from backup

    If you made a ZIP backup:

    cd ~/Projects

    rm -rf dax-pro
    

    cp -r dax-pro-backup-20260525 dax-pro
    

    cd dax-pro
    

    git add .
    

    git commit -m "Rollback to pre-update version"
    

    git push

    Option B — Restore from Git tag

    If you tagged before updating:

    cd ~/Projects/dax-pro

    git checkout pre-update-v1.1.0
    

    git checkout -b rollback
    

    git add .
    

    git commit -m "Rollback to pre-update version"
    

    git push origin rollback

    Then merge the rollback branch into main via a pull request on GitHub.

    Option C — Roll back the Netlify deploy

    If the source is fine but the deployed version is broken, Netlify can restore a previous deploy without changing the source:

    1. Open Netlify dashboard

    2. Click Deploys

    3. Find the last working deploy (before the update)

    4. Click it

    5. Click Publish deploy (or Restore this deploy)

    The site reverts to the last working version. The source code in Git is unchanged — if you push a new commit, the site jumps to the new state.

    This is a temporary fix, not a permanent rollback. It gives you time to fix the update properly while the site is live.

    A Version Control Strategy That Makes Updates Easy

    The pain of updating comes from not knowing what changed. A good Git workflow eliminates that pain.

    Tag every version you deploy

    When you deploy a version of your site, tag the commit:

    git tag deployed-v1-2026-05-25

    git push origin deployed-v1-2026-05-25

    Tags are immutable snapshots. You can always return to a tag.

    Keep Dax Pro files separate from your files

    If possible, keep the theme files (templates/, _data/ structure, public/css/) close to the original, and put your customizations in a separate layer:

  • Custom CSS — in public/css/custom.css, loaded after style.css
  • Custom templates — in templates/partials/custom/, included from your layouts
  • Custom data — in _data/custom.yaml, separate from the standard files

    • This way, when you update, you can replace templates/, _data/ (except your custom files), and style.css wholesale, and your custom layer remains untouched.

    Dax Pro does not ship with this pattern by default — it assumes you will edit the theme files directly. But if you update frequently, the pattern is worth adopting. It requires:

    1. Creating the custom/ files and folders

    2. Including them from your layouts ({% include custom/section.dax %})

    3. Loading custom.css in base.dax

    Use branches for updates

    Before updating, create a branch:

    git checkout -b update-v1.1.0

    Apply the update on the branch. Test. If it works, merge to main:

    git checkout main

    git merge update-v1.1.0
    

    git push

    If it does not work, discard the branch:

    git checkout main

    git branch -D update-v1.1.0

    Your main branch stays on the working version throughout.

    Keep a changelog

    In CHANGELOG.md in your project, record what you changed and when:

    # Changelog


    v1.1.0 update — 2026-05-25
    


  • Updated Dax Pro from v1.0.0 to v1.1.0
    • 

  • Merged template changes in home/hero.dax and home/trust.dax
    • 

  • Added new fields to footer.yaml (brand_desc)
    • 

  • No changes to Program.cs
    • 

  • Tested on Chrome, Safari, Firefox — no regressions
    • 


    Custom changes — 2026-05-20
    


  • Added "testimonials" section to homepage
    • 

  • Changed brand color from purple to orange
    • 

  • Added custom CSS in public/css/custom.css
    •

    Future updates are easier because you know exactly what changed.

    How Often to Update

    There is no universal answer. It depends on:

    Update immediately when:

  • A release fixes a bug that affects your site
  • A release contains a security patch (rare for static sites)
  • You are actively working on the site and want the latest tooling

    • Update quarterly when:

  • You want to stay roughly current without constant churn
  • You have new features to integrate but no urgency

    • Update annually or never when:

  • The site is stable and you do not want to risk it
  • You have heavily customized the theme and updates are labor-intensive

    • The pragmatic default: update quarterly. Enough to stay current, infrequent enough that each update is worth the effort.

    Do not update on the same day as a release. Wait a few days. If the release has a bug, you benefit from other users finding it first.

    Always update before starting a major new feature. If you are about to add a big section to the homepage, update first — you get the latest tools, and the update is smaller because you have been keeping up.

    What to Do If an Update Breaks Your Customizations

    If you applied the update and your customizations no longer work:

    Example: you added a "testimonials" section to home.dax. After updating, the file has new sections and your testimonials include is in the wrong place.

    Fix:

    1. Re-apply your customization on top of the updated file

    2. Compare your old home.dax (from backup) with the new one

    3. Identify where your {% include home/testimonials.dax %} was

    4. Find the corresponding place in the new home.dax

    5. Add the include there

    This is where the backup saves you. Without it, you lose the record of what you customized. With it, you can compare and re-apply.

    If you forgot to back up:

    1. Check Git history — git log shows every commit

    2. Find the commit before the update

    3. The old home.dax is in that commit: git show :templates/layouts/home.dax

    4. Copy the old version, compare with the new, re-apply your customizations

    Git is a backup. Even if you forgot the ZIP backup, Git has every version you committed.

    What You Have Now

    After this chapter, you can:

  • ✅ Understand how Dax Pro updates are delivered (Gumroad email + library)
  • ✅ Back up your project before updating (ZIP or Git tag)
  • ✅ Download and extract the new version safely
  • ✅ Compare old and new versions with diff, VS Code, or a visual tool
  • ✅ Apply changes file-by-file, preserving your customizations
  • ✅ Test the update locally before deploying
  • ✅ Deploy the update and verify on the live site
  • ✅ Roll back if something breaks (ZIP restore, Git tag, Netlify deploy)
  • ✅ Set up a version control strategy that makes future updates easy
  • ✅ Decide when to update and when to skip

Updates are a maintenance task. They keep your site current without requiring you to start over. The right mindset: updates are investments, not chores. A well-maintained site is a site that stays fast, secure, and easy to extend.

The next chapter is Conclusion — the summary of everything you built, a quick reference index, and the custom .NET and AI services available for teams that need bespoke work.

→ Continue to Conclusion