🌐 Translation: Translated from Korean.

Same Blog, Different Approach: Comparing Plugin-Based vs. Code-Driven Workflows

There are two ways to run a WordPress blog.

One is to leverage the plugin ecosystem. Translate with Polylang Pro, optimize with Yoast SEO, and design with Gutenberg blocks. A few clicks and you’re done—with proven solutions and abundant community support.

The other is to write code yourself. Build a CLI tool in TypeScript, construct a translation system with Claude API, and manage versions with Git. It requires a 2-week investment, but you gain complete control.

After publishing 15 posts over 2 weeks, I compared both approaches. This isn’t about which is “better”—it’s about sharing why different choices make sense.

Comparison 1: Content Creation Environment

Plugin-Centric: Gutenberg + Extensions

WordPress’s Gutenberg editor is more powerful than you might think:

• Reusable Blocks: Save frequently used structures as templates
• Block Patterns: Leverage pre-built layouts
• Keyboard Shortcuts: Insert blocks with / commands, duplicate with Ctrl+Shift+D
• Markdown Plugins: Write in markdown using WP Githuber MD

Pros:

• ✅ Write anywhere with just a browser
• ✅ WYSIWYG real-time preview
• ✅ Integrated media library (drag and drop)
• ✅ Low learning curve

Cons:

• ❌ Browser-dependent (difficult to work offline)
• ❌ Limited version control (WordPress revisions only)
• ❌ No editor choice

Code-Centric: Local Markdown + Git

Developers prefer local file systems:

---
title: "Post Title"
categories: ["Category"]
tags: ["tag1", "tag2"]
---

# Heading

**Bold** *Italic* `code`

![Image](path/to/image.png)

Write in VS Code and:

blog publish my-post.md

Pros:

• ✅ Choose your favorite editor freely (VS Code, Vim, Obsidian)
• ✅ Track all changes with Git
• ✅ Work offline
• ✅ Keyboard-centric (shortcuts, snippets)

Cons:

• ❌ Initial environment setup required (Node.js, CLI tools)
• ❌ No real-time preview (separate tools needed)
• ❌ Image uploads handled separately

Conclusion: Similar Speed, Different Preferences

Writing Speed (2000-word post):

• Gutenberg + reusable blocks: 20-30 minutes
• Markdown + VS Code: 20-30 minutes

Nearly identical. The difference is “where you feel comfortable.”

Comparison 2: Multilingual Translation

Plugin-Centric: Polylang Pro / WPML

WordPress multilingual plugins have a mature ecosystem:

Polylang Pro ($99/year):

• Automatic translation (DeepL, Google Translate integration)
• A few clicks in WordPress admin
• Automatic language switcher generation
• All post type support

WPML ($159/year):

• More powerful automatic translation (DeepL Advanced)
• Integration with plugins like WooCommerce
• Translation management system

Pros:

• ✅ Ready to use immediately (5 minutes after installation)
• ✅ Proven solution (millions of sites using it)
• ✅ Automatic language switcher UI
• ✅ Guaranteed plugin compatibility

Cons:

• ❌ Annual cost ($99-159)
• ❌ Limited translation quality customization
• ❌ Plugin dependency

Code-Centric: Claude API Automated Translation

Developers build their own AI translation system:

blog publish my-post.md  # Publish Korean + auto-translate + publish English

Actual implemented system:

// 1. Call Claude API
const translationResult = await translatePost(content, metadata, {
  targetLang: 'en',
  optimizeSeo: true,
  preserveCodeBlocks: true,
});

// 2. 8-step quality validation
const validationResult = await validateTranslation(
  originalContent,
  translatedContent
);

// 3. Link translations with Polylang
await linkTranslations(koPostId, enPostId);

Pros:

• ✅ Free after initial development (Claude Code free)
• ✅ Fully customizable translation logic
• ✅ 8-step automatic quality validation
• ✅ Automatic SEO optimization (keyword density, title length)

Cons:

• ❌ 2-week initial development investment
• ❌ Self-maintenance required
• ❌ Claude API limitations (timeouts, quotas)

Conclusion: Cost vs. Time Investment Trade-off

Cost Comparison (1-year basis):

• Polylang Pro: $99/year (perpetual payment)
• Claude API: 2-week development time (free afterward)

When is each advantageous?:

• Starting a blog → Plugin (immediate use)
• Long-term operation plan → Code (long-term cost savings)
• Technical capability → Code (customization)
• No technical capability → Plugin (safe choice)

Detailed implementation: See “Building an AI Translation System (Part 3)”

Comparison 3: Quality Management

Plugin-Centric: Yoast SEO + Grammarly

The WordPress ecosystem has abundant quality management plugins:

Yoast SEO (free/paid):

• Real-time SEO analysis (keyword density, title length, meta description)
• Readability checks (sentence length, passive voice, transition words)
• Internal link suggestions
• Social media previews

Grammarly WordPress Plugin:

• Real-time grammar/spelling check
• Tone analysis (formal, casual)
• Clarity suggestions

Broken Link Checker:

• Automatically detects broken links
• Email notifications

Pros:

• ✅ Real-time feedback (instant verification while writing)
• ✅ Easy for beginners
• ✅ Industry-standard validation logic
• ✅ Visual indicators (red/yellow/green)

Cons:

• ❌ Generic solution (limited blog-specific adaptation)
• ❌ Some features paid (Yoast Premium $99/year)
• ❌ English-focused (limited Korean support)

Code-Centric: Custom Validation System

Developers create validation logic tailored to blog characteristics:

// validation.ts
export async function validateTranslation(
  originalContent: string,
  translatedContent: string
): Promise<ValidationResult> {
  const issues: ValidationIssue[] = [];

  // 1. Basic validation
  validateBasics(originalContent, translatedContent);

  // 2. Line count validation (50-150% range)
  validateLineCount(originalContent, translatedContent);

  // 3. SEO keyword validation (based on frontmatter tags)
  validateSeoKeywords(originalMetadata, translatedContent);

  // 4. Title length validation (≤60 characters)
  validateTitleLength(translatedMetadata);

  // 5. Code block preservation validation (100% match)
  // 6. Link structure preservation validation
  // 7. Heading structure preservation validation
  // 8. Metadata completeness validation

  return { isValid, issues, metrics };
}

Pros:

• ✅ Blog-tailored (e.g., 100% code block preservation)
• ✅ Quantitative metrics (line count 8.5%, keyword density 1.2%)
• ✅ Automatic blocking before publication (if validation fails)
• ✅ Both Korean and English support

Cons:

• ❌ Need to develop logic yourself
• ❌ No real-time feedback (only validated at publication)
• ❌ No UI (terminal output)

Conclusion: Generic Solution vs. Specialized Validation

Quality Assurance Level:

• Yoast SEO: 70-80% (generally good)
• Custom validation: 90-95% (blog-specific)

Practicality:

• Most blogs: Yoast SEO is sufficient
• Technical blogs (lots of code): Custom validation advantageous
• Translation blogs: Custom validation necessary

Comparison 4: Handling Repetitive Tasks

Plugin-Centric: Templates + Defaults

WordPress has many features to reduce repetitive tasks:

Gutenberg Reusable Blocks:

• Save frequently used structures as blocks
• Insert with one click

Default Settings:

• Set default category
• Auto-add default tags
• Publication status default (draft/publish)

Autocomplete:

• Suggest existing items when entering categories/tags
• Automatic internal link search

Yoast SEO Templates:

• Meta title variables (%%title%% - %%sitename%%)
• Meta description templates

Pros:

• ✅ Click-based (fast)
• ✅ Visual confirmation
• ✅ Error prevention (dropdown selection)

Cons:

• ❌ UI manipulation needed each time
• ❌ Complex structures difficult to reuse

Code-Centric: Frontmatter + CLI

Developers automate based on file systems:

---
title: "Post Title"
slug: "post-slug"
excerpt: "Post summary"
status: "publish"
categories:
  - "Category1"
  - "Category2"
tags:
  - "Tag1"
  - "Tag2"
  - "Tag3"
language: "ko"
---

Template Copy:

cp templates/blog-post.md content/posts/ko/new-post.md

Zod Schema Validation:

export const PostMetadataSchema = z.object({
  title: z.string().min(1).max(60),
  excerpt: z.string().max(300),
  categories: z.array(z.string()).min(1),
  tags: z.array(z.string()).min(3),
});

Automatic error if required fields missing:

❌ Validation Error: tags must have at least 3 items

Pros:

• ✅ Reuse templates by file copy
• ✅ VS Code autocomplete (existing categories/tags)
• ✅ Version control templates with Git
• ✅ Schema enforces required fields

Cons:

• ❌ Terminal use required
• ❌ Need to learn YAML syntax

Conclusion: UI vs. CLI Preference

Task Time (metadata input):

• WordPress UI: 2-3 minutes (clicking, dropdowns)
• Frontmatter: 1-2 minutes (typing, autocomplete)

Slightly faster but not a huge difference. It’s a “mouse vs. keyboard” preference.

Comparison 5: Version Control

Plugin-Centric: WordPress Revisions

WordPress’s built-in feature for automatic version control:

• Auto-save (every 60 seconds)
• Revision history (unlimited)
• “Restore to previous version” button
• Compare view (diff)

Pros:

• ✅ Automatic (no need to think about it)
• ✅ Easy UI rollback
• ✅ Access anywhere (browser)

Cons:

• ❌ Only stored in WordPress DB (vulnerable to backup loss)
• ❌ Can’t track multiple file changes simultaneously
• ❌ No branch concept (difficult to experiment)
• ❌ Hard to integrate with external collaboration tools

Code-Centric: Git Version Control

Developers want complete control with Git:

# Check edit history
git log --oneline
# d440908 feat: Image generation engine spike
# 7c9b6fb feat: Image strategy benchmark research
# f817df3 fix: English post rendering bug

# Compare changes
git diff HEAD~1

# Revert specific file
git checkout HEAD~1 my-post.md

# Experimental edits (branch)
git checkout -b experiment
# If you don't like it
git checkout main
git branch -D experiment

GitHub/GitLab Remote Backup:

git push origin main

Pros:

• ✅ Precisely track all changes
• ✅ Rollback anytime (file-level, commit-level)
• ✅ Safe experimentation with branches
• ✅ Automatic remote backup to GitHub
• ✅ Collaboration tools (Pull Request, Code Review)

Cons:

• ❌ Need to learn Git
• ❌ Terminal use required
• ❌ Can’t access from browser (local only)

Conclusion: Accessibility vs. Control

Regular bloggers: WordPress revisions are sufficient
Developers: Can’t give up Git’s power

The difference is “how often do you rollback?”:

• Occasionally rollback → WordPress revisions
• Frequently experiment and rollback → Git

When is Each Approach Advantageous?

Plugin-Centric is Advantageous When

✅ You want to start immediately

• Publish first post 5 minutes after signup
• Almost no learning curve

✅ You lack technical capability

• No coding knowledge needed
• Just need to know how to click

✅ You want proven solutions

• Used by millions of sites
• Abundant community support
• Plenty of problem-solving resources

✅ You have budget

• Can invest $100-300 per year
• Time is more valuable than money

Code-Centric is Advantageous When

✅ You want complete control

• Customize all logic
• No plugin constraints

✅ You have long-term operation plans

• Free for life after 2-week initial investment
• Planning 50+ posts

✅ You have technical capability

• Can develop TypeScript, API, CLI
• Familiar with Git, Node.js

✅ You want independence

• No impact from plugin updates
• Minimal impact from WordPress version upgrades
• Store data locally (Markdown)

Objective Comparison Table

Item	Plugin-Centric	Code-Centric	Winner
Learning Curve	Low (1 day)	High (1 week)	Plugin
Initial Cost	Low ($0-100)	High (2 weeks dev)	Plugin
Long-term Cost	High ($100-300/year)	Low (free)	Code
Writing Speed	Fast (20-30 min)	Fast (20-30 min)	Similar
Translation	Immediate ($99-159/year)	2 weeks dev (free)	Trade-off
Quality Management	Real-time (generic)	At publish (custom)	Trade-off
Customization	Limited	Unlimited	Code
Version Control	Basic	Powerful (Git)	Code
Accessibility	Anywhere	Local only	Plugin
Independence	Plugin dependent	Fully independent	Code
Problem Solving	Easy (community)	Difficult (DIY)	Plugin

Conclusion: No Right Answer, It’s a Choice

There’s no single answer to running a WordPress blog.

Plugin-Centric Workflow:

• ✅ Start immediately, proven solutions, low learning curve
• ❌ Paid costs, limited customization, plugin dependency

Code-Centric Workflow:

• ✅ Complete control, independence, long-term cost savings
• ❌ 2-week initial investment, high learning curve, self-maintenance

Selection Criteria

Condition	Plugin	Code
Technical Capability	Low	High
Initial Time	None	2+ weeks
Budget	$100-300/year	Dev time
Post Count Plan	<50 posts	>50 posts
Customization	Limited OK	Essential
Independence	Not important	Very important

Whatever you choose, it’s fine as long as it fits your situation and preferences.

Other Posts in This Series

Specific implementation methods for code-centric workflow:

• Part 1: Project Motivation and Design
• Part 2: WordPress API Integration
• Part 3: Building an AI Translation System
• Part 4: Complete Workflow

Which approach do you prefer?

Are plugins sufficient for you, or do you write code yourself? Share in the comments!

---

Keywords: WordPress, plugin, development, workflow, blog, automation, Polylang, Yoast SEO, Git, markdown