# farmOS Demo Records Module **URL:** \ **Category:** Development\ **Created:** [September 17, 2026, 9:13pm UTC](https://farmos.discourse.group/t/farmos-demo-records-module/2606 "2026-09-17T21:13:41Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [September 17, 2026, 9:13pm UTC](https://farmos.discourse.group/t/farmos-demo-records-module/2606/1 "2026-09-17T21:13:41Z")
We started a new farmOS Demo Records (`farm_demo`) module on the development call today. The goal is to be able to easily populate a farmOS instance with data (asset and log records) that mimic a real operation. We may continue working on this together in the upcoming weekly dev calls. Anyone who is interested is welcome to join the process! We can use this forum topic to track progress, and invite ideas from folks who are unable to join the calls. Here is the project on [drupal.org](http://drupal.org): [Client Challenge](https://www.drupal.org/project/farm_demo) It can be installed with `composer require drupal/farm_demo`. Previous discussions: - [Example Data for FarmOS](https://farmos.discourse.group/t/example-data-for-farmos/86) - [farmOS Demo Data](https://farmos.discourse.group/t/farmos-demo-data/999) ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [September 17, 2026, 9:28pm UTC](https://farmos.discourse.group/t/farmos-demo-records-module/2606/2 "2026-09-17T21:28:17Z")
A few notes from today’s discussion: - What demo data should be created? - How should we store/manage the demo data? 1. CSVs that can be imported via the `farm_import_csv` module? 2. YML files that can be imported via the [Default Content](https://www.drupal.org/project/default_content) module? - What should trigger the data creation? 1. Automatically when the module is installed? 2. Manually by clicking a button in the UI? 3. Via Drush CLI commands? 4. … other? - How do we handle “shifting dates” so that the demo data appears “current”? (if the demo data has a timestamp in 2026, but someone installs it in 2036, we should shift the data to the present) - Do we need to be able to clean up (delete) demo data? - What happens if other records reference it? - Or do we just put a big warning somewhere? “Don’t use this on a real database!” - Can this tie into the setup wizard somehow? - The idea: the demo module may install certain modules to generate the data, and someone might want to start fresh with the same modules installed. - Conventions! - This module will naturally be following some [conventions](https://farmos.org/model/convention/), so maybe it’s an opportunity to [document them](https://farmos.discourse.group/t/documenting-conventions/1263) too. ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [September 17, 2026, 9:32pm UTC](https://farmos.discourse.group/t/farmos-demo-records-module/2606/3 "2026-09-17T21:32:14Z")
> [@mstenta](#): > > - What demo data should be created? This is the list I made on today’s call (certainly incomplete!)… ```auto - farm_demo_land - land assets (fields) - farm_demo_plant - plant assets - seeding logs - observation logs - input logs - harvest logs - quick planting form - farm_demo_animal - animal assets - medical logs - observation logs - birth logs - harvest logs - birth quick form - movement quick form ... ``` Note: when I wrote that we were thinking about including multiple sub-modules (eg: `farm_demo_land`, `farm_demo_plant`, `farm_demo_land`) which each generate certain sets of data when they are installed. But, now I’m leaning more towards this approach: > [@mstenta](#): > > - What should trigger the data creation? > 1. … > 2. Manually by clicking a button in the UI? > 3. Via Drush CLI commands? We could provide a simple settings form with options for generating data (and installing modules for it automatically). We could also provide Drush commands, to do the same thing. The Drush commands would allow for some useful automated testing / CI options. ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [September 17, 2026, 9:42pm UTC](https://farmos.discourse.group/t/farmos-demo-records-module/2606/4 "2026-09-17T21:42:06Z")
> [@mstenta](#): > > - How should we store/manage the demo data? > 1. CSVs that can be imported via the `farm_import_csv` module? > 2. YML files that can be imported via the [Default Content](https://www.drupal.org/project/default_content) module? In the past, we’ve talked a lot about leveraging the [Default Content](https://www.drupal.org/project/default_content) module for this, but now I’m starting to think more about the CSV option… Some advantages to the CSV approach: 1. CSV is more approachable than YML. This will make it easier for folks to contribute to this project. You can open a CSV as a spreadsheet. 2. CSVs can be imported with the `farm_import_csv` module, which we already have. No new dependencies. And it means they can be tested easily, so someone who wants to contribute can make sure it works before suggesting new data. 3. The module could potentially provide custom CSV import templates and logic, so we have some flexibility with the CSV schema to make it very simple (or very complex!) [CSV importers | farmOS](https://farmos.org/development/module/csv/) Other considerations: - Date-shifting might be easier in the CSV import process than in the Default Content import process… (needs more investigation). CSV import uses Migrate API which has the ability to preprocess the date fields to modify them on import. - Default Content creates content when a module is installed. It might be possible to trigger it programmatically instead… (needs more investigation). CSV import/migration can be done programmatically (we already do it in automated tests). ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [September 17, 2026, 9:45pm UTC](https://farmos.discourse.group/t/farmos-demo-records-module/2606/5 "2026-09-17T21:45:05Z")
Another advantage of CSVs: We can point people to the CSV files in this repository as examples to reference if they are importing their own data via the CSV importers. ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [September 17, 2026, 10:05pm UTC](https://farmos.discourse.group/t/farmos-demo-records-module/2606/6 "2026-09-17T22:05:38Z")
Question that just came to mind… I’m assuming that one of the first things we’ll want to provide is a set of Land assets. Ideally these would include geometry. What geometries should we use? There are privacy/PII considerations here, potentially. Does someone want to volunteer their own geometries (and attest that they indeed have the ability to offer them publicly, knowing that they will forever be visible in a public Git history)? Do we auto-generate geometries randomly? This side-steps the privacy issue, at the expense of a cohesive demo. It would be weird to see some geometries appear in the ocean, for instance. Other thoughts? ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [September 17, 2026, 10:09pm UTC](https://farmos.discourse.group/t/farmos-demo-records-module/2606/7 "2026-09-17T22:09:26Z")
> [@mstenta](#): > > What geometries should we use? There are privacy/PII considerations here, potentially. There are some good suggestions related to this in [Example Data for FarmOS](https://farmos.discourse.group/t/example-data-for-farmos/86) Quotes: > [@Example Data for FarmOS](https://farmos.discourse.group/t/example-data-for-farmos/86/16): > > Some of the parishes within England (eg Brighton) share kml files of all the council-owned agricultural land, which we may be able to use as a starting point. I’m not sure how receptive the council will be! > [@Example Data for FarmOS](https://farmos.discourse.group/t/example-data-for-farmos/86/17): > > One approach that might work would be to find a publicly managed location that is being operated as a farm. For example, there seem to be a few living history museums built around historical farms. We could try reaching out to [https://alhfam.org](https://alhfam.org) or a similar organization to see if they know of a historical farm with an existing rich GIS dataset in the public domain or with a permissive license. (From either historical or present-day farming activities.) > [@Example Data for FarmOS](https://farmos.discourse.group/t/example-data-for-farmos/86/18): > > I was wondering about Universities / Colleges as well - most have research farms and may have datasets that are public use. ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [September 24, 2026, 4:49pm UTC](https://farmos.discourse.group/t/farmos-demo-records-module/2606/8 "2026-09-24T16:49:03Z")
Notes from today’s call: - Agreement that CSVs seem to be a good approach (for the reasons listed above). - Might be easiest to start simple and just create everything all at once (land, plants, animals, etc), rather than creating separate “sets” of data per-use-case - that can be split up in a v2, perhaps. - @mstenta is working on the basic architecture of the module (UI, Drush command, CSV importer integration, date shifting process plugin). - In the meantime we can start collecting some sample date. This can be done async by anyone who wants to help, just by creating and testing some CSVs with the existing CSV importer. Any volunteers? 🙂