KJP Data Pipeline & Infrastructure Plan

Created: 2026-03-18 Triggered by: Casey Kurz bug report — taxonomy changes from Google Sheet not reflecting on site


Root Cause (Confirmed)

WP All Import last ran 2026-02-10. The external nightly cron that triggers it is not firing. All taxonomy updates made in the Google Sheet since then have not reached WordPress.

The current client-reported issue (photos showing under both "Interpretations" AND "Filters"): - 38 posts still have the type taxonomy term "Interpretations" - An unknown taxonomy update added them as "filter" tags separately - FacetWP shows both because both exist in the DB — the import was never re-run to reconcile


Phase 1: Immediate Fix

1a. Identify the broken cron

1b. Fix the taxonomy issue on production

Two options: - Option A (rename): Rename the "Interpretations" term to "Filters" in the type taxonomy — fastest, no import needed - Option B (run import): Re-run Photo Import (ID 10) on production with the updated spreadsheet. Requires confirming the spreadsheet's type column now reads "Filters" instead of "Interpretations", and that WP All Import's taxonomy update mode is set to REPLACE (not append)

Recommend starting with Option A to fix the immediate display issue, then re-run the import after confirming the cron is fixed.

Production WP-CLI for Option A:

ssh kurtjohnsonphotographycom@34.162.230.19 -p 61436 \
  "wp --path=/www/kurtjohnsonphotographycom_376/public term update type interpretations --name='Filters' --slug='filters'"

1c. Reindex FacetWP on production

After taxonomy fix:

ssh kurtjohnsonphotographycom@34.162.230.19 -p 61436 \
  "wp --path=/www/kurtjohnsonphotographycom_376/public facetwp index"

Phase 2: Cron Infrastructure Fix

Goal

Reliable nightly import that pulls from Google Sheets → updates WordPress taxonomy, content, and metadata → triggers FacetWP reindex.

Options

Option A: Fix the existing external cron service - Find out what service it is and why it stopped - Update the endpoint URL if it changed - Add monitoring/alerting so we know if it fails

Option B: Kinsta Scheduled Tasks (preferred) - MyKinsta supports server-level cron via the "Scheduled Tasks" feature - Set up a cron to run: wp all-import run 10,9 on a nightly schedule - More reliable than external ping-based cron — runs inside the server

Option C: WP-Cron + Action Scheduler - Register the WP All Import run as a WordPress scheduled event - Less reliable (WP cron is traffic-dependent) but simpler to set up

Option D: DevKinsta local cron for testing - No DevKinsta CLI exists — but macOS crontab can call Docker exec commands - Useful for testing import runs locally before pushing to production

  1. Check if Kinsta Scheduled Tasks can replace the external service
  2. Set up wp all-import run 10,9 as a nightly Kinsta cron (midnight CDT)
  3. Add a post-import FacetWP reindex step (already handled per-post by pmxi_saved_post hook, but a full reindex after the batch is cleaner)

Phase 3: Documentation & Architecture

Completed

To do


Open Questions for Eric

  1. What is the cron service? Where is it configured?
  2. What is "WP OnPort"?
  3. Does a staging environment exist on Kinsta?
  4. Was the Google Sheet actually updated with "Filters" (or just the Casey's local copy)?
  5. Should we rename "Interpretations" → "Filters" immediately, or wait and let the import fix it?