Feature preview
When importing historical content in batches, archives with text and pictures are suitable for entering as compressed packages, and neatly formatted plain text content is suitable for entering as tables. The choice between the two entry methods depends on the proportion of resources and fields in the source. This article explains the fields that need to be checked before and after batch import, the arrangement of the status of importing drafts first and then publishing, and the method of rolling back after importing incorrectly, with the help of the recycle bin and interface query.
When importing historical articles in batches, which source is suitable for compressed packages and tables respectively? Determine what falls into 'What else is included in the source besides text': Archives bound together with text and images are suitable for batch importing compressed packages, records with tidy fields and mainly text are suitable for table importing. AnQiCMS supports two types of batch importing entries, ZIP compressed packages and Excel tables, and the cost of choosing the wrong entry is usually not failure, but the need to manually fill in a large number of missing fields and resources.
Content from the old site often has two types of forms. One type is the archive exported from the page: each article is accompanied by a resource catalog, images are referenced by relative paths, and the correspondence between the text and images is written in the file structure. This type of source uses a compressed package entry, and the resources can be stored with the text. Another type is the export from the database or table list: the title, publication time, category, and summary each occupy a column, and the text only contains text. This type of source uses a table entry, the field mapping is intuitive, and no additional processing is needed for one image.
| Source characteristics | Appropriate batch import entry | Main risk points |
|---|---|---|
| Text with local image catalog | ZIP compression package | Check resource references when the catalog level is too deep. |
| Plain text with neat fields | Excel spreadsheet | Long text truncated by table cell |
| Source is an interface or scraping product | Convert to table first then import | Title repetition and status are not agreed upon |
| Large number of attachments and volume | Import compressed package in batches | Single package too large, difficult to locate after failure |
It is not recommended to directly import in bulk and make it visible to the outside. The document status is divided into several types such as formal documents, drafts, pending publication, and recycling bin. When importing, first enter the draft, check the title, content, and images to ensure they are correct, and then release in bulk to avoid a single mistake pushing thousands of semi-finished products online. The parts that need to be released at a fixed time should go through timed publishing with the time factor, which will take effect automatically at the set time without the need for manual monitoring.
The draft link contains a preview tag and can be used to view the rendering effect without making it public; this step is especially useful for table imports because line breaks and empty columns in tables are easy to change the paragraph structure.
The import interface provides the ability to query whether a title exists by title, the path is/api/import/archiveFirst use it to filter out duplicate titles before batch import, which is more convenient than cleaning up after import. The fields to be checked are concentrated in four places: whether the title has been truncated, whether the classification and tags fall into the existing standards within the station, whether the abstract is empty, and whether the relative resource paths in the main text have been rewritten as station addresses.
A unified field specification will bring subsequent maintenance costs. It is recommended to fix column names and category values when importing tables, so that the fields imported at one time correspond to the customized content model within the site, and avoid the same content being structured differently in different batches.
Deleting formal documents means moving them to the recycle bin, not physical deletion, so after batch import, if a batch has a problem, you can delete it in bulk first and then retrieve the correct version from the recycle bin. It is important to note the boundary of rollback: the recycle bin retains documents within the site, and whether external resource files are also cleaned up depends on the disk location of the resources at the time of import. Before rolling back, go through the same deletion action in the test category to confirm the correspondence between resources and documents.
Question: Is there a length limit for the main text in the table?Answer: A common failure is that the content of the cell is truncated. Before importing, it is more stable to split the long main text into columns separately or change it to a compressed package entry.
Can I use a zip file and a table for the two batches of content?Yes, but make sure the classification and label criteria of the two batches are consistent, otherwise the sorting and filtering performance of the same type of content in the list will be different.
How can I confirm that there are no duplicate titles before importing?Use the interface for querying by title first to compare, and change or exclude duplicate titles first to avoid two similar addresses after importing.
Can I change the publishing time uniformly after importing?Yes, but distinguish between content that has been released and content that is waiting to be released; use scheduled publication arrangements for parts that need to take effect later, and do not directly change the time of the online documents.
Preview
The permissions of paid content are layered according to user groups: first define the membership groups and corresponding content that can be viewed, and then entrust the payment relationship to order and financial management, avoiding using hidden links or drafts as permissions. The number of groups should be controlled between three to five levels, and the fewer the rules, the less likely there will be unauthorized access and cases of content not being released.
Preview
The fields and processes for products, cases, and articles are different, and they should be separated into independent content models: products require parameters and specifications, cases require customers and achievements, and articles only need titles and text. After separation, the list page and detail page should take what is needed, and drafts, pending publication, and recycling stations should also follow the model, avoiding forcing three types of content into the same set of fields.
Preview
The function of anti-crawling interference code is to increase the cost of the whole transfer, it inserts noise characters that do not produce semantic meaning for readers and layout, does not change the structure of the text and the page address, and therefore does not change the search engine's understanding of the page topic. This article explains the position of interference code insertion, the type of collection it can prevent and cannot prevent, and the way it coordinates with sensitive word filtering and content review level.
