mcpField
C
codebase-to-wordpress-converter

codebase-to-wordpress-converter

github.com/sickn33Development48.7k57 installsUpdated today
Repository

About codebase-to-wordpress-converter

A skill for converting static or React-based frontends into editable WordPress themes while auditing visual structure and technical SEO. Its phased process separates comparison, audit, risk-classified planning, and incremental fixes with validation.

Key features

  1. 01Phased UI comparison and audit
  2. 02React and HTML content field mapping
  3. 03WordPress hooks and dynamic navigation
  4. 04SEO and CMS editability checks
  5. 05Incremental fixes with validation

Use cases

  1. 01Converting a React frontend into a WordPress theme
  2. 02Migrating a static HTML project to WordPress
  3. 03Auditing an existing conversion for SEO issues
  4. 04Tracking UI differences before making fixes

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill codebase-to-wordpress-converter

After installing, type/codebase-to-wordpress-converterin Claude Code to confirm it loaded.

Details

From the project README

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:

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

Use these as visual-parity goals. Security, valid markup and accessible navigation may require a documented structural change; report that tradeoff instead of promising impossible parity:

  • 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 esc_url( 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: Build Tailwind through the project asset pipeline and enqueue compiled CSS with WordPress hooks; do not rely on a runtime Tailwind configuration in header.php. Escape dynamic text, attributes and URLs for their output context; preserve intended rich content through approved WordPress filters.
  • ❌ 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.

Comments

Markdown supported