CodeCanyon ImportWP Pro - WordPress Plugin

A Practical Guide to Setting Up CodeCanyon ImportWP Pro

CodeCanyon ImportWP Pro is most useful when WordPress needs to take in an external catalog, an export from a legacy system, a supplier spreadsheet, or a regularly updated XML file and process it predictably. In that kind of workflow, the main task is not clicking the import button. You need to define what each row or XML node represents on your site, which fields can change on a repeat run, how to identify the same record, and how to catch an error before it reaches the public site.

This guide walks through the process, from checking the source file to updating records under controlled conditions. It covers posts, pages, custom post types, terms, and users, as well as imports that use the ACF and WooCommerce add-ons. It also covers CSV/XML selectors, stable identifiers, update permissions, media files, test runs, scheduling, and troubleshooting.

Think of an import as more than a one-time migration. With CodeCanyon ImportWP Pro, it is more useful to build a repeatable process from the start: a small test file, a clear field map, a recovery point, and one stable matching key before running the full import. That approach saves time and prevents catalog or database updates from turning into a manual duplicate cleanup job.

When importing becomes a data-mapping problem

The plugin is useful when the source data is structured differently from WordPress. A supplier CSV might have an item_code column that needs to become the store's SKU. An XML product record might contain nested nodes for photos and specifications, while the corresponding custom post type needs a title, taxonomies, custom fields, and several attachments. You could create those relationships by hand in the WordPress editor, but ImportWP Pro lets you define them once in an importer configuration.

In practice, the plugin supports four distinct use cases. The first is a one-time migration, where the data is ready and the source will not change after the import. The second is initially populating a large catalog. The third is syncing only selected fields, such as stock and price. The fourth is regularly importing data from an external XML/CSV source. They may look similar, but each needs different rules for creating, updating, and deleting records.

Where ImportWP Pro can save time

For a content site, that might mean migrating posts or custom post type records with titles, body text, categories, image URLs, and theme-specific fields. For a catalog, it might mean importing product records with stable SKUs, prices, stock levels, categories, attributes, and galleries. For an education site, it could be importing instructors, programs, or events with some of the data stored in ACF. For a support site, it might mean importing authors, terms, or users from a source system.

The basic mechanics are the same in each case: the file provides values, the importer template determines which WordPress entities to create, and the field mapping tells WordPress where each value belongs. However, "import" does not mean that every field is safe to update on every run. Product descriptions, editorial content, manually corrected photos, and SEO metadata often need to remain under the editor's control. That is why the Permissions tab matters just as much as the template fields in ImportWP Pro.

Who should use it, and when another approach may be better

The plugin is a good fit for an administrator or content manager who can read a CSV or XML structure, understands the difference between a post, taxonomy, custom field, and attachment, and is willing to test a few rows first. Developers can also use it as a foundation: the documentation describes extension points and ways to process values before saving, but routine imports do not require changes to WordPress core or the plugin itself.

If the source lives in a closed service that provides only an authenticated API, with no XML or CSV file, you first need to decide how to retrieve the data. If the project has no stable record key, add one to the source or agree on how to generate it before importing. If you need to migrate an entire WordPress installation, including users, theme settings, and files, a spreadsheet import is not a substitute for a full migration plan. Finally, if you have only a few records that rarely change, creating them by hand may be easier to understand than maintaining a dedicated import workflow.

A practical rule of thumb: use ImportWP Pro when the task can be described as a repeatable rule: "one source record becomes one WordPress object with known fields." If you cannot state that rule clearly, normalize the data first instead of trying to compensate for it with a dozen exceptions in the interface.

Map the workflow: file, template, fields, identifier, outcome

Before installing the plugin, sketch a short workflow map. This is not paperwork for its own sake; it helps you keep two different questions separate: where a value comes from and what WordPress should do with it. List the source fields in the left column, the ImportWP field or rule in the middle, and the visible WordPress outcome in the right. For example: supplier_sku -> Inventory → Product SKU -> the existing product is found on the next run; image_url -> attachment record -> the image appears in the media library and product page; category_path -> hierarchical taxonomy -> the product gets the right category.

The map should also record what you have decided not to update. For example: the description field is not updated because a content manager edits it; a blank price must not overwrite the existing price; an archived category must not delete a product; and images will be attached only after a test confirms that their URLs are accessible. These restrictions matter more than listing every field that might be available.

Define what counts as one record

In a CSV, a record is usually obvious: one row after the header. XML is more complicated. A file may contain a root node, category blocks, a list of products, and repeated images, properties, or variations inside each product. In ImportWP Pro's file settings, you can choose an XML Base Path, the path to one standalone object to import. The preview shows the first record at the selected path. If you choose a node too high in the hierarchy, the plugin may treat the entire catalog as one record. If you choose one too deep, you may lose fields that belong to the product.

Here is a simple check: the preview for one record should show the unique key, title, and at least one field you plan to import. For variable products, decide at this point whether each record represents a parent product, a variation, or an attribute row. Do not try to hide an inconsistent data model behind nested selectors. It is better to create separate importers for distinct entities.

Prepare a small test file

Create a copy of the file with 3-10 records. Include a typical record, one with multiple categories or images, one with an optional field left blank, and at least one record that you will update later. This sample will reveal much more than a single perfect example. Keep the original file separate, do not edit the only copy on the server, and do not replace keys with temporary values after the first run.

For CSV, check the delimiter, text enclosure, encoding, headers, and whether every row has the expected number of columns. A comma in a value that is not enclosed correctly can turn the rest of the description into a phantom column. For XML, check that all tags are closed and the hierarchy stays consistent from record to record. If the supplier provides the file remotely, record the test copy's retrieval date and file size in a team note. That makes it easier to tell an import error from a change in the source.

Create an importer: choose the right template before mapping fields

After activation, the documented path for creating an importer starts at Tools → Import WP. On the Add New tab, give the importer a clear name and choose what it will import. Base the name on the source and destination, such as "Supplier A - prices and stock" or "Property catalog - initial import." A name like "New Import" quickly becomes unhelpful once you have test, production, and recovery workflows.

The template you choose determines which field groups are available and therefore shapes the rest of the setup. Posts, pages, and custom post types use the corresponding WordPress template. For terms, choose a taxonomy. For users, use the user template. For a store, the WooCommerce add-on provides a product template with fields grouped around the product record. For ACF, the selected template is only part of the setup: the fields you plan to populate must already be registered on the site.

Why you should not start with a generic post template

A post template can be tempting because it lets you save a title and metadata. But a WooCommerce product has properties, parent-variation relationships, stock, prices, images, and taxonomies that are easier and safer to configure with a dedicated template. Import WP's documentation shows a separate importer type for WooCommerce products, with simple, grouped, external, and variable products represented as different product types. Using a generic template for a quick start pushes the complexity into unclear metadata and makes repeat imports risky.

Similarly, do not import a list of images as ordinary posts if the goal is to create or update media library attachments. ImportWP has a separate attachment template with fields for the file, title, caption, alt text, parent, author, and other properties. Choose the template based on the entity you are working with, not just on whether the columns seem to match.

File sources and the boundary of responsibility

When choosing a file, you can upload it from your computer, use a remote URL or a path on the server, or select a file previously attached to the importer. A remote URL is convenient for supplier exports, but it needs careful checking: it must point to the expected CSV/XML, be accessible to the WordPress server, and not expose secrets in public examples or team documentation. If the source requires credentials or complex authentication, do not put them in screenshots or articles or share them with third parties. First decide on a secure way to deliver the file to the site environment.

For recurring data exchanges, it helps to separate file retrieval from file processing. One process makes the latest export available at a predictable path. ImportWP Pro reads the file and writes data to WordPress. This division makes troubleshooting easier: if the preview has no new rows, the issue is upstream of the plugin; if the preview is correct but the product page has not changed, check the mapping and permissions.

Read CSV and XML files: where imports can fail before field mapping

After you choose a file, ImportWP Pro opens its read settings. This is not a formality. These settings determine whether the plugin sees the actual data or a distorted version of the file. For XML, the key setting is XML Base Path. Choose the path that contains one record, then check the preview panel after every change. If a record contains several neighboring nodes with the same name, the data selector may treat them as a group. That is useful for repeated images, but you need to decide whether you want the whole group or a specific item.

CSV settings are usually simpler, but mistakes can have equally visible effects. Delimiter must match the actual separator, Enclosure must match the character surrounding text cells, and the header option must reflect whether the first row contains column names. A mismatch can shift values: a price may end up in a description field, the SKU column may appear blank, and the stable identifier may not be found. Do not try to fix that in the field mapping. Go back to the file settings and correct the preview first.

Check the preview before selecting fields

The preview should answer five questions. Can you see the expected number of columns or the right XML nodes? Is any text with commas, line breaks, or HTML cut off? Do you see unexpected characters instead of readable text? Does each test record have a unique key? Is repeated information, such as several image URLs, displayed correctly? If the answer to any of these is no, it is too early to configure the fields.

Unexpected characters usually point to a file encoding issue. Import WP's documentation treats encoding as a separate topic and recommends addressing it when the preview shows garbled characters. Do not try to fix the problem by replacing text field by field. Correct the source file or read settings, then reopen the preview. Once the file is being read correctly, the same record should look the same in the test copy and in the importer.

Complex delimiters and compound values

Real-world exports often use commas to separate columns, vertical bars to separate categories, and semicolons to list image URLs. Keep those levels distinct. First define the CSV structure, then specify how a particular field group should handle multiple values. If a category name contains a comma, it needs to be enclosed correctly as a cell. If the source uses a nonstandard multi-character delimiter, consult the product documentation for that format and test it first. Otherwise, it is easy to lose the meaning of the data during file parsing.

A well-configured file looks uneventful: the preview simply matches the source. That is exactly what you want. Save more elaborate transformations for after you have confirmed that the basic structure reads correctly without surprises.

Map fields: data selector, preview, and value transformations

The Template fields tab connects the file to the importer template. Fields are grouped by purpose: a post template has post, taxonomy, attachment, and custom fields; other templates have different groups. Do not enable everything. Click Enable Fields and add only the fields this workflow is responsible for. The clearer the boundaries, the easier it is to understand the importer when you run it again.

For each field you need, open Select Data. In XML, the modal shows one record and lets you choose a node, text, or attribute, creating an XPath. In CSV, selecting a row in the preview inserts a reference to the column. In either case, check not just the source field name but also its preview beside the destination field. A source field called name is not necessarily the product name; it might be a brand or category.

Build the mapping around an observable outcome

A useful setup order is: title or name first, then the stable key, object type, taxonomies, main text fields, images, and finally complex metadata. Save your changes after each small group and note the expected outcome in your workflow map. This order matters. If the plugin cannot create the basic entity, there is no point troubleshooting images and complex fields. Once the base object exists and has a stable key, you can test additional properties without losing the connection to the record.

Consider an XML property record. It contains reference, title, price, a list of features, and repeated images/image nodes. First map reference as the future identifier, then map the title and basic fields. Do not try to turn the list of features into a polished string in the title field. First decide whether the features belong in a taxonomy, separate custom fields, or an ACF repeater. Only then choose the nodes and delimiters.

When to use value mapping

The Template Fields documentation describes mapping as replacing a source value with another value. This is useful when an external source stores its values in a code system, such as Y/N, active/inactive, status codes, abbreviated types, or local labels. Instead of asking the theme or another plugin to guess what each code means, create an explicit rule in the importer and test both branches with a small file.

Value mapping is suitable for a finite set of known values. It does not replace data cleanup if a column contains dozens of unpredictable variations. In that case, normalize the source first or use a documented extension point. Keep the original mapping easy to understand: someone else should be able to open the importer a month later and see why Yes becomes 1 and why a blank value is not written to the record.

A small, safe value transformation

If you have confirmed that you need only a predictable text normalizer, the product documentation describes the iwp/template/process_field filter for changing a mapped value before it is saved. The example below does not modify the plugin core. It is a minimal custom adaptation based on the documented filter: it trims whitespace and converts the SKU to uppercase. Put the code in a small custom plugin or a safe snippet manager, but only after making a backup and testing it with a test importer first.

<?php
add_filter('iwp/template/process_field', function ($value, $field) {
    if ('sku' !== $field) {
        return $value;
    }
    return strtoupper(trim((string) $value));
}, 10, 2);

Before using it, confirm the actual field name in the documentation and test template. Do not guess that sku is the right value. The check is simple: two values with surrounding spaces and different letter cases should produce the expected normalized key in the test record. To roll back, deactivate the snippet and repeat the test run with the original values. Do not apply this kind of transformation to titles, descriptions, or image URLs without a separate reason.

Stable identifiers and permissions: prevent duplicates and accidental overwrites

In ImportWP Pro, the Permissions tab controls the most important decision for a repeat import: whether a row is treated as new, used to update an existing record, or skipped. The plugin uses a unique identifier to find the object. You can use a populated template field or build a custom value from one or more parts of the source file. The documentation also warns that the search includes items in the trash, and that changing the identifier type or value between runs can create duplicates or break the expected match.

Choose the identifier before the first production run and keep it unchanged. For a product, that is usually an SKU, GTIN, UPC, EAN, or stable external code. For a page or custom object, it could be an ID from the source system. For a user, an external ID or another agreed-upon key is generally a better choice than a display name. Titles, readable slugs, and prices are poor identifiers: they can change naturally and are not necessarily unique.

How to choose a key

A good key meets three conditions: every record has one, it does not change during routine updates, and it is unique across objects. If all three are true, map the field on the Template fields tab, then select it on Permissions. If the value should not appear on the public record, the documentation allows you to create a custom identifier from parts of the file. Make sure the composite key is easy to explain, such as a supplier code plus an item number, rather than an arbitrary combination of a title and price.

Test the key on a small sample before the full run. Run the import a second time after changing one field that is allowed to update. The expected outcome is that the number of objects stays the same and only the intended field changes. Then test a new row. If creation is enabled, it should appear exactly once. This short test is more valuable than assuming a field name is correct.

Three safe modes for different tasks

Initial import usually allows creation. Enable updates only if you intend to rerun the test. It is sensible to leave deletion disabled. Even if the file is supposed to be complete, a row missing from the next export does not always mean that the object should be removed from the site.

Recurring updates require a stable identifier, permission to update, and an explicit list of fields the source is allowed to change. For a supplier feed, these might be stock, availability, price, a short technical specification, and supplier-provided images. You can exclude editorial descriptions, page blocks, and manually selected featured images. This keeps the import from conflicting with the content team's work.

Update without creating is useful for syncing prices or stock in an existing catalog. In this mode, disable creation, enable updates, and limit the field list to what is needed. A row with an unknown key should produce the expected creation error instead of quietly creating a new product. That is a useful signal that the supplier sent a different key or that the corresponding product does not exist on the site yet.

Restricting fields matters more than it may seem

The permissions interface lets you allow all fields, limit changes to selected fields, or block specific fields. When a workflow updates only part of a record, start with a narrow allowlist. If an incoming feed provides an empty gallery or incomplete attributes for a day, broad permissions could erase a product page that had already been corrected. A narrow rule keeps an incomplete update from becoming a site-wide content loss.

Distinguish a blank value from an intentional request to clear a field. If the business process needs to clear a field, add an explicit flag to the file, such as clear_gallery=yes, and process it only after confirming the configuration. Do not treat every blank cell as an instruction to delete data. This matters especially for CSV files that may be temporarily incomplete.

Deletion and the trash

Deletion is the riskiest action in an import workflow. Do not enable it for the first run, connect it to a source that may be incomplete, or test it on a public catalog. If the business rules really require deleting missing items, first run the import on a site copy and save a list of expected deletions. Confirm that the identifier matches the one used when the records were created. Remember that searches include items in the trash: an unexpected match can make it look as if a new object disappeared when the plugin actually found an older one.

Do not change the key midstream. If the SKU was the identifier and you switch the importer to a title or internal ID, make a separate migration plan first. A routine repeat run cannot know that the new search method refers to the same object.

Nested data, taxonomies, and attachments: do not flatten everything into a table

ImportWP Pro's strengths become clear when the source contains more than a title and body text. Templates can work with taxonomies, attachments, and custom fields. Each group, however, stores data according to its own WordPress rules. A category is not just a text string, an image is not just a URL in an arbitrary field, and an array of product features cannot always be stored as a plain string. Before mapping a value, decide how it should be represented on the site.

Taxonomies and hierarchies

A taxonomy is useful when a value needs to support filtering, archives, navigation, or a shared attribute across many objects. Examples include product category, brand, property type, city, and topic. ImportWP's documentation describes a separate taxonomy section for product categories and settings for hierarchy. If the source stores a path such as Electronics > Photography > Lenses, decide in advance what separates the levels and how they should be connected. Do not assume that a text string will automatically create the right hierarchy without configuration and testing.

For repeat syncs, pay particular attention to whether terms should be added or replaced. If the feed contains the full category list for each record, replacing the terms may make sense. If it contains only additions, replacement will remove existing relationships. Test this on a record that already has several categories and note the decision in your import map.

Images and files

Attachments generally involve two separate tasks: retrieving the file and linking it to an object. Import WP guides describe downloading from a remote URL, using the site's file system or FTP, and reusing media library files. For a post or product, you also need to know which image is the featured image, which ones belong in a gallery, and how multiple URLs are separated. Do not add media downloads to the first test while the basic fields and unique identifier are still unproven.

Check external URLs from the perspective of the server running WordPress. A file might open in your browser but still be unavailable to the server because of a network restriction, redirect, hotlink protection, or expiring URL signature. Do not try to work around that by randomly changing the field type. Note the symptom, test one URL, check the response code and file type, and then choose the appropriate attachment source. If multiple images are listed in one cell, verify the exact delimiter and order before running a bulk import.

ImportWP has a separate template for attachments, with fields such as File, Alt Text, Caption, and Parent. It is useful when the media library itself is part of the migration. For post and product records, use the attachment groups in the relevant template. In either case, a successful file download alone is not enough: confirm that the file is attached to the expected object, serves as the featured image where needed, and appears correctly on the public site.

Custom fields and ACF

Use a custom field when a theme or extension needs the data but it is not a standard post field. The documentation recommends creating a sample WordPress record before importing, filling in all the required parts, and using the existing custom fields preview. This is a practical way to see how the site stores a valid example instead of guessing the field key.

The Advanced Custom Fields add-on expands the field list to include registered ACF fields and adapts the settings to the selected field type. This is especially useful for links, files, images, galleries, dates, relationships, and repeaters. But ACF does not remove the need to understand the expected format. For example, a relationship needs the expected object IDs; the documentation specifies that a link uses values such as title=..., url=..., and target=...; and a true/false field needs one of the expected Boolean representations.

An ACF repeater needs its own design. In XML, repeated nodes may map naturally to several repeater rows. In CSV, decide in advance how the repeating group is represented: separate columns, a serialized structure, or normalized rows. Do not let the choice be dictated by combining values into one field. First create a record manually in ACF and inspect the expected data shape. Then prepare a test with one object and two repeated items.

What to do if an ACF field is missing

If the expected field is not listed, first confirm that ACF and the relevant field group are active, and that the group's location rules do not exclude the selected post type. Import WP's FAQ describes a case where restrictive location rules prevent the plugin from finding related groups. It also mentions a documented filter as a technical option for experienced developers. Do not add it unless necessary or apply it to a production site without testing. In most cases, it is more useful to check the object type, field group, and actual field name first.

Sync a WooCommerce catalog without duplicates or lost editorial changes

Product imports are the most demanding, but also one of the clearest, use cases for CodeCanyon ImportWP Pro. The official documentation describes a dedicated WooCommerce Products template that supports simple, grouped, external, and variable products, as well as variations when the corresponding add-on is installed. Use that template because its sections match the data in a product record: product type, prices, stock, images, taxonomies, attributes, and variation relationships.

For a catalog, first decide who is the source of truth for each field. If the supplier manages only stock and regular price, do not give it permission to change product names, descriptions, galleries, and custom blocks. If the supplier provides the full catalog, still check for blank values and category consistency. One importer does not have to handle initial setup, daily stock updates, and bulk copy revisions. Several simple workflows with clear permissions are easier to verify than one universal importer.

Set up simple and variable products in the right order

For simple products, start with a few essential values: name, type, SKU, price or the other values your store requires, category, and image if needed. Map the SKU, then use it as the unique identifier on the Permissions tab. Run a small test and rerun it after changing the price. Once the existing product updates without creating a duplicate, add media and taxonomies.

Variable products need to be imported in the right order. The documentation recommends creating parent products first, with attributes marked as used for variations, then importing the variations and linking them to the parent using an appropriate field, often the SKU. Each variation needs its own stable key. Giving the parent and a variation the same SKU creates a conflict that cannot be fixed by renaming the field.

Describe the model first. For example, a parent product, TSHIRT-100, has "Size" and "Color" attributes; variations TSHIRT-100-BLU-M and TSHIRT-100-BLU-L have their own prices, stock, and parent relationship. Confirm that the parent attributes exist before importing variations. Then create one parent and two variations, open the product in WooCommerce, and verify that customers can select the options rather than seeing a few unrelated records.

Prices, stock, and partial feeds

For recurring price and stock updates, create a separate importer with a concise field map: SKU, price, sale price if needed, quantity, and stock status. On the Permissions tab, enable Update, disable Create if new products should not appear, and limit the allowed fields to price and inventory data. Import WP's WooCommerce documentation recommends this approach for updates that should affect only stock or prices.

Do not treat zero and blank as the same value. Zero stock may be valid, while a blank cell could indicate an export error. Confirm the source rules and test edge cases. Also make sure stock management is enabled for quantity updates where the store's setup requires it. If the feed changes prices but not publication status, do not add unrelated fields to the update map.

Taxonomies, galleries, and editorial ownership

Categories often seem simple until the first repeat run. Decide in advance whether the feed contains a complete or partial category list, whether manually added categories should be preserved, and whether the importer should add or replace terms. The same principle applies to galleries. If an editor has reordered the photos to improve the product page, a daily sync should not restore a different order unless that is part of the agreed workflow.

Make ownership boundaries explicit. WooCommerce importer documentation mentions groups for galleries, attributes, related products, and other properties. Update permissions turn those boundaries into technical safeguards. First allow the feed to update only its fields, then expand the list based on test results. The safest recurring update changes less than the plugin is capable of changing.

Practical example: updating a catalog from a supplier CSV

Here is a typical task, rather than an abstract import. The store already has products whose descriptions and photos have been prepared by an editor. Each morning, the supplier generates a CSV with the columns supplier_id, sku, title, regular_price, sale_price, stock_qty, category_path, and image_urls. The business wants prices and stock updated automatically, new products created only after a separate review, and descriptions and existing galleries left untouched.

Goal and preparation

The goal is to update existing products by SKU without creating duplicates, log any unknown SKU, and confirm that the public product page shows the new price and stock status. Prepare a backup, a test CSV with 5-10 rows, and one existing product whose original price, stock, description, and images you know. Add a row with a new SKU, one with a blank price, and one whose SKU differs by whitespace or letter case if that kind of source issue is possible.

Confirm that WooCommerce and the required importer add-on are active, and that the SKUs in the catalog are unique. If products were previously matched by title, do not mix the two methods. First create a separate mapping list or agree on a migration to SKUs. The update importer should use a single stable key from its first meaningful run.

Step 1. Create a dedicated importer

1. In Import WP → Add Importer, name it, for example, "Supplier A - price and stock."
2. Select the test CSV source and confirm that the header option matches the file.
3. Choose WooCommerce Products as the template, not the generic post template.
4. In the file settings, check the delimiter, text enclosure, and preview all the test rows.
5. Do not add images and categories just because those columns are present. This workflow is only for syncing price and stock.

Do not run the import yet. At this stage, the goal is to define the workflow clearly. The name, template, and planned fields should tell your colleagues the same thing: the feed updates inventory data, not the entire storefront.

Step 2. Map only the required fields

On Template fields, enable the SKU field in the appropriate group and select the sku column. Then add only the price and stock fields required by your store: quantity, stock status, and, where needed, the stock management option. Map regular_price and sale_price only after checking the number format. If the source uses a different decimal separator, confirm how it is handled in a test instead of manually correcting dozens of values in the interface.

You can map the title in the test importer for clarity, but do not allow it to update. This helps confirm that the key finds the right product without giving the supplier control over editorial wording. Then check the preview: every row should show an SKU, the price should not land in a text field, and the quantity should not be combined with a neighboring column.

Step 3. Set the identifier and restrictions

On Permissions, choose Product SKU as the unique identifier, enable updates, and disable creation. In the update field restrictions, allow only prices and inventory data. Do not add the description, gallery, categories, title, or custom fields. Save the settings and write down the rule in your working documentation: "An unknown SKU is not created; an existing SKU updates price and stock only."

The test row with a new SKU should now produce a clear creation-not-allowed error. That is not a failure in the workflow; it confirms that the boundary is working. If it creates a product, review the permissions. If an existing SKU creates a duplicate, check whitespace, letter case, the column value, and the selected identifier. Do not move on to scheduling until both cases behave predictably.

Step 4. Run a controlled test

On the Run Import step, specify a row range that covers the test sample. The documentation explains the Start Row and Number of rows settings, which let you test part of a file instead of running the whole thing. Choose Run Now, save, and start the import. The progress window shows the status, statistics, and log for processed records. Do not stop at the word "complete": open one updated product and compare it with its pre-import state.

Check the price, sale price, quantity, stock status, whether new duplicates appeared, and whether the description and gallery stayed unchanged. Then open the public product page in a separate window and reload it without the browser cache. If the site uses a server or plugin cache, clear only the relevant layer according to your project's procedures, then check again. The importer saves data, but it does not have to refresh another component's frontend cache immediately.

Step 5. Handle new products in a separate workflow

Once you have verified the basic update, create a separate workflow for adding new SKUs. You can enable creation there and map the title, type, categories, images, and other properties. Test it on a few new products first. This lets you control two different business operations: recurring updates to a small set of fields and deliberate creation of new product pages with a quality check.

Manual runs, logs, and scheduling: automate only a proven workflow

The Run Import tab offers two modes: run immediately or run on a schedule. In manual mode, you can limit the record range, and the interface shows progress, statistics, and a log. Keep using manual runs after the first day. A short, controlled run is useful after a supplier changes the file, you update the theme, add an ACF field, change the XML structure, or adjust the matching rules.

Enable scheduling once several manual runs have produced the same expected outcome. ImportWP Pro's documentation describes recurring schedules that use WordPress Cron, as well as a separate option that uses a server scheduler. This does not make it appropriate to publish a secret token in an article or in documentation available to everyone. Give details about secure execution, URLs, and server tasks only to the responsible administrator, and store them according to your project's policy.

How to confirm that a scheduled run is working

Do not rely only on the selected frequency in the form. Create one harmless test that should cause an observable change within a defined interval. Check the importer notification, log, last-run time, and result on the site. The documentation describes a Waiting on WP Cron status, which means that execution is waiting for the WordPress Cron handler. If a manual run works but a scheduled one does not, check Cron and the execution environment before changing all the field mappings.

For large files, decide how long a single run is allowed to take. The scheduling guide ties the importer time limit to the PHP limit available on the server. Increasing it may speed up processing, but it can also conflict with hosting limits. Do not raise it without measuring first. Start with a small sample, check the last successfully processed record in the log, and reduce the workload or split the import if needed.

Changing sources and verifying the data

An automated import needs a control point you can observe. That might be a log report, a separate test record, a processed-row count, or a sample SKU check. If the source sometimes returns an empty file, an HTML error page instead of CSV, or a truncated feed, an automated run without monitoring can cause more damage than a manual process. Restrict permissions, leave deletion disabled by default, and agree on who checks an unusually high or low number of changes.

Import WP's documentation notes that scheduling is useful for recurring tasks and that history and progress provide visibility. Treat them as an operation log, not decoration in the interface. When something fails, save the importer ID, time, row range, and an example record. That information is much more useful than saying, "The import isn't working."

Verify the outcome after a run: do more than count processed rows

Import success has several levels. First, the file was read correctly. Second, each record followed the intended create or update path. Third, WordPress stored the data in the expected place. Fourth, the theme, WooCommerce, or another extension displays it to visitors. Fifth, running the import again does not create side effects. Check each level; otherwise, a "successful" log can still hide a broken public product page.

A basic verification checklist

1. Compare the number of processed and failed rows with the test sample.
2. Open one new and one existing record using the stable identifier.
3. Check the fields the workflow was allowed to change.
4. Confirm that protected descriptions, galleries, categories, and editorial blocks did not change.
5. Open the public page and check what visitors see, including filters, variations, price, and images if those are part of the task.
6. Run the same test file again and confirm that it creates no duplicates or unexpected changes.

For CSV and XML files with repeated elements, include a record with several photos, terms, or repeater items. For variations, include a parent with several options. For ACF, check both the record and the part of the site where the theme uses the field. For user imports, confirm that the users were created without triggering unwanted notifications or access.

Check representative records

It helps to have 3-5 test records that deliberately cover different cases. The first is a typical record. The second has a multi-value field. The third has an optional value left blank. The fourth should be updated. The fifth should be rejected. Do not choose these at random after something goes wrong. Add them to the operating procedure and reuse them after changing the configuration.

If an import affects important public data, check it as an anonymous visitor, not just in the admin area. The theme may apply its own transformation, cache, template condition, or incomplete custom field display. A correct outcome means that the source contains the expected value, ImportWP shows it in the preview, the WordPress record receives it, the public page uses it, and a repeat run does not make an unintended change.

Official video walkthrough: create an importer and check the first rows

ImportWP's official video on importing users from CSV shows the process from creating an importer to running it. It is useful beyond user imports because it clearly demonstrates the general workflow: create an importer, choose a file, map fields, and run the import. Watch it after reading the sections on identifiers and permissions so you can adapt the decisions to your own template instead of copying the steps mechanically.

Pay attention to the object type selection, field mapping screen, and run. Your workflow may have different field groups: WooCommerce adds product sections, posts use post and taxonomy fields, and ACF adds more field types. Do not copy the identifier or update permissions from the video without creating your own data map. Those settings depend on the source and determine whether the second run will be safe.

Troubleshoot an import by tracing symptoms to testable causes

Troubleshooting ImportWP Pro is faster when you do not change every setting at once. Record the symptom, choose one specific row or XML record, check it in the preview, and then trace it through to the WordPress object. The run log, selected template, field mapping, and Permissions tab will tell you more than rerunning the full import with new, arbitrary settings.

CSV columns have shifted, or the preview shows extra or truncated values

Symptom: a title appears in the price field, a record breaks into multiple rows, the number of columns in the preview changes unexpectedly, or the import reports an inconsistent number of fields. Likely cause: the delimiter or enclosure is wrong, text contains an unescaped comma, line endings are mixed, or the export was cut off.

What to check: Open the original CSV in a plain-text editor and compare one problematic row with the Delimiter, Enclosure, and header settings in ImportWP. Look at the actual characters around descriptions, URLs, and names, not just the formatted table shown by a spreadsheet application. Test with a small file containing only a few rows.

How to fix it: Correct the export in the source system or match the read settings to its actual format, reopen the preview, and only then repeat the field mapping. Do not try to shift each template field over by one column. When to roll back: if the preview is still inconsistent after changing the settings, undo the change and request a corrected file. Do not run it on the production catalog.

A repeat run creates duplicates instead of updating existing records

Symptom: the same product, post, or other object appears twice even though it represents one source entity. Likely cause: no stable identifier is selected, its field is not mapped, its value differs because of whitespace or formatting, or the matching method changed after the first run. For product imports, the documentation specifically recommends an SKU or another stable identifier instead of a product name.

What to check: Find one duplicate and compare the key in the source row, the template field preview, and the existing WordPress record. On Permissions, check which field is set as the unique identifier, whether updates are enabled, and whether the rule changed after the first import. Also check the WordPress trash: identifier searches include items that have not been permanently deleted.

How to fix it: Stop the schedule, choose one stable key, and confirm it with two tests: rerunning an existing record should update it, while a new key should create exactly one record if creation is enabled. Cleaning up existing duplicates needs a separate, careful plan. First identify the primary record and make a backup; do not try to fix a bulk cleanup by running the import again. When to roll back: if you cannot prove that the key is stable, return the importer to manual test mode and do not enable bulk sync.

The import says that creation or updates are not allowed

Symptom: a row is not saved, and the log reports insufficient permission to create or update a record. Likely cause: the identifier found an existing object but Update is disabled, or the object was not found and Create is disabled. A field may also be blocked by a permissions allowlist or blocklist.

What to check: Determine whether an object with the same key already exists, then compare that with the workflow's purpose. In an "update only" workflow, a rejection for a new SKU is expected and useful. In an initial import, a rejection for a new row means the creation permission is too restrictive. If the object was found but one value did not change, check the specific field restriction too.

How to fix it: Match the permissions to the purpose of the importer, enable only the required action, and repeat the test with one row. Do not enable creation, updates, and deletion all at once just to dismiss the message. When to roll back: if one permissions change starts affecting unrelated fields, restore the narrow allowlist and split the workflow into initial import and partial sync.

Images are missing or attached to the wrong records

Symptom: the main record is created, but no image appears on the page; the gallery is empty; extra files show up in the media library; or a file is linked to the wrong object. Likely cause: the remote URL is inaccessible to the WordPress server, the wrong source type is selected, URLs are separated by the wrong character, an attachment field is being used instead of a separate template, or the parent relationship is configured incorrectly.

What to check: Take one URL from the file and check whether it is accessible from the server's perspective. In the importer, check the download source, base path, and preview value, not just the URL column. For multiple files, test one record with two URLs. In a separate attachment importer, confirm that the Parent rule uses the required reference type, such as ID, slug, name, or reference column, as described in the documentation.

How to fix it: First get one image working from one clearly defined source, then add the gallery. For product pages with manually selected images, prevent the recurring feed from updating the gallery. When to roll back: if the remote source is unreliable, disable attachments in the production workflow and restore them only after a reliable file delivery method is agreed on.

Variations were created, but customers cannot select them

Symptom: variation records exist in the admin area, but the product page does not offer a size or color, or the variations are not linked to a parent. Likely cause: the parent product does not exist yet, it has no attributes marked for use in variations, the attribute name differs between rows, the parent relationship is missing, or the parent and child share an SKU.

What to check: Open one parent product and confirm that it is variable and has the complete set of attributes and options. Then open one variation and compare its key, parent relationship, price, and attributes with the source. Check the order of the workflows: parents must exist before variations are imported.

How to fix it: Separate parent and variation imports, map the relationship field in the advanced properties section, and give each object its own key. Test with one parent and two variations instead of the whole catalog. When to roll back: if the feed does not provide a stable way to link variations to a parent, stop the automated variation import and update the source data first.

An ACF field is missing or stored in a format the theme cannot use

Symptom: the field is not listed, text appears in the wrong place, the gallery stays empty, or a repeater shows one incorrect item. Likely cause: the ACF group is not active for the selected post type, the wrong key is being used, the field has a special type, or the input format does not match the expected value.

What to check: Manually create one sample record, fill in the field through ACF, and inspect it in the admin area. Use the ImportWP custom fields preview to see the actual key and current representation. Check the field group's location rules, field type, and documented format for a link, gallery, relationship, date, or repeater.

How to fix it: Start with a plain text field, then add one complex field at a time. Use attachment types for images and files, stable identifiers for relationships, and a suitable repeated XML node or prepared structure for repeaters. When to roll back: if the custom field stores a serialized or special structure that you cannot verify against a sample record, do not publish the bulk result. Return to the small test instead.

A manual run works, but a scheduled run stalls or leaves the data unchanged

Symptom: Run Now completes, but the scheduled workflow stays pending, processes only part of the file, or runs inconsistently. Likely cause: WordPress Cron is not being triggered, the server scheduler is not configured, the time limit is too short, or a large file or its media cannot be processed in one run.

What to check: Review the importer notification, the Waiting on WP Cron status, the last attempt time, and the log. Compare the duration of a manual test with the PHP time limit at Tools → Site Health → Info → Server. Check whether the remote file has changed or now takes longer to download.

How to fix it: First confirm the server execution method with an administrator, then choose a realistic interval and batch size. Split a heavy task into separate imports for core data, media, or variations. Increase the timeout only within the hosting environment's limits and after a test you can observe. When to roll back: if automation leaves the catalog in an unclear state, disable the schedule and return to controlled manual runs until you have reviewed the log.

When CodeCanyon ImportWP Pro is a good fit

CodeCanyon ImportWP Pro becomes a useful operational tool when a team stops treating it as a "upload file" button. Its practical value comes from a clear chain: data source -> WordPress template -> field mapping -> stable identifier -> limited permissions -> outcome verification. That chain makes repeat runs understandable: you know what will be created, what will be updated, and what the workflow is not allowed to touch.

Start with a small file, one data type, and one outcome you can verify. Then confirm the key, run the import again, add complex fields, images, or variations, and only then enable scheduling. If that process fits your workflow, you can download CodeCanyon ImportWP Pro and prepare a test environment. If the source still lacks a stable key, consistent structure, or a clear data owner, address those gaps first. They, rather than the number of settings, will determine whether the import is reliable.