How to supplement the missing content in the package when migrating from another content system
How to supplement the missing content in the package when exporting from a different content system? First, identify where the missing content comes from: The export file is generally organized according to the text and common fields, and the custom content types generated by attachments, plugins, and themes are often not in the package. The official Halo migration document specifies that some custom content types generated by certain plugins or themes may not be imported. The order of supplementation is to move the media directory separately first, then use the content model and custom fields to accommodate the missing structure, and finally use batch import to fill in the text.
What does the export file overwrite?
For example, in the common WordPress migration path, the official Halo documentation states that migration is 'done by exporting the WXR file (XML) from the WordPress backend', and 'it is recommended to back up the wp-content/uploads directory on the server at the same time'. This sentence points out two facts: the exported item is an XML file carrying articles and some metadata; the actual files such as images and attachments are not included in the export package and need to be retrieved from the server separately.
The three types that are often missed when moving sites are usually these:
| Content type | Is there anything in the export package? | Filling method |
|---|---|---|
| Article content and publication time | Exists, in the XML package | Direct batch import |
| Categories, tags and other structures | Partially exists, with different naming rules | Build the same name category on the new site first and then import |
| Image and attachment file body | Does not exist, only in the uploads directory | Pack and move the entire directory |
| Custom content type generated by plugin | Not applicable, the official documentation explicitly states that it may not be imported | Modeling with custom fields |
| Form, comments, and other interactive data | Depending on the export options | Exported separately as a table and then imported |
Three types of content often missing
The first type is media files. The export package only contains image addresses, and the actual files are in the upload directory of the old site. The method is to download the entire media directory, upload it according to the storage structure of the new site, and then check if the address matches.
The second type is a custom content type. It refers to data that is not articles or pages, such as schedules, quotes, and store lists, which are extended by plugins in the old site. Export tools usually do not put them into XML, so it is necessary to define the structure on the new site side first and then inject the data. The custom content model and custom fields of AnQiCMS are the entry points for this structure: first, define the new model according to the field list of the old site, and then decide which fields are required and which participate in the list display.
The third category is interactive data. Comments, reviews, and form submissions of this kind often need to be exported separately as tables. Batch import supports two forms: ZIP compressed packages and Excel spreadsheets. Tabular data can go through the Excel channel, and data packages with attachments go through ZIP.
In what order should it be filled in?
It is recommended to follow the four steps of ‘structure first, data later’:
- Inventory the old site. List all data types and field lists, mark whether each item appears in the export package, and note the missing ones separately.
- Build structure. On the new site, first set up categories, tags, content models, and custom fields to avoid fields having no place to fall during import.
- Move media. Move the entire directory and then check if the image addresses on the new site are accessible.
- Ingest data. Use batch import to execute in batches by category, first take a small amount of data for trial import, confirm that the field mapping is correct before scaling up; keep a record of the results during the import process to facilitate the location of failed entries.
If documents are mistakenly deleted during the import process, documents moved to the recycling bin can be restored, avoiding the need to re-import the entire batch.
How to converge the addresses after they are filled in.
After the content is completed, the relationship between the old address and the new address should be consistent. The address structure of historical articles on the new site is usually different, and it is necessary to redirect the old addresses one by one or according to a rule to the new addresses in the 301 redirect management behind the scene to ensure that existing external links and inclusions do not fall onto失效 pages. When configuring the redirect rules, retain the address characteristics of the old site (date segments, article numbers), which can be generated in bulk using rules, and do not write them one by one.
Before wrapping up, perform three checks: sample visit twenty old addresses to confirm that the return is a redirect instead of an error page; check if there are any old structural addresses in the site map; make a comparison table of the number before and after import, and list the missing entries separately for additional recording.
Common questions
There are no attachments in the export package, can we just move the text?That can be done, but the page will be missing all images. It is recommended to process the media directory with the text in the same batch, otherwise, you need to confirm that the new site can temporarily refer to the old site address and make up for it as soon as possible.
Can the custom fields correspond one by one with the old plugin fields?Not necessarily. The field naming and types of old plugins may have their own logic, define the type in the custom fields of the new site first, and then write a field mapping table for column import.
How to handle data that fails to import?Keep the import results record, grouped by failure reasons: change field definition for mismatched field types, supplement media for missing files, and re-import the corrected text after content hits the review rules.