After adding fields to the custom content model, should the template and batch import be modified accordingly

After adding a custom content model field, should the template and batch import be modified as well? Yes. The field only exists at the model level, so it cannot be seen on the front end and cannot be written into during import. A complete link requires three stages: defining the field in the model, using the field in the template, and aligning the field with the import and interface. If any stage is not kept up with, the new field will just be an empty column in the database. AnQiCMS supports custom content models and custom fields to ensure that these three stages can be configured separately by content type.

The first stage: the field falls on the model first.

Firstly, determine the field ownership: is it a global field or exclusive to a certain content model. Product parameters should be placed in the product model, case numbers in the case model, and adding fields globally at once will result in a lot of invalid columns in subsequent models inheriting from it.

Add constraints next: whether it is required, whether it participates in list filtering, and whether the value type is text or numeric and date. Constraints determine the way the template values and the verification strength during import are taken, and these two steps should be based on this. Often, adding fields first and then adding constraints requires redoing the template.

The second paragraph: the template values need to be changed accordingly.

The field does not automatically appear on the page just because it has entered the database. The template must explicitly use this field, and the change involves at least three places: details page display, whether to output on the list page, and whether to reference filtering and sorting.

Do not omit the default value for empty. Old data without new field values, the template directly takes the value will render a blank or placeholder on the page, adding a judgment of 'empty then do not display' is more convenient than remedying after the event.

Third paragraph: Both paths of bulk import must be synchronized

Bulk import supports ZIP compressed packages and Excel tables. After adding fields, the two things must be synchronized: the import template downloaded for the editor must include the new column; the import verification must check the required fields and types according to the model constraints.

The most common accident is using the old template to import new data: the old template lacks new columns, the import matches the existing documents by title and overwrites them, and the new fields are cleared. The way to avoid this is to first run a small sample before importing, confirm that the new fields have values, and then perform the full import; make a backup before important batch operations, in case of errors, you can roll back.

The same on the interface side. When importing document content via the /api/import/archive interface for batch import, the field names must match the model definition. The interface supports querying whether the document exists by title, and duplicate submissions will not generate two identical contents. When filling data through the interface, it is more reliable to fix the field list in the calling script than to manually check the table column names each time.

How to verify after the modification

Verify each state by taking one: Whether the new field can be displayed and restored correctly under the four states of formal documents, drafts, pending publication, and recycling station. Pay special attention to the recycling station - deleting a formal document is moved to the recycling station instead of being physically deleted. If the field modification affects the recovery logic, the documents in the recycling station may be misplaced after recovery. The recommended verification order is: first modify one draft to confirm the correct value, then publish it as a formal document, and finally delete one into the recycling station and restore it to see if the data is complete.

Common questions

Question: Is renaming a field more convenient than adding a new one?Answer: No. Renaming will cause historical values, template references, and existing import templates to become invalid simultaneously. Adding new fields with data migration is usually less risky than renaming.

Question: Should numerical fields be formatted in the template?Answer: Yes. Direct output of numerical types often results in inconsistent decimal places and units. Display formats are fixed at the template level, which is more stable than letting editors control it themselves when filling in information.

Question: How can you confirm that the import has overwritten old data?Answer: Record a snapshot of the fields affected by the import before the import, and compare them after the import; leave recoverable backup points for batch operations, and revert to the backup if there is a problem.