Codebase to WordPress Converter

Overview

This skill is designed for the high-fidelity conversion of static or React-based frontends into fully functional, CMS-driven WordPress themes. It acts as a Senior WordPress Architect, React Expert, and QA Engineer to ensure a 100% pixel-perfect match while integrating deep WordPress functionality like ACF, dynamic menus, and technical SEO preservation.

When to Use This Skill

Use when converting a React (CRA/Vite/Next.js) or HTML project into a WordPress theme.
Use when the client demands a 100% pixel-perfect match with the original source.
Use when auditing an existing WordPress conversion for structural or SEO flaws.
Use when you need to ensure technical SEO (Schema, Meta tags, Heading hierarchy) is preserved exactly.

Core Capabilities

Phased Conversion & Audit

The skill follows a strict 4-phase forensic process:

Phase 1: Forensic UI Comparison: Side-by-side table audit of React components vs. WordPress templates to find discrepancies.
Phase 2: Full Audit: Deep dive into UI, SEO, CMS Editability, Navigation, Functionality, and Performance.
Phase 3: Action Plan: Tasks classified as SAFE, RISKY, or BLOCKED to prevent breaking the UI.
Phase 4: Iterative Fixing: Executing one safe task at a time with validation after each step.

Absolute UI Lock

Strict enforcement of non-negotiable rules:

No alterations to layout, spacing, typography, or colors.
Exact preservation of Tailwind or CSS class names.
Zero changes to DOM structure or HTML nesting.

Step-by-Step Guide

1. Discovery & Forensic Audit

Start by identifying all components in the source code. Create a UI Comparison table comparing the original source output against the target WordPress output.

Rule: No fixes are allowed during this phase; only detection.

2. Strategic Field Mapping

Map static React/HTML content to dynamic WordPress functions:

Replace static text with the_title(), get_field(), or the_content().
Replace static paths with get_template_directory_uri().

3. Implementation of Core Hooks

Ensure every theme includes the foundational WordPress hooks correctly:

Layout Files (header.php / footer.php): Must include wp_head() before </head> and wp_footer() before </body>.
Page Templates: Must call get_header() and get_footer().
register_nav_menus() for dynamic navigation without breaking original HTML structure.

4. Validation & Live Tracker

Maintain a live tracker of Total Issues, Fixed, and Remaining. Every fix must be followed by a confirmation:

✅ No UI change
✅ No DOM change
✅ No class change

Examples

Example 1: Navigation Conversion

// WRONG: Static replacement that adds wrappers
wp_nav_menu(['theme_location' => 'primary']);

// CORRECT: Preserving original Tailwind classes and structure
wp_nav_menu([
    'theme_location' => 'primary',
    'container' => false,
    'items_wrap' => '<ul class="flex space-x-8">%3$s</ul>',
    'walker' => new Custom_Tailwind_Walker()
]);

Example 2: Asset Pathing

// Source: <img src="/images/logo.png" />
// WP Conversion:
<img src="<?php echo get_template_directory_uri(); ?>/assets/images/logo.png" alt="Logo" />

Best Practices

✅ Do: Use get_page_by_path() for robust internal linking.
✅ Do: Implement ACF (Advanced Custom Fields) fallbacks in functions.php.
✅ Do: Keep the Tailwind configuration in the header.php to ensure global styles are active.
❌ Don't: Add "div" wrappers or rename classes to "clean up" the code.
❌ Don't: Use standard WordPress default styles if they conflict with the original design.

Additional Resources

Limitations

Use this skill only when the task clearly matches the scope described above.
Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

codebase-to-wordpress-converter