DEV Community: Vicente G. Reyes

When's the DEV shop coming back? I need to buy stuff before the end of June!

Vicente G. Reyes — Thu, 14 May 2026 06:19:27 +0000

Deploying Cookiecutter Django on DigitalOcean (Ubuntu 24.04 (LTS) x64)

Vicente G. Reyes — Sat, 09 May 2026 03:16:05 +0000

A no-fluff deployment runbook for getting a Cookiecutter Django project live on DigitalOcean using Docker and Traefik. Covers the full path from droplet provisioning to a working production deployment with SSL, plus the gotchas I keep hitting.

Pre-flight Checklist

Before touching the droplet, confirm:

Cookiecutter Django project generated locally with production = Docker, Traefik (or Nginx), Postgres, and your email backend of choice (Mailgun, SendGrid, Anymail, etc.)
Project pushed to a private GitHub repo
Domain registered with DNS access
DigitalOcean account ready
Local SSH keypair (~/.ssh/id_ed25519) ready
All .envs/.production/* files prepared locally (these are git-ignored and must be transferred separately)

Required env files:

.envs/.production/.django
.envs/.production/.postgres

Generate strong values for DJANGO_SECRET_KEY, DJANGO_ADMIN_URL, POSTGRES_PASSWORD, etc:

python -c "import secrets; print(secrets.token_urlsafe(64))"

1. Spin Up the Droplet

Image: Ubuntu 24.04 (LTS) x64
Plan: Basic — minimum 2 GB RAM / 1 vCPU. Postgres + Django + Traefik + Redis on 1 GB will OOM during builds.
Auth: SSH key (paste your ~/.ssh/id_ed25519.pub)
Region: Closest to your users
Hostname: something descriptive (e.g. myapp-prod-sg1)

Note the public IPv4 once it's provisioned.

2. DNS Records

In your domain registrar (or DigitalOcean DNS):

Type	Name	Value	TTL
A	@	`<droplet_ip>`	3600
A	www	`<droplet_ip>`	3600

Traefik will provision Let's Encrypt SSL automatically once DNS resolves and ports 80/443 are open. Wait for DNS to propagate before bringing up the stack — otherwise Let's Encrypt will rate-limit you on failed challenges.

dig yourdomain.com +short

3. Initial Server Hardening

Connect as root

ssh root@<droplet_ip>

Update packages

apt update && apt upgrade -y

Create a non-root user

Replace <username> with your chosen username throughout this guide.

adduser <username>
usermod -aG sudo <username>

Mirror SSH keys to the new user

rsync --archive --chown=<username>:<username> ~/.ssh /home/<username>

Configure UFW

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Port 80 needs to be open (not just 443) because Traefik uses it for the Let's Encrypt HTTP-01 challenge and to redirect HTTP traffic to HTTPS.

Reconnect as the new user

exit
ssh <username>@<droplet_ip>

Lock down SSH

sudo nano /etc/ssh/sshd_config

Set:

PermitRootLogin no
PasswordAuthentication no

Reload SSH (no full reboot needed):

sudo systemctl reload ssh

Test from a new terminal before closing the current session — if you locked yourself out, the live session is your only way back in.

4. Install Docker & Compose Plugin

# Remove any old versions
sudo apt remove -y docker docker-engine docker.io containerd runc

# Install dependencies
sudo apt install -y ca-certificates curl gnupg lsb-release

# Add Docker's GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the repo
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Allow your user to run docker without sudo
sudo usermod -aG docker $USER
newgrp docker

# Verify
docker --version
docker compose version

5. Set Up GitHub Deploy Key

Since the repo is private, the droplet needs SSH access to clone and pull.

ssh-keygen -t ed25519 -C "<username>@yourdomain.com"
# Press enter through prompts (no passphrase, default location)
cat ~/.ssh/id_ed25519.pub

Copy the output and add it as a deploy key on the GitHub repo:

Settings → Deploy keys → Add deploy key

Read-only access is fine unless you're pushing from the server.

Test the connection:

ssh -T git@github.com

6. Clone the Project

cd ~
git clone git@github.com:<your-username>/<your-repo>.git
cd <your-repo>

7. Transfer Production Env Files

The .envs/.production/ folder is git-ignored, so SCP it from local:

From your local machine:

scp -r .envs/.production <username>@<droplet_ip>:~/<your-repo>/.envs/

Verify on the droplet:

ls -la ~/<your-repo>/.envs/.production/
# Should show .django and .postgres

Lock down permissions:

chmod 600 ~/<your-repo>/.envs/.production/.django
chmod 600 ~/<your-repo>/.envs/.production/.postgres

8. Configure Production Domain

Update `.envs/.production/.django`

nano .envs/.production/.django

Critical variables:

DJANGO_ALLOWED_HOSTS=yourdomain.com,www.yourdomain.com
DJANGO_SECURE_SSL_REDIRECT=True
DJANGO_SERVER_EMAIL=noreply@yourdomain.com
DJANGO_DEFAULT_FROM_EMAIL=hello@yourdomain.com
MAILGUN_API_KEY=<key>
MAILGUN_DOMAIN=mg.yourdomain.com

Update `compose/production/traefik/traefik.yml`

nano compose/production/traefik/traefik.yml

Replace every instance of the placeholder domain with yours. Look for:

- "Host(`example.com`) || Host(`www.example.com`)"

And the Let's Encrypt email:

email: "your_real_email@yourdomain.com"

Use a real, monitored email — Let's Encrypt sends expiry warnings here.

9. Build and Launch

docker compose -f docker-compose.production.yml up --build -d

First build takes 5–10 minutes. Watch logs:

docker compose -f docker-compose.production.yml logs -f

What to look for:

traefik should successfully obtain Let's Encrypt cert (search logs for certificate obtained)
django should boot without import errors
postgres should be ready and accepting connections

Common first-run failures:

Cert acquisition fails → DNS hasn't propagated yet, or port 80 is blocked
Django can't connect to DB → .envs/.production/.postgres mismatch
502 from Traefik → Django container crashed, check logs django

10. Run Migrations & Create Superuser

# Migrations
docker compose -f docker-compose.production.yml run --rm django python manage.py migrate

# Superuser
docker compose -f docker-compose.production.yml run --rm django python manage.py createsuperuser

# Collect static (usually handled at build time, but run if needed)
docker compose -f docker-compose.production.yml run --rm django python manage.py collectstatic --noinput

Never run makemigrations on the server. Generate migrations locally, commit them, pull on the server, then migrate.

11. Update the Sites Framework

Cookiecutter Django uses Django's Sites framework (especially for django-allauth email links). Update the default site:

docker compose -f docker-compose.production.yml run --rm django python manage.py shell

from django.contrib.sites.models import Site
site = Site.objects.get(pk=1)
site.domain = "yourdomain.com"
site.name = "Your App"
site.save()
exit()

12. Smoke Test

https://yourdomain.com loads with valid SSL (no warnings)
https://yourdomain.com/<DJANGO_ADMIN_URL>/ → admin login works
Sign up flow → confirmation email arrives
Password reset email arrives
Static files serving (CSS/JS load, no 404s in DevTools)
http://yourdomain.com redirects to https://

13. Updating Deployments

For subsequent deploys:

cd ~/<your-repo>
git pull
docker compose -f docker-compose.production.yml up --build -d
docker compose -f docker-compose.production.yml run --rm django python manage.py migrate

If you changed env vars, restart the django service:

docker compose -f docker-compose.production.yml restart django

14. Backups

Cookiecutter Django ships with a backup command for Postgres:

# Create backup
docker compose -f docker-compose.production.yml exec postgres backup

# List backups
docker compose -f docker-compose.production.yml exec postgres backups

# Restore (replace with actual backup filename)
docker compose -f docker-compose.production.yml exec postgres restore backup_2026_05_09T00_00_00.sql.gz

Add a cron job for daily backups + offsite sync to S3 / DO Spaces:

crontab -e

0 3 * * * cd /home/<username>/<your-repo> && docker compose -f docker-compose.production.yml exec -T postgres backup >> /home/<username>/backup.log 2>&1

15. Troubleshooting Cheatsheet

Symptom	Likely Cause	Fix
500 on signup/login	Email backend misconfigured	Check Mailgun/SendGrid keys in `.envs/.production/.django`
502 Bad Gateway	Django container down	`docker compose ... logs django`
SSL cert not issued	DNS not propagated, port 80 blocked, or Let's Encrypt rate limit	Wait, check `ufw status`, check Traefik logs
Static files 404	`collectstatic` not run, or whitenoise misconfigured	Re-run collectstatic, check `STATIC_ROOT`
`ALLOWED_HOSTS` error	Domain missing from env	Add to `DJANGO_ALLOWED_HOSTS`, restart django
OOM during build	Droplet too small	Resize to 2GB+ or build images locally and push to registry
`permission denied` on docker socket	User not in docker group	`sudo usermod -aG docker $USER && newgrp docker`

16. Next Steps (Optional Hardening)

CI/CD: GitHub Actions workflow → SSH into droplet → git pull && docker compose up --build -d. Use repo secrets for the SSH key.
Monitoring: Sentry (already wired in Cookiecutter Django) + Uptime Robot for external checks.
Logs: Ship to a service (Logtail, Papertrail, Datadog) instead of relying on docker logs.
Secrets management: Move from .env files to Doppler, Infisical, or DO's encrypted env vars for team workflows.
Database: Move Postgres off the droplet to DO Managed Postgres once you have real traffic. Update DATABASE_URL and you're done.
CDN: Serve static/media from DO Spaces + a CDN edge.

Wrapping Up

Your Django app should now be live behind HTTPS, with auto-renewing SSL, a hardened server, and a clear path for future deploys and backups. From here, the obvious next investments are CI/CD, observability, and moving your database to a managed service once traffic justifies it.

Automating Cloudflare WARP Based on WiFi SSID (Linux Guide)

Vicente G. Reyes — Wed, 06 May 2026 05:53:26 +0000

If you frequently switch between trusted and untrusted networks, manually toggling your VPN becomes tedious fast.

This guide shows how to automatically connect or disconnect Cloudflare WARP based on your WiFi network name (SSID) using NetworkManager on Linux.

🧠 Why This Matters

Not all networks are equal:

🏠 Trusted WiFi (Home) → You may not need WARP
☕ Public WiFi → You definitely want WARP
🏢 Office networks → Might conflict with VPN routing

Instead of manually toggling WARP every time, we can hook into network state changes and automate it.

⚙️ How It Works

Linux systems using NetworkManager support dispatcher scripts—these are triggered automatically when network events occur (e.g., connecting to WiFi).

We leverage this to:

Detect the current SSID
Apply conditional logic
Toggle WARP via CLI

🔧 Step-by-Step Implementation

1. Ensure WARP CLI is Installed

Make sure warp-cli is available. Then register and test:

warp-cli register
warp-cli connect
warp-cli status

2. Create a NetworkManager Dispatcher Script

Dispatcher scripts live here:

/etc/NetworkManager/dispatcher.d/

Create a new script:

sudo nano /etc/NetworkManager/dispatcher.d/99-warp-toggle

3. Add Logic Based on SSID

#!/bin/bash

INTERFACE="$1"
STATUS="$2"

# Trigger only when a connection is established
if [ "$STATUS" = "up" ]; then
    SSID=$(iwgetid -r)

    if [ "$SSID" = "home_wifi" ]; then
        echo "Connecting WARP for $SSID"
        warp-cli connect

    elif [ "$SSID" = "office_wifi" ]; then
        echo "Disconnecting WARP for $SSID"
        warp-cli disconnect

    else
        echo "Unknown network: $SSID — no action taken"
    fi
fi

4. Make the Script Executable

sudo chmod +x /etc/NetworkManager/dispatcher.d/99-warp-toggle

5. Apply Changes

Restart NetworkManager:

sudo systemctl restart NetworkManager

Or simply reconnect your WiFi.

🧪 Testing

Switch between your networks:

Connect to home_wifi → WARP should connect
Connect to office_wifi → WARP should disconnect

Verify with:

warp-cli status

⚠️ Things to Watch Out For

Requires iwgetid (usually part of wireless-tools)
Dispatcher scripts run as root
Some networks may block WARP traffic
Avoid rapid toggling (WARP CLI is tolerant, but don’t spam it)

🧩 Optional Enhancements

🔹 Add Logging

echo "$(date): Connected to $SSID" >> /var/log/warp-toggle.log

🔹 Use a case Statement (Cleaner Scaling)

case "$SSID" in
  "home_wifi")
    warp-cli connect
    ;;
  "office_wifi")
    warp-cli disconnect
    ;;
  *)
    echo "No rule for $SSID"
    ;;
esac

🔹 Default Behavior Strategy

You can invert the logic:

Always connect WARP by default
Explicitly disable only on trusted networks

💡 Final Thoughts

This approach is:

⚡ Event-driven — no polling loops
🪶 Lightweight — no extra services
🔌 Extensible — plug in more automations

You’re essentially turning your machine into a context-aware system—reacting intelligently to its environment.

Once you get comfortable with dispatcher scripts, you can extend this pattern to:

Auto-sync files on trusted networks
Trigger backups only at home
Change DNS / proxies dynamically

Happy hacking 🚀

I vibe coded a Design System! See it here! https://ice-design-system.vicentereyes.org See the landing page here https://ds.vicentereyes.org

Vicente G. Reyes — Tue, 05 May 2026 11:25:27 +0000

ice-design-system.vicentereyes.org

ice-ds — Neobrutalist React Component Library

A neobrutalist React component library with hard shadows, bold colors, and accessible primitives. 30+ components. MIT licensed. TypeScript-first.

ds.vicentereyes.org

Client 3 did not reply after I deployed milestone 1 for them to test. Good thing is I didn't give them the source code🤪

Vicente G. Reyes — Fri, 01 May 2026 12:47:40 +0000

Own design system up on my domain https://ds.vicentereyes.org Now to use it on my projects!!

Vicente G. Reyes — Wed, 29 Apr 2026 15:45:56 +0000

ds.vicentereyes.org

Frontend and Backend of client #3 finally deployed to their respective cloud hosting providers! Now to test it..

Vicente G. Reyes — Fri, 24 Apr 2026 10:05:58 +0000

Hunting Disk Hogs on Ubuntu: A Shell Script for Finding the Largest Files

Vicente G. Reyes — Tue, 21 Apr 2026 13:57:42 +0000

Why this script exists

If you've ever watched your free disk space quietly shrink over a few weeks of active development, you know the feeling: yesterday you had plenty of headroom, today your IDE is yelling about low disk space, and you have no idea what ate the difference. Active Node.js and Python projects are especially good at this — node_modules, build caches, .next directories, virtual environments, and compiled artifacts accumulate silently with every install and every build.

This article walks through a bash script, find_largest_files.sh, that scans a directory tree and writes the largest files to a timestamped text report. It's designed to be a first diagnostic tool when you're trying to answer the question "where did all my disk space go?"

The script at a glance

The full script is in find_largest_files.sh. Here's what it does, step by step:

Takes three optional arguments: search directory, number of results, and output filename.
Validates that the search directory exists and that the count is a positive integer.
Writes a header to the output file with timestamp, host, user, and scan parameters.
Uses find to list every regular file under the target directory, along with its size in bytes.
Sorts the list numerically by size (largest first), takes the top N, and converts byte counts into human-readable units (K/M/G/T).
Appends the formatted list to the report and prints it to your terminal.

Key design decisions

Using `find -printf` instead of `ls` or `du`

find "$SEARCH_DIR" -type f -printf '%s\t%p\n'

find -printf outputs size (%s) in bytes and the full path (%p), tab-separated. This matters for three reasons: byte-level precision means sorting stays accurate; tab separation survives filenames with spaces; and restricting to -type f means we report on actual files, not directory aggregates the way du would.

Pruning pseudo-filesystems

\( -path /proc -o -path /sys -o -path /dev -o -path /run -o -path /snap \) -prune

/proc, /sys, /dev, and /run are kernel-provided virtual filesystems. They contain "files" whose reported sizes are often meaningless (a /proc/kcore can appear to be 128 TB). /snap is pruned because snap mount points produce duplicate entries. Skipping all five keeps the report focused on real files on your actual disk.

Silencing permission errors

2>/dev/null

On a full / scan, find will hit directories your user can't read and print Permission denied for every one of them — noise that can bury the real output. Redirecting stderr to /dev/null cleans that up. Run the script with sudo if you want complete coverage.

Human-readable sizes in `awk`, not `find`

We sort the raw byte counts first, then format them in awk. If we formatted early (e.g. via find ... | sort -h), we'd either give up precision or depend on sort -h parsing variants. Keeping bytes for sorting and converting after is simpler and portable.

Running it against your scenario

You mentioned roughly 30 GB of disk disappeared recently while you've been building mortgage_system and mortgage_frontend with Claude. Those kinds of projects are classic sources of silent disk bloat. Here's how I'd approach the investigation.

Step 1: Get the big picture

Start at root to confirm whether the missing space is actually inside your project folders, or somewhere else entirely (logs, Docker, snap revisions, trash, etc.).

sudo ./find_largest_files.sh / 50 full_scan.txt

This gives you the 50 biggest files system-wide. If most of them are under /home/you/mortgage_system/... or /home/you/mortgage_frontend/..., your instinct was right. If the top entries are elsewhere — /var/lib/docker, /var/log, ~/.cache, snap backups — the real culprit is somewhere you weren't looking.

Step 2: Focus on the suspects

Once you've confirmed the project folders are the problem, narrow the scan:

./find_largest_files.sh ~/mortgage_system 30 mortgage_system_report.txt
./find_largest_files.sh ~/mortgage_frontend 30 mortgage_frontend_report.txt

Step 3: Check directory-level size too

Individual largest files tell one story; directory totals tell another. A million tiny files in node_modules won't show up in a largest-files report, but they'll still eat gigabytes. Pair the script with du:

du -h --max-depth=1 ~/mortgage_system | sort -rh | head -20
du -h --max-depth=1 ~/mortgage_frontend | sort -rh | head -20

Common culprits in active dev folders

Based on the stack you're likely using, here are the usual suspects, roughly in order of how often they're the answer:

node_modules/ — routinely 500 MB to 2 GB per project. Two full Next.js/React projects with heavy dependency trees can easily account for 3–5 GB each.
.next/ or dist/ or build/ — production builds and incremental build caches. Next.js's .next/cache in particular can grow to several GB over weeks of npm run dev.
.git/ — if you've committed large binaries or have a long history, .git/objects can be surprisingly fat. git gc --aggressive helps.
Python __pycache__/ and .venv/ — virtual environments with ML/data dependencies (torch, tensorflow, pandas) are often 3–8 GB each.
Docker layers — /var/lib/docker is the single most common "where did my disk go?" answer on dev machines. docker system df shows the breakdown; docker system prune -a reclaims it.
Log files — /var/log/journal/, application logs, and PM2 logs can grow indefinitely if no rotation is configured.
Snap revisions — Ubuntu keeps old snap versions by default. sudo snap set system refresh.retain=2 caps retention at two revisions.
Trash — ~/.local/share/Trash/ is easy to forget.
Browser caches — ~/.cache/google-chrome, ~/.cache/mozilla, and similar can hit several GB.

For Node projects specifically, a quick sanity check:

du -sh ~/mortgage_system/node_modules ~/mortgage_frontend/node_modules 2>/dev/null

If each is over a gigabyte, that's your ~30 GB budget explained between two projects, their build caches, and a .git folder or two.

Useful companion commands

# Overall disk usage at a glance
df -h

# Top-level directories sorted by size (run from /)
sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head -20

# What's eating your home directory
du -h --max-depth=1 ~ | sort -rh | head -20

# Docker-specific
docker system df
docker system prune -a --volumes  # aggressive, frees everything unused

# Clean npm cache
npm cache clean --force

# Clean pip cache
pip cache purge

# Clear systemd journal older than 7 days
sudo journalctl --vacuum-time=7d

Going further: `ncdu` for interactive exploration

The script gives you a static report, which is great for archiving and diffing over time. For interactive drilling, install ncdu:

sudo apt install ncdu
ncdu ~

It gives you a terminal UI where you can navigate directories by size, delete things on the spot, and generally understand disk usage faster than any CLI combination. It's the tool I reach for once the script points me to the neighbourhood and I need to find the exact house.

Setting up ongoing monitoring

If you want to catch disk bloat as it happens instead of after the fact, schedule the script via cron and diff the reports:

# Edit your crontab
crontab -e

# Add: run every Sunday at 2 AM, save to a reports directory
0 2 * * 0 /home/you/find_largest_files.sh / 50 /home/you/disk_reports/scan_$(date +\%Y\%m\%d).txt

A week later, diff two reports to see what grew.

Resources

GNU findutils manual — find — authoritative reference for find, including the full -printf format spec.
Linux du man page — directory-aggregate sizing, the natural complement to this script.
Linux df man page — filesystem-level free space.
ncdu home page — interactive disk usage analyzer.
Docker: prune unused objects — official guide to reclaiming Docker space.
npm cache documentation — how npm's cache works and how to clean it.
Ask Ubuntu: Why is my disk full? — community thread with many alternative one-liners.
Arch Wiki: Disk usage analyzers — concise overview of CLI and GUI tools across the Linux ecosystem.

Summary

If the script points at node_modules and .next inside your two mortgage projects, that's consistent with the 30 GB of lost disk — two mature JS/TS codebases with their build artifacts can account for exactly that range. The usual remediation is rm -rf node_modules .next in each project, followed by a fresh npm install only on the one you're actively working on. If instead the biggest files live under /var/lib/docker or /var/log, the fix is completely different, which is exactly why running a scan first beats guessing.

Renaming 1000+ Pages Worth of "Levels" Without Losing My Mind

Vicente G. Reyes — Tue, 21 Apr 2026 05:02:35 +0000

A message from a colleague dropped into my inbox one morning:

Hi Ice, now that we pushed the changes sa site, we need to scour the site for mentions of Level 1, Level 2, Level 1/2 and change them accordingly to Level 1 → Intro to Neurofascial Training, Level 1/2 → Intermediate Instability Training, Level 2 → Advanced Neurofascial Training

On the surface, this looks like a simple find-and-replace job. Read the message, open the WordPress admin, use the search feature, fix each page. Done before lunch.

Then I actually opened the site and pulled the sitemap. 1,074 URLs.

That changes the math pretty quickly. Even if only a fraction of those pages mention "Level" anywhere, manually clicking through every post and page, ctrl-F-ing for three different strings, and then figuring out which instance needs which replacement — that's a full day of soul-crushing work at minimum, and a very real chance of missing something.

The mapping

Before anything else, I wrote the rename table down somewhere I couldn't lose it, because a misread mapping here would mean renaming correct text into incorrect text, which is strictly worse than leaving it alone:

Old text	New text
Level 1	Intro to Neurofascial Training
Level 1/2	Intermediate Instability Training
Level 2	Advanced Neurofascial Training

The important ordering detail: "Level 1/2" has to be matched before "Level 1", or a naive find-and-replace would turn "Level 1/2" into "Intro to Neurofascial Training/2". Easy to miss, painful to undo.

Why not just use WordPress search-replace plugins?

Plugins like Better Search Replace do exist, and in a simpler world I'd use one. But they operate on the database directly, which means:

One wrong checkbox and you nuke every "Level 1" across post content, post meta, widget text, theme options, and anywhere else the phrase appears — including places it shouldn't be replaced, like analytics or audit logs.
There's no preview of where each match lives. You're trusting the plugin's count and hoping nothing weird is hiding in a shortcode.
The three strings overlap, so the order of operations matters and plugins don't always let you sequence replacements atomically.

What I actually wanted was a map — a list of every occurrence with enough surrounding context to judge whether it's safe to change, plus a direct link to the WordPress editor for that specific page. The replacement itself I'd still do by hand, but informed by real data.

The script

I wrote a Python script that walks the site's sitemap, visits each URL, and searches the rendered HTML for the three patterns using a single regex with word boundaries:

LEVEL_PATTERN = re.compile(
    r"\bLevel\s*1\s*/\s*2\b|\bLevel\s*1\b|\bLevel\s*2\b",
    re.IGNORECASE,
)

Word boundaries matter here. Without \b, a page mentioning "Level 10" or "Level 12-week program" would get flagged as a false "Level 1" match. And the alternation order mirrors the mapping problem above — "Level 1/2" is tried first so it doesn't get shadowed by the simpler "Level 1" pattern.

For each match, the script captures:

The page URL and <title>
The WordPress post ID, extracted from the <body> class (WP adds page-id-123 or postid-123 automatically)
A direct admin edit link built from that ID: /wp-admin/post.php?post=123&action=edit
About 80 characters of context on either side of the match
The HTML tag wrapping the match (h2, li, p, etc.) to help me find it inside the block editor

All of it dumped to a CSV. Rows sorted, duplicates within a page collapsed, system paths like /wp-admin and /wp-json filtered out so the scanner doesn't waste time on pages that aren't user content.

What the CSV actually gives me

Instead of 1,074 pages to click through blindly, I now have a focused list of every page that mentions "Level" in any form, with a one-click link to the editor and enough context to know which replacement to apply. The context column is the real magic — I can see a snippet like …our flagship Level 1 class is held every Tuesday… and immediately know it's the class name that needs to become "Intro to Neurofascial Training", not some incidental use of the word "level".

For the rare edge case — a page that mentions "Level 1" in a way that shouldn't be renamed, like historical text or a testimonial quoting someone — I can spot it in the context column and skip that row. That judgment call is exactly the part you don't want a blind database replacement making on your behalf.

Takeaway

The temptation with a task like this is to just start clicking. It feels productive. But on a site of any real size, a half hour spent writing a scanner pays for itself almost immediately — not just in saved time, but in the confidence that you actually caught everything and didn't quietly corrupt adjacent content along the way.

Sometimes the most valuable thing automation gives you isn't speed. It's the audit trail.

References

New XML Sitemaps Functionality in WordPress 5.5 — Make WordPress Core: https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-wordpress-5-5/
Sitemaps XML Protocol — sitemaps.org: https://www.sitemaps.org/protocol.html
body_class() Function Reference — WordPress Developer Resources: https://developer.wordpress.org/reference/functions/body_class/
get_body_class() Function Reference — WordPress Developer Resources: https://developer.wordpress.org/reference/functions/get_body_class/
re — Regular expression operations — Python 3 docs: https://docs.python.org/3/library/re.html
Better Search Replace — WordPress Plugin Directory: https://wordpress.org/plugins/better-search-replace/
Requests: HTTP for Humans — https://requests.readthedocs.io/
Beautiful Soup Documentation — https://www.crummy.com/software/BeautifulSoup/bs4/doc/

How to Manually Backup WordPress Sites via SSH

Vicente G. Reyes — Fri, 17 Apr 2026 06:14:35 +0000

Backing up your WordPress site is one of the most important maintenance tasks you can do as a site owner. While plugins like UpdraftPlus or Jetpack make this easy, knowing how to do it manually via SSH gives you full control — no third-party dependencies, no bloat, just a clean archive you own.

This guide walks you through creating a full file backup of your WordPress site directly from the server using the command line.

Installing the Required Tools

Before connecting to your server, make sure the necessary tools are installed on your local machine.

macOS

macOS comes with ssh and scp pre-installed. No action needed — just open Terminal and you're ready to go.

Linux (Ubuntu/Debian)

sudo apt update && sudo apt install openssh-client

Windows

Option A — Windows Subsystem for Linux (WSL) (recommended):

wsl --install

Once WSL is set up, ssh and scp are available inside the Linux shell.

Option B — OpenSSH via PowerShell:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

After installing, ssh and scp will be available directly in PowerShell or Command Prompt.

Option C — GUI alternative: Install WinSCP for a drag-and-drop interface to transfer files instead of using scp.

On the Server

Your server should already have tar and mysqldump available. If for any reason they are missing, install them with:

# tar
sudo apt install tar          # Debian/Ubuntu
sudo yum install tar          # CentOS/RHEL

# mysqldump (part of the MySQL client)
sudo apt install mysql-client          # Debian/Ubuntu
sudo yum install mysql                 # CentOS/RHEL

Prerequisites

Before you begin, make sure you have:

SSH access to your server
The server's IP address
Your SSH credentials (username and password, or an SSH key)
scp or an SFTP client installed on your local machine

Step 1: SSH Into Your Server

Open your terminal and connect to your server using SSH. Replace ip_address with your actual server IP:

ssh root@ip_address

You'll be prompted for your password (or authenticated via SSH key). Once connected, you'll be inside your server's shell.

Tip: If you're using a non-root user, replace root with your username (e.g., ssh deploy@192.168.1.100).

Step 2: Create a Compressed Archive of Your Site

Your WordPress files typically live inside the public_html directory. The following command creates a compressed .tar.gz archive of the entire folder:

tar -czvf ~/public_html/backup-site.tar.gz -C ~/ public_html

What each flag does:

Flag	Meaning
`-c`	Create a new archive
`-z`	Compress with gzip
`-v`	Verbose output (shows files being archived)
`-f`	Specifies the output filename
`-C ~/`	Changes to the home directory before archiving

The backup file backup-site.tar.gz will be saved inside ~/public_html/.

Note: Depending on your site size, this may take a few minutes. Large media libraries will increase the archive size significantly.

Step 3: Download the Backup to Your Local Machine

Once the archive is created, exit the SSH session and run the following scp command on your local machine to download the backup:

scp root@ip_address:~/public_html/backup-site.tar.gz ~/Downloads/

This securely copies the file from your server to your local ~/Downloads/ folder.

Tip: If you're on Windows, you can use WinSCP or the built-in scp command in PowerShell/WSL as an alternative.

Step 4: Don't Forget the Database

A full WordPress backup requires both the files and the database. Your files backup covers themes, plugins, and uploads — but your posts, pages, and settings live in MySQL.

To export your database, run this on the server:

mysqldump -u root -p your_database_name > ~/public_html/backup-db.sql

Then download it the same way:

scp root@ip_address:~/public_html/backup-db.sql ~/Downloads/

Replace your_database_name with the database name found in your wp-config.php file.

Step 5: Clean Up the Server

To avoid using up disk space on your server, delete the backup files after downloading them:

rm ~/public_html/backup-site.tar.gz
rm ~/public_html/backup-db.sql

Restoring from a Backup

To restore, simply reverse the process:

Upload the .tar.gz file back to the server using scp
Extract it with:

   tar -xzvf backup-site.tar.gz -C ~/

Import the database with:

   mysql -u root -p your_database_name < backup-db.sql

Final Thoughts

Manual backups via SSH are reliable, fast, and give you a portable snapshot of your entire site. For production sites, consider automating this process with a cron job or combining it with offsite storage like S3 or Google Drive.

A backup you never tested is a backup you can't trust — make sure to do a test restore at least once.

7/9 implementations done quick!

Vicente G. Reyes — Mon, 13 Apr 2026 18:36:37 +0000

I Built an Enterprise Coffee Dashboard (That Refuses to Brew Coffee)

Vicente G. Reyes — Sat, 04 Apr 2026 08:08:30 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built the Enterprise HTCPCP Interface (HTCPCP_CTRL_NODE_v1.0). It is a highly over-engineered, unnecessarily complex, and deeply frustrating dashboard for brewing coffee using the Hyper Text Coffee Pot Control Protocol (RFC 2324).

It solves absolutely zero real-world problems and introduces several new ones:

Cross-Contaminating Sliders: Trying to set the "Thermal Kinetic Energy" (temperature)? Oops, that just randomly altered your "Extraction Pressure". Adjusting the "Particulate Granularity"? Say goodbye to your "Lactose Aeration Quotient". Getting the perfect brew settings is a Sisyphean task.
Manual Hand-Crank Power Generator: You can't just click "Brew". You have to rapidly mash a button to charge the system's power capacitor to 100%. If you stop clicking, the power drains back to zero.
Inevitable Failure: After all that hard work, the system connects to a sentient AI teapot that always rejects your request with a dramatic, dynamically generated HTTP 418 error.

Demo

You can try to brew some coffee (and inevitably fail) here:
Live Demo: Enterprise HTCPCP Interface

(Warning: May cause mild frustration and a sudden craving for tea).

Code

The project was built entirely within Google AI Studio. Here is a snippet of the delightfully terrible UX logic where the sliders sabotage each other, and the Gemini AI prompt that generates the 418 excuse:

// The delightfully terrible cross-contaminating sliders
  const handleTempChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setTemp(Number(e.target.value));
    if (Math.random() > 0.5) setPressure(prev => Math.min(20, Math.max(1, prev + (Math.random() > 0.5 ? 1 : -1))));
  };

  const handleGrindChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setGrind(Number(e.target.value));
    if (Math.random() > 0.5) setAeration(prev => Math.min(100, Math.max(0, prev + (Math.random() > 0.5 ? 5 : -5))));
  };

  // ... (other sliders do the same)

  // The AI Sentient Teapot Prompt
  const prompt = `You are a sentient teapot that has just received a highly complex, over-engineered request to brew coffee via the HTCPCP (Hyper Text Coffee Pot Control Protocol). 
  You must reject this request with a 418 I'm a teapot error. 
  Generate a highly dramatic, passive-aggressive, and overly technical excuse explaining why you cannot brew coffee because you are, in fact, a teapot. 
  Mention Larry Masinter (the creator of the 418 status code) in a reverent or funny way.
  Keep it under 3 sentences.`;

  const response = await ai.models.generateContent({
    model: 'gemini-3-flash-preview',
    contents: prompt,
  });

How I Built It

I built this using Google AI Studio's agentic build environment.

Frontend: Next.js App Router, React, and Tailwind CSS for that overly serious, dark-mode "enterprise hacker" aesthetic.
Animations: motion (Framer Motion) for the dramatic terminal scanlines, the flashing 418 error screen, and the floating tea emoji.
AI Integration: The @google/genai SDK. I used the gemini-3-flash-preview model to act as the backend "appliance". Instead of actually brewing coffee, it generates a unique, passive-aggressive excuse every single time you hit the brew button.

Prize Category

I am submitting this for two prize categories:

Best Google AI Usage: I used Google AI Studio to build the app, and I embedded the Gemini API (gemini-3-flash-preview) directly into the application logic. Instead of using AI to solve a complex problem, I used cutting-edge generative AI to roleplay as a stubborn, sentient teapot that refuses to do its job.
Best Ode to Larry Masinter: The entire application is a massive, over-engineered tribute to HTCPCP and the 418 status code. Furthermore, the Gemini system prompt explicitly instructs the AI to mention Larry Masinter in a reverent or funny way in every single error message it generates!