Import and export
Transfers are scoped to the selected website. They do not silently create a destination website and do not move installation-wide administrators, SMTP credentials, Redis passwords, API tokens, or full-product secrets.
WordPress
In WordPress, open Tools → Export and download the WXR XML file. In DynoStatic, select the destination website and open Import / Export in that website rail. No destination widget is required.
Use Import a WordPress website to create CMS collections and entries from posts, pages, and supported custom post types and to create website discussions from WordPress comments. DynoStatic detects the source address, language, content types, hierarchy, moderation state, and publication state. You can import all CMS entries as drafts, and you can override the source address when a local WordPress URL such as http://127.0.0.1:4321/ needs a deliberate durable migration identity. The job advances in bounded resumable requests and remains available on the transfer page if the browser closes.
Alternatively, use Connect directly to WordPress with an HTTPS WordPress address, username, and a dedicated Application Password. DynoStatic discovers the standard /wp-json/ endpoint and the official query-based REST fallback, admits only simple wp/v2 content collections on the confirmed origin, and reads at most one bounded REST page per source step. Keep the tab open for automatic continuation. If it closes during source reading, return to the durable job and re-enter the username and Application Password. The Application Password is never stored in the job, stage records, logs, backup, URL, or returned HTML; the login is not saved as an access setting, although ordinary author metadata returned by WordPress may contain the same public name or slug. After source reading, normalization and local website application resume without WordPress credentials. WordPress creates dedicated Application Passwords under Users → Profile → Application Passwords.
Both source workflows retain author and taxonomy context on content and import comments into the website-wide discussion corpus; a Comments widget is not required. Comment email addresses are encrypted, source IP fields are discarded, nested replies and WordPress moderation state are preserved, and repeated WXR/REST imports converge on the same comments. Standalone author and term records remain references. Attachments enter the Content media library as unavailable WordPress references without downloading their bytes during import. The older Import discussions → WordPress WXR/XML path remains available when an operator deliberately wants comments without CMS content.
In Content → Media, choose Verify WordPress source when you are ready for DynoStatic to fetch one attachment. Verification accepts only a public standard-port HTTPS source, follows no redirects, bounds the response to 25 MiB, and measures the actual allowed MIME, size, dimensions, and SHA-256 before the asset becomes usable. A verified WordPress source can remain remote. You can instead choose Copy to this server and retain the WordPress reference, Copy here, retire reference, or later Retire WordPress reference after a verified server original exists. Retiring a reference stops DynoStatic from using that source; it does not delete the provider's file. These choices do not rewrite content references or change the stable media ID. Failed verification leaves the reference unavailable and safe to retry.
The parsers stream XML instead of loading an arbitrary upload into memory. PHP upload/post limits and the web server's matching request-body limit still apply.
Drupal and Joomla
For Drupal, open the selected website's Import / Export page and enter the
HTTPS Drupal address. Choose public, Basic, or bearer-token access, preview the
exact JSON:API collections, then select the node, file, taxonomy-term, and user collections that apply.
Credentials are re-entered only while Drupal pages are being read and are never
stored. Nodes become CMS entries; same-origin file records become unavailable
media references pending explicit verification. Selected taxonomy terms and users
resolve node taxonomy and author labels without creating standalone local accounts
or taxonomy objects; private account fields are not imported. Other selected
entities are kept as explicit reference-only results. A valid node langcode
becomes the entry locale; missing or invalid language facts use the locale chosen
for the import, with invalid values reported as warnings.
For Joomla 4/5, enter the HTTPS website and normally use a Joomla API token.
DynoStatic verifies the documented core articles route under
/api/index.php/v1 and independently probes the fixed categories, tags, and
users support routes. Every selected route is verified again when the job starts,
then read one bounded page at a time. Use the advanced API-root field only when
Joomla is installed under a different same-origin path. Article text, publication
state, language, dates, featured state, resolved category/tag/author labels,
custom fields, and image metadata become CMS content facts. Categories, tags,
and users remain reference-only and do not create standalone local objects;
private account fields are not imported. Menus and modules are not imported.
Joomla language tags become canonical entry locales; the language-neutral *
value and missing or invalid tags use the locale chosen for the import. One
imported content type can therefore contain multiple editable locale variants,
and its Blueprint locale set expands safely when a later import introduces a
new source language. Image bytes are not downloaded while the Joomla content
job runs.
Drupal and Joomla API credentials are request-only. Closing the browser during source reading leaves a resumable job that asks for the same access again; credential-free local normalization/application can continue automatically. Both readers require standard-port HTTPS, reject redirects and private network targets, and never accept direct source database credentials.
After either import, Content → Media offers the same custody workflow as WordPress. A public Drupal or Joomla source can be verified in place, retained as the remote original, copied into protected DynoStatic storage, or have its DynoStatic reference retired after a verified server original exists. Every step preserves the stable media ID used by CMS entries, collections, widgets, and local workspaces. Private or authenticated source files are not fetched by this workflow and no Drupal/Joomla credential is stored for media access.
Other comment sources
Supported readers include DynoStatic portable JSON, CSV, Disqus XML, WordPress/Hyvor XML, Remark42 JSONL, Isso JSON, Commento JSON, and Cusdis JSON. The import preview reports format and parse errors before persistence when possible.
DynoComments/Panel Comments encrypted backups are not supported import formats.
Export
Choose WordPress / Hyvor Talk WXR under Export website data for a WordPress WXR 1.2 download containing CMS entries and drafts, discussion threads/comments, and eligible media references. The export reads canonical state in bounded batches and fails closed if that state changes while the file is being generated. Choose Include verified public media references or Omit media attachments. Unverified references, private-only delivery, credentials, and protected server paths are never written. Discussion-only items are marked so a later DynoStatic re-import restores their comments without creating fake CMS content.
The other catalog exports remain discussion-focused and preserve page identity, hierarchy, status, timestamps, pins, likes, and supported reaction totals to the extent the destination supports them. Review export is separate and includes first-party source attribution without connector credentials.
Exports can contain personal data such as author names or email addresses when the format and authorization permit it. The admin workflow requires an explicit privacy acknowledgement and serves temporary files with safe attachment headers and cleanup-after-send semantics.
Large transfers
XML, CSV, and JSONL inputs use incremental readers. Whole-document JSON has a bounded maximum. Keep the browser page open for synchronous shared-hosting transfers, review the history/error panel, and split exceptionally large jobs when PHP execution or proxy limits require it. Importing is idempotent only where the source format supplies stable source IDs; keep an original export until verification is complete.
Verify
After a unified WordPress import, open Content to compare post/page totals and review several published and draft entries, routes, taxonomy metadata, and source URLs. Review Content → Media, verify a representative attachment, and deliberately choose remote, retained-copy, or retired-source custody. Then open Discussions to compare comment totals and spot-check nested replies, moderation state, reactions, and search. Retain the original export—or keep WordPress available—while acceptance testing is underway.