Migrate and contribute
This section has two halves. The guides help you move an existing website into Hatamoto, from WordPress or from another Hatamoto server, and keep every old address working so visitors and search engines never land on a missing page. You need your old site and its admin, and nothing more technical than that.
The reference pages are for developers who want to change Hatamoto itself: build it from source, run the tests, write a safe database change, follow how a release is built and signed, publish plugins through a registry, and update these docs.
Guides
- Move your site
Plan the move of an existing site into Hatamoto, pick the right import and switch over without losing old links.
- Import from WordPress
Copy your WordPress pages, posts, images and menus into Hatamoto from the admin, and check that every old address still works.
- Export and import
Save all of a site's content to one file and rebuild it on a new server, to move hosts or keep a copy of your content.
- Keep old links working
Forward old addresses to their new pages after you move your site, so visitors and search engines never land on a missing page.
- Contributing
Build Hatamoto from source, make a focused change that follows the project rules, run the checks and open a pull request.
Reference
- WordPress importer
Every option of the WordPress import, what it converts, how repeated runs and the address check behave, and its limits.
- Not imported from WordPress
What the WordPress importer leaves behind, such as comments, shops, page-builder layouts, forms, plugin data and themes, and what to do about each.
- Archive format
What a site export archive holds and leaves out, how the file is laid out and the rules an import follows.
- Redirect rules
How the site decides where an old address goes: rule order, wildcards, safety checks, automatic redirects and the WordPress setting.
- Testing
Every test layer and repository check: unit and database tests, pinned output files, the guards, the WordPress fixture and the manual pass.
- Writing migrations
Add a timestamped schema migration that is safe for the previous release, use the contract and backfill markers and run the linter and n-1 check.
- Release process
How a Hatamoto release is tagged, built reproducibly in CI, attested, signed offline, published and rolled out through the stable, edge and canary channels.
- SDK and registry
How the plugin SDK is versioned, how plugin packages are signed and packed, and how to build and host your own signed plugin registry.
- How these docs are made
Where the docs source lives, how pages are written and grouped, the Markdown the publisher accepts, and how to check and publish them.