NASPO.org¶
naspo.org is part of the website portfolio maintained and supported by Online Services.
Architecture¶
www.naspo.org uses a split frontend/backend architecture.
| Layer | Verified details |
|---|---|
| Public frontend | Next.js on Vercel |
| Vercel project | naspo |
| Production branch | main |
| Production domain | www.naspo.org |
| Frontend GitHub repository | NASPO-ValuePoint/naspo |
| Canonical local frontend path | ~/Sites/naspo/naspo.org |
| Production WordPress backend | https://cms.naspo.org |
| Production backend host | AWS Lightsail instance naspo-cms-production |
| Production backend public IP | 3.239.201.168 |
| Production backend platform | Bitnami WordPress |
| Production WordPress root | /opt/bitnami/wordpress |
The WordPress backend remains the source of wp_mail()-based transactional mail. Mail transport changes for WordPress-generated email belong on the WordPress backend, not in the Vercel/Next.js frontend.
The Vercel frontend must not receive:
- SendGrid API credentials
- NASPO Secure Mail HMAC secrets
- WordPress backend-only mail configuration
For the shared cross-site reference, see Cross-Site Architecture and Deployment.
Deployment Boundaries¶
The frontend deployment and the WordPress backend deployment are separate concerns.
Frontend deployment is currently verified as Vercel project naspo, production source branch main, and production domain www.naspo.org.
The production CMS database URLs are:
| Setting | Value |
|---|---|
home |
https://cms.naspo.org |
siteurl |
https://cms.naspo.org |
FRONTEND_SITE_URL |
https://www.naspo.org |
Unknown/TODO: confirm the production WordPress backend repository status if any, plugin management workflow, and deployment process.
Staging¶
NASPO staging is separate from production.
| Layer | Verified details |
|---|---|
| Public staging frontend | https://sandbox.naspo.org |
| Staging frontend repository | NASPO-ValuePoint/naspo-staging |
| Staging WordPress host | NASPO-STAGING |
| Staging WordPress public IP | 44.197.170.249 |
| Staging WordPress platform | Bitnami WordPress |
| Staging WordPress root | /opt/bitnami/wordpress |
Staging uses its own NASPO Secure Mail identity and the staging gateway. Do not query the production gateway for the staging identity, or the staging gateway for the production identity. The expected result for the wrong gateway environment is unknown_site.
Transactional Mail¶
WordPress-generated mail should be evaluated from the WordPress backend because WordPress calls wp_mail().
Do not place SendGrid credentials, NASPO Secure Mail HMAC secrets, or backend-only mail settings in Vercel.
Status last verified August 12, 2026:
- NASPO Secure Mail
0.1.0is active in production. - WP Mail SMTP
4.9.0is inactive and remains installed as a rollback path during the proof window. - NASPO Secure Mail is now the production
wp_mail()transport.
Production Secure Mail configuration:
| Setting | Value |
|---|---|
| Gateway identity | naspo-org-wordpress-prod |
| Gateway endpoint | https://naspo-mail-gateway.naspo.workers.dev/v1/mail |
| Protected config file | /opt/naspo/secure-mail/naspo-org-wordpress-prod.php |
| Config directory permissions | root:daemon 750 |
| Config file permissions | root:daemon 640 |
| Delivery mode | send |
| Allowed From | webmaster@naspo.org |
| Default From | NASPO, webmaster@naspo.org |
| Max recipients | 50 |
| Max payload | 10 MiB |
| Rate limit | 60 per minute, 600 per hour |
| SendGrid sandbox | false |
The protected config contains the NASPO Secure Mail site ID, gateway URL, HMAC secret, timeout, and attachment limit. Do not document the secret value.
Staging Secure Mail configuration:
| Setting | Value |
|---|---|
| Gateway identity | naspo-org-wordpress-staging |
| Gateway endpoint | https://naspo-mail-gateway-staging.naspo.workers.dev/v1/mail |
| Protected config file | /opt/naspo/secure-mail/naspo-org-wordpress-staging.php |
| Delivery mode | redirect |
| Allowed From | webmaster@naspo.org |
| Default From | NASPO, webmaster@naspo.org |
| Max recipients | 25 |
| Max payload | 10 MiB |
| Rate limit | 30 per minute, 300 per hour |
Staging redirects mail to a controlled NASPO operator inbox rather than sending to original production recipients.
Contact Forms¶
Production Contact Form 7 forms inspected August 12, 2026 use webmaster@naspo.org as the mail From identity:
| Form | Title | Recipient | From | Reply-To |
|---|---|---|---|---|
5 |
Contact Form | [department_email], headquarters@naspo.org |
[_site_title], webmaster@naspo.org |
[email] |
4358 |
State contact form | [_site_admin_email] |
[_site_title], webmaster@naspo.org |
[email] |
9678 |
George Cronin Awards Form | NASPO staff recipients configured in CF7 | [_site_title], webmaster@naspo.org |
[email] |
Submitted visitor addresses should remain Reply-To values. Do not use submitted addresses as the actual From identity.
Confirmed production Vercel endpoint model:
| Variable | Target |
|---|---|
NEXT_PUBLIC_NEXTJS_SITE_URL |
https://www.naspo.org |
NEXT_PUBLIC_NEXTJS_CANONICAL_URL |
https://www.naspo.org |
NEXT_PUBLIC_WORDPRESS_SITE_URL |
https://cms.naspo.org |
CONTACT_FORM_POST_ENDPOINT |
https://cms.naspo.org/wp-json/contact-form-7/v1/contact-forms/5/feedback |
STATE_CONTACT_FORM_POST_ENDPOINT |
https://cms.naspo.org/wp-json/contact-form-7/v1/contact-forms/4358/feedback |
GEORGE_CRONIN_AWARDS_FORM_POST_ENDPOINT |
https://cms.naspo.org/wp-json/contact-form-7/v1/contact-forms/9678/feedback |
Production uses the matching production Cloudflare Turnstile site and secret pair for www.naspo.org. Do not document secret values.
Mail Validation¶
Production Secure Mail was validated end to end on August 12, 2026:
- A controlled
wp_mail()test fromnaspo-cms-productionreturnedtrue, produced production gatewaymail_sent, and was received. - A real submission through
https://www.naspo.org/contact/reached the public frontend thank-you state. - The contact submission produced production gateway
mail_sentfornaspo-org-wordpress-prod. - SendGrid recorded the contact-form message to
headquarters@naspo.orgas delivered fromwebmaster@naspo.org. - A WordPress account-reset email was received from
NASPO,webmaster@naspo.org.
This proves both core WordPress transactional mail and the production contact-form path through the Vercel frontend, Turnstile validation, cms.naspo.org CF7 endpoint, WordPress wp_mail(), NASPO Secure Mail, production gateway, SendGrid, and recipient inbox.
Known Issues and Follow-Up¶
- Received NASPO account-reset email displayed HTML source literally in Outlook. Delivery succeeded; do not treat this as a Secure Mail delivery failure. Root cause is not yet confirmed.
- WP-CLI on
naspo-cms-productionemits an invalidmemory_limitwarning for1024MB. The warning did not block configuration loading, plugin activation/deactivation,wp_mail(), or production delivery. - Browser-validation failures can occur when stale or mismatched Turnstile state is present in the browser. Check the frontend validation layer before treating that symptom as a mail-gateway failure.
- The contact and state-contact API routes log safe Contact Form 7 diagnostic metadata, including promise status, HTTP status, CF7 status, CF7 message, target
into, and invalid-field count. They should not log submitted names, email addresses, message bodies, Turnstile tokens, or full payloads. - The
naspo-stagingfrontend Vercel install failure was resolved August 12, 2026 by pinningsharpto0.33.5and regenerating the Yarn 1 lockfile to use npm-hosted@img/sharp-*and@img/sharp-libvips-*packages. The fix did not change Next.js, React, runtime behavior, application behavior, or Vercel environment settings.
Rollback¶
During the proof window:
- Deactivate NASPO Secure Mail.
- Reactivate WP Mail SMTP only if its configuration remains valid.
- Confirm plugin states.
- Send a controlled
wp_mail()test. - Preserve gateway request IDs and WordPress
wp_mail_failedentries for troubleshooting.
Do not delete WP Mail SMTP yet. The protected Secure Mail configuration and gateway identity do not need to be destroyed for a temporary transport rollback.
Documentation to Capture¶
Add validated information here as it is discovered, including:
- WordPress backend hosting and environments
- WordPress backend repository and deployment workflow, if any
- Cloudflare and DNS configuration
- Third-party integrations
- Analytics and tag management
- SEO and AI-search implementation
- Accessibility practices
- Runbooks and known issues
Link to shared procedures rather than duplicating them when a process applies to multiple sites.