What fields can be included when importing content in batches, and which states need to be configured later
What fields can be included in the content batch import interface, and which states need to be configured later? The answers to these two questions are as follows: Title, keywords, description, category, tags, draft position, these content attributes can be fully written at the time of import; while publication time, scheduled publication and other configurations that affect the state transition are recommended to be added one by one after the first batch of samples are verified. The common consequence of reversing the order is that a batch of content with incorrect categories and half-time settings enters the official list, and rolling back is more time-consuming than补writing.
Fields covered by the import interface
The document content import API path provided by AnQiCMS is /api/import/archive, which writes the content sorted outside into the site internally. The fields that can be stored in one request roughly match the fields on the background editing page, the difference being that the interface will not handle items that require manual judgment.
| field | Do you suggest including it during the import? | Description |
|---|---|---|
| Title | Must include | Also serves as the basis for querying whether a title already exists. |
| Keywords, descriptions | Suggest to include | Determines the summary display in the list page and search results. |
| Categories, tags | Suggest to include | The category should use the existing number in the site, do not expect the interface to build it automatically. |
| Main text | Must include | Keep the content pure, do not hard write the site address in the text |
| Draft position | Open the first batch of suggestions | First enter as a draft, verify and then transfer to formal documents |
| Publishing time, scheduled release | Configure at the end | After confirming that the position of the text is correct, arrange item by item |
Where should the duplicate check action be placed
The easiest accident that can occur during batch import is duplicate entry./api/import/archive supports querying for existing titles, and the correct usage is to check once before writing: compare each item on the list to be imported one by one, and for matches that already exist, either skip or change the action to update instead of inserting another. The timing of duplicate checking should also be fixed—after generating the list and before sending the request, rather than checking manually after the import is completed, as the latter is impossible to clean up thoroughly on large lists.
What status is the document in after import?
The document status is divided into four categories: formal documents, drafts, pending release, and recycling bin. The reasonable default for batch import is a draft: after being stored, you can check field alignment one by one on the editing page, and confirm it to turn it into a formal document that is visible to the public. If you need to check the layout but do not want to make it public, you can preview the draft link by adding the preview parameter, without having to turn it into a formal document first and then hide it. Why is the delete action safe, and this is also part of the set of states - deleting a formal document is moved to the recycling bin rather than physically deleted, and deleted items can be recovered from the recycling bin, but this does not mean that the recycling bin can replace backups.
Why is the timing factor and scheduled release delayed?
The time factor is used to set the timing for content release, with the premise that the content itself is already accurate. Placing the timing release in the import parameters together with submission is equivalent to scheduling the external actions before the verification occurs. Once there are issues with the first batch of content, the scheduled entries will still be released. The safe approach is divided into two stages: first import and verify, and then set the release time for each piece of content that passes the verification, and stagger the scheduling to avoid a situation where a large amount of content is released at one time.
Verification list for the batch import
A batch review of the final check looks at five aspects: Is the title truncated? Are the keywords and descriptions in place? Are the categories and tags pointing to the expected entries? Are the images and other static resources in the body available with the content? Open a few randomly selected ones from the front-end perspective to see the layout. There are not only interface entries for batch import, but the site also supports two batch import methods: ZIP compressed packages and Excel tables. The verification standards for the three entry methods are consistent - they should all end with 'extract formal documents, check the front-end performance'.
Common questions
Ask: Can the import interface replace the batch import within the site? Answer: The positioning is different. The interface is suitable for external programs to push entries and can search before writing; ZIP compressed packages and Excel spreadsheets are more suitable for migrating a large amount of content that has been manually organized at one time.
Ask: Should the category be written as a name or a number in the import list? Answer: Use the category identifier that already exists within the site. Names are easy to mismatch due to spaces or synonyms, which can cause content to fall into the default category. The amount of change required by the all-site replacement tool later will be significantly higher.
Ask: How to deal with batch cleanup when the import is wrong? Answer: First confirm the status of this batch of content. Directly clean up in the draft stage; move the formal ones to the recycle bin, and then find the truly needed ones one by one according to the recycle bin. When there is a large range of changes, make a backup first before continuing the operation.