Who
I needed a place to version the SalesPromis production site — the WordPress tree that actually ran the SSDI qualify funnels on WP Engine.
Who this write-up is for: operators who still have a private “production site” repo months after the public domain moved stack; builders who want to see how thin the custom layer is under an Elementor + Salert + HurryTimer kit; anyone who has ever opened GitHub expecting the live frontend and found a wp-content dump instead.
What
I keep HurleyUS/SalesPromis private. README line one: SalesPromis! Production Site. Line three: “This is the production site for SalesPromis!”
What the tree actually is: a WordPress wp-content-only dump. Core, wp-admin, uploads, and wp-config.php are gitignored. Tracked: 7,723 files. GitHub disk ~36 MB. Linguist calls primary language JavaScript because Elementor’s JS weight wins — PHP is still ~16 MB of bytes.
Builder stack from the plugins directory: Elementor 3.21.8, Elementor Pro, Dynamic Content for Elementor (~45M on disk alone), Hello Elementor 3.0.2, child theme hello-theme-child-master 2.0.0. Host signals: WP Engine object-cache.php (Memcached Redux) + wpe-cache-plugin mu-plugin + force-strong-passwords. Also in the kit: Really Simple SSL, Redirection, MonsterInsights, SVG Support, Admin Site Enhancements, HurryTimer, Salert 1.2.5.
Custom operator code is small. functions.php enqueues ssdi-qualify.js only when the request is an Elementor e-landing-page whose permalink contains ssdi-qualify. The script (~294 lines) floors .elementor-countdown-minutes so the timer does not fall below 05, prepends random faces from 100k-faces.glitch.me into Salert wrappers, and renders two randomized “Qualify SSDI” testimonial cards (hardcoded first-name quotes + five-star glyphs) into Elementor widget data-id="8c4d0c4". Salert’s own plugin header says it generates fake sales notifications.
There is no package.json. There is a 303-line .cursor/rules/STRIPE.md (“How I Stay Sane Implementing Stripe”) with zero Stripe usage in the PHP/JS app tree.
Where
Code: github.com/HurleyUS/SalesPromis — private, org HurleyUS, default branch main, empty GitHub description and homepage fields. Local Projects checkout on m1Pro13 still lists origin michaelmonetized/SalesPromis; Brain _src tracks HurleyUS/SalesPromis. Same HEAD.
Live domain: www.salespromis.com — HTTP 200, Cloudflare, title SalesPromis | AI-Powered Lead Generation - Pay Per Result. HTML at pack time loads Vite-hashed /assets/index-*.js|css and /lovable-uploads/…. That is a Lovable SPA, not this WordPress tree. Canonical points at https://www.salespromis.com/. Portal copy elsewhere references a Tronador login — outside this repo.
Audience sits next to every client lead-gen site that got rebuilt on a new host while the old wp-content dump stayed the Git source of truth.
When
2024-08-15 15:48 ET — init by Michael Monetized. Full dump: plugins, themes, mu-plugins, icons, GPL-3 LICENSE.md, three-line README.
2026-01-31 05:37 ET — chore: sync all changes. Diff is one file: .cursor/rules/STRIPE.md (+303). That is HEAD c543864. GitHub pushed_at 2026-01-31T10:39:16Z.
Two commits. Seventeen months between them. No Elementor upgrade commit in git history after init — whatever changed on the server between those dates did not land as a second content sync.
Why
Because a private wp-content dump is still useful as an artifact of the Elementor funnel even after the marketing domain moves — as long as you do not pretend the dump is still the live renderer.
Because the custom surface that mattered for the SSDI qualify landing page was one child-theme script and an enqueue gate, not the 45 MB Dynamic Content plugin folder.
Because the HEAD commit is a perfect operator scar: I synced a Stripe sanity rule into a WordPress lead-gen dump that never charged a card in-tree.
Engagement Q: When the README still says “production site” and the live HTML loads Lovable assets — which one should the content factory treat as the product under review?