Bilingual corporate portal with measured security and accessibility
I rebuilt a power generation company's website from scratch, with 134 pages in Spanish and English on custom WordPress, deployments with automatic rollback and an external penetration test that closed with 3 low-severity findings.
Project facts
- Role
- Full-stack developer and technical lead, from design extraction to production sign-off
- Period
- Jul 2026 to Sep 2026
- Public links
- Live site(opens in a new tab)
134
published pages, 67 in Spanish and 67 in English generated from a single sourceSource: Production acceptance record, September 2026 3 low
findings from the external penetration test, with no critical, high or medium onesSource: External audit firm report, September 2026 96 of 99
server hardening controls passing; the remaining 3 depended on third partiesSource: Project hardening test harness, 2026 2,211
commits to the portal in about 8 weeks of workSource: Git history, July to September 2026
The problem
The previous site was four separate WordPress installations, one per language and domain, hosted by a third party. Content was outdated, the English version was not maintained, and the site did not meet Colombian transparency (Law 1712 of 2014) or accessibility (Resolution 1519 of 2020) requirements.
My role
- Extracted the Figma design and the old site's content with my own tools, and replicated them page by page.
- Built the block theme, two plugins and the engine that generates the English pages.
- Wrote the server provisioning, the deployment and the hardening harness, and coordinated certificates, DNS and the web application firewall with the infrastructure team.
- Drove an internal security audit with more than 100 findings to closure and supported the external penetration test.
- Prepared the production acceptance record, with 9 test cases and 35 pieces of evidence, generated by code.
Constraints
- The communications team edits content without a developer and without being able to break the design.
- Mandatory transparency and WCAG 2.2 AA accessibility compliance for a public website.
- Company-owned infrastructure, behind a corporate web application firewall.
- Self-hosted fonts and assets, with no third-party services collecting visitor data.
- Zero broken links during the migration, because the old addresses had to keep working.
Decisions
- 01
Git as the single source of truth
The WordPress admin only edits content. Block structure is locked, and the menu and the route table live in the repository and are seeded with idempotent scripts.
Ruled out
- Configure the site from the admin panel
- 02
An in-house engine for the English version
The 67 English pages are generated from the Spanish ones with a per-page translation catalog, so the structure is identical and a guard prevents publishing a half-done translation.
Ruled out
- A multilingual plugin with pages duplicated by hand
- 03
Reproducible deployments with automatic rollback
Each deployment packages an exact commit with its checksum, runs validations, backs up the database, switches versions atomically and rolls back on its own if verification fails. It rolled back 4 times in production with no downtime.
Ruled out
- Upload files over FTP or edit on the server
- 04
A content security policy measured with a browser
The CSP was built by crawling 137 routes at two widths with a real browser until there were zero violations, instead of guessing which resources each page uses.
Ruled out
- Copy a generic CSP and loosen it every time something broke
Architecture
Sources
- Figma designExtracted through the API, frame by frame
- Git repositoryTheme, plugins, routes and menu
- Communications teamEdits content only
Delivery
- Verified deploymentChecksum, validations, backup and rollback
Server
- WordPress with a custom block themePHP, 67 pages per language
- English engineGenerates the English pages
- MariaDBReachable only from the server
Services
- Headless CMSCommercial data tables, queried server-side
- Document storageS3-compatible
Visitors
- Site visitorsSpanish and English, WCAG 2.2 AA
How data moves
- Figma designtoGit repositoryReplicated design and tokens
- Git repositorytoVerified deploymentExact commit
- Verified deploymenttoWordPress with a custom block themeAtomic version switch
- Communications teamtoWordPress with a custom block themeContent
- WordPress with a custom block themetoMariaDBContent and settings
- Headless CMStoWordPress with a custom block themeData with cache and fallback
- WordPress with a custom block themetoEnglish engineSpanish HTML
- English enginetoSite visitorsEnglish pages
- WordPress with a custom block themetoSite visitorsSpanish pages
- Document storagetoSite visitorsRegulatory documents
Results
- The site went to production with an acceptance record signed by the business and technology areas, after 9 test cases run against production.
- All 76 legacy addresses redirect with a 301 and no link was left broken.
- The communications team publishes and updates content without depending on a developer.
- The site was verified at 27 screen widths, from 360 to 1,920 px, and accessibility issues were tracked in a log with measurements and their fixes.
What I would do differently
- I would set up the security harness and the CSP measurement in the first week; much of the closing work came from checks that could have been automated earlier.
- I would ask for a test environment with the same network and firewall as production from the start, so those differences do not surface at the finish line.
Technologies
- WordPress
- PHP
- Python
- Bash
- MariaDB
- Directus
- WCAG 2.2
- Playwright
- nginx
- Linux