WordPress, beyond the page builder.

The work behind the interface

My freelance practice grew from building websites into developing custom WordPress themes and plugins. The source archive behind this portfolio includes the JBTheory and JLT themes, a toolbox plugin, custom content types, and template-driven interfaces.

A concrete example: content modeling

The archived JLT Toolbox defines content types and their fields in configuration, then registers them through WordPress hooks. It includes a field-rendering layer and metadata save handlers. This separates the structure of the content from its presentation in a theme.

Content type configuration
  ↳ register_post_type()
  ↳ editor metadata fields
  ↳ theme-specific presentation

The engineering decision

Content that needs to survive a visual redesign belongs outside the theme. Presentation belongs in templates. A reusable field layer reduces repeated setup, but makes that layer a dependency: its validation, permissions, and compatibility need the same attention as the features built on top of it.

What this demonstrates

Working with the WordPress platform itself: PHP, hooks, custom post types, metadata, and front-end templates. It is a different responsibility from configuring a purchased theme, and both kinds of work have a place in my history.

Reading older code honestly

This is a historical code example, not a claim that the archived implementation meets today’s production standards. A modern rebuild would review capability checks, nonce handling, input validation, output escaping, and supported PHP versions before reuse.