Drupal Feeds for recurring content imports

Setting up Drupal Feeds for recurring imports: when the web interface is enough

If your team must refresh products, events or directory records on a schedule and the source is a regular file or feed, the Feeds module's web interface is usually a sound first choice. Feeds imports or aggregates data into nodes, users, taxonomy terms and other content entities without coding a migration, so editors or site builders can define a source, map its fields to Drupal fields and run the import from the site. The 8.x-3.2 release supports Drupal ^10.2 or ^11, which matches the versions a new build would target. Before committing, confirm on the Feeds project page that the release line you plan to install is still the one maintained for your Drupal version, and check which fetcher and parser plugins it ships with or depends on.

The decision turns on the source format and the data volume. Ask the data owner for a sample export and check whether it is CSV, a structured XML or JSON feed, or something that needs authentication, pagination or custom cleanup. Confirm how each record is identified, because repeat imports depend on a stable unique key to update existing entities instead of creating duplicates. Also confirm how deletions are reported, since a record removed upstream may need to be unpublished or removed by a separate step. Plan for the hosting side too: scheduled imports depend on cron running reliably, and the import's memory and run time should be tested with a realistic file before editors rely on it.

The web interface stops being enough when imports need conditional logic that the mapping screens cannot express, data must be transformed across several linked entities in a fixed order, or failures need automated rollback and detailed reporting. In those cases, a scripted pipeline built on the core Migrate API is the better tool, and the cost moves from configuration to development and testing. A short proof of concept with one real source file will show which side of that line your project sits on. Any quote should separate the Feeds configuration work, the source analysis, the scheduling setup and the test imports, since each drives effort in different ways.

What the Feeds module does for scheduled imports

The Feeds module moves records from an external source into Drupal without a custom migration. Each capability below maps to a decision the content team makes when it sets up a recurring import, from what the records become to how often they refresh.

Entity targets for each record

Feeds imports or aggregates data into nodes, users, taxonomy terms and other content entities. Choose the target before anything else, because it decides which fields exist, how duplicates are matched and who can edit the result. A product feed usually maps to nodes, while a staff directory may map to users. Confirm that the entity type and bundle you need are supported by the importer configuration you plan to use.

Web-based importer configuration

Importers are configured through the Drupal admin interface, so a content team can adjust field mappings without writing a migration class. This suits teams that own the data mapping and need changes made quickly. Keep a record of each mapping change, because a later edit to a field target can silently alter what the next scheduled run writes.

Scheduled, repeatable runs

Importers can run on a schedule, so the site refreshes records without someone clicking import each time. The schedule depends on Drupal cron, which only runs when the site is requested or when a server job triggers it. Confirm how cron runs on your hosting before you promise a refresh interval to the business.

Update and deduplication rules

A recurring import must decide whether an incoming row creates a new entity, updates an existing one or skips it. Set a stable unique identifier from the source, such as a SKU or record ID, and test what happens when a row disappears from the feed. Without this, reruns can create duplicates or leave stale records published.

Source format and parser support

Feeds reads data through parser plugins, and the formats a site can use depend on the parsers installed alongside the module. Do not assume a format is supported because the module can import data in general. Ask for a sample file or endpoint, then confirm the parser, authentication method and encoding before you estimate the work.

Version and compatibility checks

The current Feeds 8.x-3.2 release supports Drupal ^10.2 or ^11. Check that version against your site's Drupal core and the other contributed modules in the importer chain before you plan an upgrade. A feed that works on one core version may need a configuration review after a major upgrade.

Feeds or a scripted Migrate API pipeline: choosing the import tool

The Feeds module suits imports that run on a schedule and are maintained by editors or site builders who want to change mappings through the Drupal interface rather than in code. It imports or aggregates data from sources such as CSV, XML or JSON files into nodes, users, taxonomy terms and other content entities without a coding step for each change. The 8.x-3.2 release supports Drupal ^10.2 or ^11, so confirm that version against your core before planning.

Configured mappings: Field mappings, processors and update behavior are set in the administration interface and exported with configuration management.
Scheduled runs: Imports run on cron, which means the site's cron must be reliable and monitored.
Editor ownership: Site staff can adjust a mapping when a supplier renames a column, without a developer deployment.
Limits on logic: Complex conditional transformations or multi-step lookups quickly become hard to read in the interface.
Source changes: Feed format changes still need someone who understands the source file, even when the mapping itself is simple.

Check whether your source format, volume and update frequency fit a configured feed before you accept the interface as the long-term maintenance path.

Configuration decisions for Feeds importers

This table compares the eight decisions that shape a Feeds importer, with the options for each, when they fit and what happens if the default is accepted without review. Read it before building the first importer, then confirm each default against the Feeds version installed on your site, since behavior and settings names can change between releases.

Decision	Options and when each fits	Risk if left to default
Source type and location	Remote file or feed URL for scheduled pulls, or a local upload for one-off loads. Remote sources suit a vendor export that refreshes daily. Confirm which fetcher and parser types the installed version ships with and how credentials are stored.	Credentials or URLs end up in plain configuration, and a changed export path silently imports nothing.
Target entity and bundle	Choose the content type, user, or taxonomy term bundle that matches how editors will search and publish the records. For product or event data, a dedicated content type usually fits better than reusing a generic page type.	Records land in a catch-all bundle, so fields, permissions and views have to be reworked after the first import.
Unique key and update behavior	Map a stable source identifier to a unique field so reruns update existing items. Decide whether changed fields overwrite Drupal edits, and whether editor changes on imported nodes should be protected.	Reruns create duplicates, or they overwrite manual corrections without warning.
Field mapping and transformations	Map each source column to a target field, and use available transformations for dates, time zones, text formats, references and images. Check how multi-value and reference fields behave when the source is empty or malformed.	Dates shift by a time zone, references fail quietly and unformatted HTML reaches the page.
Scheduling through cron or the queue	Cron-driven runs fit small feeds on a predictable schedule. Queue-based processing fits large files or where cron runs are limited. Verify how the installed version batches work and whether a run can overlap the previous one.	Long imports time out, runs overlap and records are only partly updated.
Deletion of records missing from the source	Decide whether an item absent from a later file is unpublished, deleted or left alone. Confirm the installed version's options for expiring or removing missing items before enabling them.	Stale records stay live indefinitely, or a partial export removes valid content.
Author and ownership assignment	Assign imported nodes to a service account or a named owner, and decide whether that owner can edit them. Ownership affects revision history, moderation and audit trails.	Imported content is attributed to whoever ran the import, which confuses editorial accountability.
Error reporting	Use the import log and status messages for small teams, and add notifications or a monitored report for scheduled runs. Confirm where rejected rows are recorded and whether they can be exported for correction.	Failed rows are skipped without notice, and the site shows last month's data as current.

Rollout sequence for a recurring Feeds import

The sequence moves a Feeds import from sample files to a monitored scheduled job that editors have approved. Each step closes with a written artifact, so the import can be audited, handed over and rerun after a Drupal upgrade.

Analyze the source and collect sample files
Obtain the real export or feed from the data owner, along with a sample set that includes typical rows, empty fields, duplicates, malformed records and deleted items. Record the format, encoding, delimiter, update frequency, column meanings and who maintains the source. The output is a source analysis note that lists every field, its owner and any known quality problems. The step is done when the data owner has confirmed the sample represents production rather than a cleaned extract.
Design the content model and field mapping
Decide which Drupal entity each record becomes (node, user, taxonomy term or another content entity) and which content type or bundle it uses. Map each source column to a target field, with the transformation rules for dates, time zones, references to taxonomy terms, file URLs and multi-value fields. Decide the unique key that identifies a record across runs, since that key controls whether a re-import updates or duplicates content. The output is a mapping specification signed off by the content owner and the developer who will maintain the importer.
Configure the importer on a non-production site
Build the content type or fields if they do not exist, then create the Feeds importer on a staging copy of the site with the same contributed module versions as production. Configure the fetcher, parser, processors and update behavior to match the mapping specification, and confirm the Feeds release supports your Drupal version. Keep the importer configuration in configuration management so it can be exported and reviewed. The output is a working importer configuration committed to version control.
Run test imports with edge cases
Run the importer against the sample files, then against deliberately broken copies: missing required values, duplicate keys, changed row order, removed records, unexpected characters and oversized files. Check that re-running the same file creates no duplicates and that removed source records are handled as the mapping specifies. Log each run's created, updated, skipped and failed counts. The output is a test report listing each case, the expected result, the observed result and any changes made to the configuration.
Verify scheduling and cron behavior
Set the import to run on the schedule the data owner needs, then confirm that Drupal's cron runs reliably in the hosting environment and that the import does not overlap with a previous run still in progress. Test a run that fails partway through, and check that the next scheduled run recovers without manual cleanup. Confirm which system user runs the job and what permissions it holds. The output is a scheduled job record that names the frequency, the cron mechanism, the executing account and the verified recovery behavior.
Obtain editor review and sign-off
Give the content team a staging sample of imported content and a checklist covering titles, dates, references, images and any records that should be skipped. Ask them to flag incorrect or missing values and to confirm how they will correct imported content, since a later import may overwrite manual edits depending on the update setting. Record the decisions taken. The output is a signed review record that states the accepted behavior and the owner of each open issue.
Cut over to production and write the runbook
Deploy the same configuration to production through the standard release process, run one supervised import, and compare the counts and sample records against the staging report. Confirm rollback steps, such as how to disable the schedule and how to restore or unpublish imported content in bulk. Write a runbook covering the schedule, the source contacts, the failure messages and the escalation path. The output is a production run log and a runbook that operations staff can follow without the original developer.
Monitor the import and review it after updates
Set up alerts or log checks for failed runs, unusually low or high record counts, and growth in skipped rows, and review them on a regular schedule agreed with the data owner. Re-test the importer after each Drupal core or Feeds update, since the release schedule brings bugfix and security releases on fixed Wednesdays and major versions on a longer cycle. The output is a monitoring record and a change log entry for every update that was tested against the importer.

Preparing source data and content models before the first import

Before the first Feeds import runs, the team has to decide how every field in the source file maps to a field on a Drupal content type, and which field identifies a record as the same item on the next run. Feeds does not infer a content model from the file. An importer is configured against existing content types, vocabularies and entity reference fields, so a product, event or directory record that has no matching home in Drupal will either be dropped or stored in the wrong place. Start by listing each source column, its data type, whether it is required, and the Drupal field it will feed. Pay particular attention to the source's unique identifier, because the importer's unique target setting is what lets a re-run update an existing node instead of creating a duplicate. Confirm with your own export that this identifier is stable over time and never reused.

Referenced entities need the same care. An event that points to an organizer or venue usually depends on a separate content type or taxonomy vocabulary that must be populated first, or the reference will fail to resolve. Decide whether a missing organizer should create a new term, be skipped, or stop the row, and write that rule down before the importer is built. Taxonomy values in the source, such as category labels with different spellings or casing, should be normalized or mapped to an approved list, since Feeds matches terms by name and inconsistent values create near-duplicate terms. Validation belongs in the same plan: required Drupal fields, date formats and time zones, and value ranges should be checked against the file, and rows that fail should be reported rather than silently saved. Media and image references need a separate decision. Confirm whether the source supplies a file URL, a file path or an identifier, whether the importer will fetch and store the file on each run or only when it changes, and who owns the rights to the images. Test a sample file with real edge cases, including duplicates, empty required fields and missing images, before you schedule anything.

If the source data is coming from an older Drupal site, check the version first. Drupal 7 security support ended on January 5, 2025, and Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. They are moved into a new site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush, and themes must be rebuilt. That migration is a different project from a recurring feed, and its mapping work should be done with the core Migrate API rather than Feeds. The Drupal.org migration documentation describes the path. Once the content model is settled, record it in configuration management so the importer, the fields it writes to and the validation rules stay in step across environments. Confirm each detail against your own data and your Drupal version before relying on it.

How scheduled imports connect to the rest of the Drupal platform

A Feeds import writes entities directly, so it touches moderation, search indexes, scheduled publishing, commerce data, geographic fields and the cron and queue machinery that runs it. Each connection below is a place where an import can look successful while the rest of the site shows stale or incomplete data.

Imported content skipping moderation

Feeds creates or updates nodes through the entity API, so content can bypass the review path your editors rely on if the importer sets published status directly. Decide per content type whether imported items should land as drafts under Content Moderation, and confirm that the importer's user account holds the permissions that moderation expects. Test one import with a real editorial state before enabling the schedule.

Search indexes not refreshing

Search API tracks changes through its own item tracking, and bulk writes from a scheduled import can leave the index behind the database until the next indexing run. Check that the index is set to index on cron or through a queue, and that the import finishes before indexing starts. Otherwise, catalog or directory searches will return last week's records with no error shown.

Publishing dates set by imports

Imported rows that carry publish and unpublish dates depend on Scheduler, which acts during cron runs and compares times in the site's configured time zone. Confirm that the source file's dates are in a known time zone, and that the import maps them to the fields Scheduler reads. A timing mismatch can publish an event early or leave an expired record live.

Commerce product data overwriting prices

Product variations and prices in Drupal Commerce are entities with their own storage and validation, so a feed that updates SKUs can overwrite price, currency or stock values that the store relies on. Map each column to a specific field, decide which system owns price data, and reconcile a sample of variations against the source after each run. Limit write access on the importer account to the fields it is meant to change.

Geofield coordinates from directory rows

Directory and store-finder records need latitude and longitude values in a Geofield field, and source files often carry addresses without coordinates or with swapped values. Decide whether geocoding happens before the import or in a separate step, and reject rows whose coordinates fall outside the expected region. Proximity search and maps will otherwise place locations in the wrong spot without any import error.

Cron and queue capacity for imports

Feeds runs its fetch and process steps through Drupal's cron and queue systems, so a long import can delay other cron tasks, including indexing and Scheduler, or stop mid-run when a request times out. Schedule imports on a dedicated cron or queue worker, record run times and row counts, and confirm that a failed run can be retried without duplicating records.

Unvetted external sources

Object storage buckets, SFTP drops and third-party APIs feed the importer with files and credentials that the Drupal team does not control. Use dedicated, least-privilege credentials for each source, store them outside the codebase, and validate file type, size and column structure before any row is processed. Treat the source as untrusted input and log every file the importer accepts.

What drives the effort and cost of a Feeds import project

This table lists the factors that change how much work a recurring Feeds import takes, how each one moves effort up or down, and what to request in a written quote. Read each row as a question to answer before scoping, since the same import can be small or large depending on these inputs.

Driver	Why it changes effort	What to ask for in a quote
Number of source formats	Each format (CSV, XML, JSON, spreadsheet export) needs its own parser settings and sample handling. Mixed formats multiply test cases.	Named list of formats, sample files for each, and which parser configuration is assumed for each.
Source data quality and consistency	Missing values, changing column headers and inconsistent codes push work into mapping rules, validation and exception handling.	Written statement of which data defects are expected, who fixes them at source, and whether rejected rows are logged or held.
Content types and taxonomies touched	Every node type, user role, vocabulary or entity reference in the feed adds mapping, field validation and permission checks.	Inventory of target entity types, bundles and vocabularies, with the fields each import writes.
Transformation complexity	Splitting values, looking up referenced terms, computing fields or combining several source rows into one entity require custom processing.	Description of each transformation rule and whether it is configured in the interface or needs custom code.
Volume and run time	Large files or frequent runs raise batch sizing, queue behavior and time windows, and may require tuning for memory and timeouts.	Expected row counts per run, file size range, run frequency and the acceptable completion window.
Deletion and update rules	Deciding how changed rows update existing entities, and when missing rows unpublish or delete content, is one of the most review-heavy decisions.	Written rule for matching existing records, handling removed rows, and who approves deletions.
Editor review needs	If imported content must be checked before publication, the project needs unpublished staging, moderation states and notification steps.	Whether imports publish directly or enter a review state, and which roles approve them.
Hosting and cron capacity	Feeds runs on Drupal cron and queues. Shared hosting, slow cron or limited memory make scheduled imports unreliable and add tuning work.	Confirmation of the hosting platform, cron method (system or external trigger), PHP memory and time limits, and monitoring of failed runs.
Number of environments	Each environment needs the import definitions, test feeds or sandbox data, and a repeatable way to move configuration between them.	Number of environments in scope, how configuration is deployed, and whether test data is masked or synthetic.

Questions teams ask before scheduling imports into Drupal

Can Feeds import our data into Drupal without custom code?

Yes, for many common cases. Feeds imports or aggregates data into nodes, users, taxonomy terms and other content entities through a web interface, so editors or site builders can configure a feed without writing a migration. The fit depends on the source format, how records map to fields, and how duplicates are detected. The 8.x-3.2 release of Feeds supports Drupal ^10.2 or ^11, so confirm that your target site runs one of those versions before you plan around it. Feeds handles straightforward mappings well. Complex transformations, multi-step lookups or large volumes usually need custom code, which is where the scope changes.

When is a Migrate API pipeline a better choice than Feeds?

A scripted Migrate API pipeline fits better when the import needs logic that is hard to express in the interface. Typical triggers are several linked source systems, transformations that depend on other records, rollback and reprocessing rules, strict validation before anything is written, or a need to version the import logic in source control. Pipelines are built with the core Migrate API and are code-reviewed and tested like any other custom module. Feeds is quicker to set up and easier for content teams to adjust, but every rule an editor cannot change without a developer is a sign that a pipeline may be the better tool.

What drives the cost and effort of a fixed-scope import?

The main cost drivers are the number of source systems, the quality and consistency of the source data, the number of content types and fields that receive data, the amount of transformation logic, and the duplicate and update rules. Scheduling, error reporting and access control add further work. Cost is one-time for the build and recurring only where an operations or support arrangement is chosen. Ask any partner for a written scope that lists each source, each target field, the schedule, the failure handling and the test data used for acceptance. Those items determine the quote far more than the choice of tool.

What does our team need to provide for an import project?

Plan for four inputs: read access to the source system or export process, a set of representative sample files that include messy and edge-case records, named data owners who can decide how conflicts and missing values are handled, and a staging Drupal environment where imports can be run safely. You also need a clear definition of which record is authoritative after each run and who approves the mapping. Delays usually come from unclear data ownership or from samples that do not match production exports, so settle both before the build starts.

Can our in-house team run recurring imports after they are built?

Often yes, provided the team can read Drupal logs, manage cron or the scheduler, and handle the module updates that come with each release. Feeds is a contributed module, so it needs routine updates and compatibility checks when Drupal core moves to a new major version. Drupal 10 reaches end of life on December 9, 2026, so an import built now should be checked against the Drupal 11 and Drupal 12 plans. Confirm internally who owns failed-run alerts, source changes and reruns, because most import problems after launch come from a source change nobody was told about.

How long does a fixed-scope import engagement take?

Duration depends on the written scope, so it must be confirmed in a quote. The main variables are the number of sources, the amount of mapping and transformation work, how clean the sample data is, how many review cycles the data owners need, and whether the import runs on a schedule that must be tested over several cycles before sign-off. Ask for a timeline that separates discovery, build, testing against real samples, cutover and handover, so you can see where any slippage would come from.

What happens to our imports after launch?

Imports need ongoing attention. Source formats change, schedules drift, and Drupal and contributed modules receive security and bugfix releases, which arrive on the first Wednesday of each month for bugfixes and the third Wednesday for security releases. Decide before launch who reviews failed runs, how source changes are communicated, and how updates are tested on staging. DeployOpen can plan, implement, document and support these imports inside your own infrastructure, and ongoing support, upgrades and testing are available as retainers. Ask for the handover documentation and the support terms in the written scope.

What to hand over and keep after the first scheduled run

The first scheduled run is the point where the import stops being a project and becomes a service someone must own. Before the project closes, the handover pack should contain the importer configurations exported as configuration, so that each Feeds importer (its fetcher, parser, processor and mapping settings) can be reviewed, versioned and restored from source control rather than rebuilt from memory. Alongside that, hand over a mapping specification that lists every source column, its target field on the content entity, the transformation applied and the owner of the source field. Add a source file contract that states the expected file name or endpoint, delimiter or format, encoding, column headers, update key and the behavior when a column is missing. Without that contract, the next change made by the data owner will fail silently or create duplicates.

The runbook should cover what the operator does when a run fails: where the Feeds import status and the Drupal log (the Recent log messages report in the admin interface) show the error, how to re-run a single import safely, how to identify and roll back partially imported records, and when to escalate. Monitoring must cover cron and the queue, because Feeds work depends on both running on schedule. Record the cron mechanism, its frequency, the queue worker settings, the log locations on the web and database hosts, and named owners for the source data, the Drupal site and the hosting environment. Confirm the owners in writing, with a backup contact for each. The update routine should be on the calendar from day one. Drupal bugfix releases arrive on the first Wednesday of each month and security releases on the third Wednesday, according to the Drupal core release schedule, so the operator needs a standing test window for both. Check the Feeds release notes against the Drupal version in use: the 8.x-3.2 release supports Drupal ^10.2 or ^11. Drupal 11 requires PHP 8.3 or later, and Drupal 10 reaches end of life on December 9, 2026, so confirm the PHP version on your hosts now and plan the Drupal 10 to 11 move before that date. Ask the partner to confirm the Feeds and Drupal version pairing in your environment before handover.

How DeployOpen scopes and delivers Drupal Feeds imports

DeployOpen plans, builds, documents and supports Drupal Feeds imports inside your own infrastructure, from the first source review to a tested schedule. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Review each source file or feed, its format, update frequency and field mapping before any importer is configured.
Agree in writing which content types, users or taxonomy terms each import creates, updates or deletes.
Confirm the Drupal version, PHP version and hosting constraints so the Feeds release matches your platform.

How we build

Configure Feeds importers through the web interface where the mapping is simple and the team will maintain it.
Build custom Migrate API pipelines where data volume, transforms or validation rules exceed what Feeds handles well.
Test each import against copies of real source files, checking duplicates, failed rows and cron timing.

How we hand over

Deliver written runbooks covering schedules, source credentials, expected errors and how editors re-run an import.
Document each mapping, deduplication key and custom code path so your team can change them safely later.
Walk your administrators through monitoring, log review and the steps for rolling back a bad import.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
Track Drupal core and Feeds releases so import jobs keep running through planned version upgrades.
Confirm with your team which support tier, response expectations and contacts apply before go-live.