When using the interface to batch import articles, which fields determine categories, tags, and scheduled publishing?
When writing a batch of articles into AnQiCMS through an interface, the field correspondence can be recorded according to three groups: 'Belonging, Status, Time': The archive import interface (path containing 'import' and 'archive' two words) receives a record, the classification and tag fields determine where it falls on the site; the draft and pending publication status determines whether it is visible to the outside; the scheduled publication time field determines when it will automatically go online. Most batch tasks fail because the responsibilities of the three groups of fields are mixed up when filled in.
What do the various fields in a single import record manage?
The interface document should clearly list the following conventions. First, check the list:
| Field group | Typical field | The matter decided | Consequences of filling in wrong information |
|---|---|---|---|
| Belonging | Categories, tags | Which column the article is hung in, which group of tags it belongs to | Content stored but not found in the front-end column |
| Status | Draft, formal | Whether to enter the visible range to the outside | Directly publish semi-finished products |
| Time | Scheduled release (time factor) | The moment of automatic online at the designated time | Expected 'scheduled release' but actually 'immediate release' |
| Duplicate removal | Title | Query by title to check if it already exists | The same article entered twice due to repetition |
Categorization and tags are two different things: categorization manages the column structure, and there can be many tags under a column; tags manage horizontal aggregation. Before batch import, confirm that the target category has been set up within the site, as the interface will not create a column structure for you out of thin air.
Which path do the status and scheduled release take separately
The document status is divided into four levels: formal document, draft, pending release, and recycle bin. When writing to the interface, it is necessary to understand the differences between the two levels: the draft is an incomplete state, its link contains the preview parameter, which is only for preview and verification, and does not enter the public list; the pending release is a state where the content has been finalized and the time conditions are met. The scheduled release field is used for this level. A common mistake in batch scripts is to push the interface directly in the formal state for the unreviewed drafts, which skips the preview and verification process - a safe practice is to use the draft first, manually check it in the background, and then switch to formal or schedule for release.
Where to place the title duplication check in the batch task
The interface supports querying whether the document exists by title. This action should be placed after 'assemble records' and before 'submit write': First, run a batch existence query for all titles, list the matched items separately to decide whether to skip or update, and then submit the remaining part. If not checked, the entire batch will be resubmitted, and duplicate articles with the same name will appear. The cost of cleaning up later is much higher than that of front-end duplication check.
What conventions should be written in the public interface document
API call instructions for the counterpart, covering at least four things: whether each field is required or optional, the meaning of status field values, the format and time zone of time fields, and the calling method for duplicate checking by title. High-frequency capabilities (document list and details, categories and tags, comments and reviews, etc.) are all described in the interface document classification. The counterpart should fill in the fields according to the documents instead of guessing by trial and error, which is the other half of the guarantee for batch tasks not to produce dirty data.
Common questions
Ask: Which one to choose, scheduled release or manually going live after saving drafts? Answer: Routine content with a small amount of review can be scheduled for release; For content with sensitive public statements, it is recommended to save drafts first, preview and confirm the release time later, and the two mechanisms do not conflict.
Ask: If there are problems found with the imported records later, can they be withdrawn as a whole? Answer: It can be handled according to the status: Unpublished records can be returned to drafts for modification; Deleted published records will enter the recycle bin and can still be restored without having to physically clear them.
What if the tag field is not filled in? Answer: The article will be stored normally, but it will not enter the horizontal aggregation page. In the batch task, the tag belongs to the 'optional but recommended' field, and if there are many empty ones, the search and recommendation within the site will become weaker.