Evolving the schema without breaking anything

Everything’s in production and one day you want a new content type — say, «events», with a date, a location and a description. How do you update this without breaking anything or losing what you already have? The answer is in telling apart two things that look the same but aren’t.

Code vs. content

• Defining the «Event» type and its fields is code: it lives in a mu-plugin, in git. You do it once.
• Creating the 12 September event is content: an editor does it in the dashboard. It lives in the database.

Registering the type is a few lines of PHP, always with show_in_rest so it shows up in the API:

<?php
register_post_type( 'evento', array(
  'public'       => true,
  'show_in_rest' => true,      // ← shows up at /wp-json/wp/v2/eventos
  'rest_base'    => 'eventos',
  'supports'     => array( 'title', 'editor', 'excerpt' ),
) );

How that code reaches production

Just as easily as the front end, because it’s in git too. On Hostinger you’ve got three routes, from simplest to most automatic:

1. Git deployment (the recommended one): you connect the repo in hPanel once and then updating is a git push.
2. SFTP: you drag the mu-plugin file to public_html/wp-content/mu-plugins/ with FileZilla. Zero config.
3. Hostinger’s MCP: you connect its official MCP to your agent and manage the hosting by talking to it; ideal for infrastructure tasks.

There are no migrations and no risk to what already exists. You’re only adding capabilities: the same old posts and pages stay intact.

And on the front end

You add the fetch for the new type, its TypeScript types and a route or section. git push to main, the build fires and it appears. When an editor publishes a post of the new type, the webhook rebuilds the front end on its own.

Let your agent evolve it

Add a new content type following the wp-wow skill:
register the custom post type with its custom fields in a mu-plugin
(show_in_rest turned on), and tell me how to deploy it to Hostinger by Git
without touching the existing content.

And with that you’ve got the full cycle: build, serve and grow a headless WordPress without anyone noticing there’s a WordPress behind it. That was all. Now it’s your turn.