# Looking for guidance on farmOS crop planning & conventions (farmer-led project) **URL:** \ **Category:** Community\ **Created:** [January 31, 2026, 2:44am UTC](https://farmos.discourse.group/t/looking-for-guidance-on-farmos-crop-planning-conventions-farmer-led-project/2466 "2026-01-31T02:44:31Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![MiddleWorld](https://avatars.discourse-cdn.com/v4/letter/m/ac8455/32.png) [@MiddleWorld](https://farmos.discourse.group/u/MiddleWorld)\ **Post date:** [January 31, 2026, 2:44am UTC](https://farmos.discourse.group/t/looking-for-guidance-on-farmos-crop-planning-conventions-farmer-led-project/2466/1 "2026-01-31T02:44:31Z")
Hi everyone 👋 I hope it’s OK to share something a bit personal and a bit technical. I’m Martin, a farmer in the UK running a small ecological, direct-to-public farm. We use **farmOS** at the core of our operation, and I genuinely believe it’s one of the most important open-source tools agriculture has. Over the last year I’ve been building an open-source project called **Symbiosis** , very deliberately _around_ farmOS — not instead of it. The aim is to extend farmOS into areas that small, direct-selling farms often struggle with most: **crop planning tied to reality** , and **integration with ecommerce** (subscriptions, orders, packing, delivery). The repository is here if it helps with context: [https://github.com/Middleworld/symbiosis-farm-management](https://github.com/Middleworld/symbiosis-farm-management?utm_source=chatgpt.com) I should be upfront: I’m not a professional developer. I’m a farmer who’s “vibe-coded” this with a lot of determination, a lot of late nights, and a lot of help from AI. I’ve also had a serious neck operation recently, which has pushed me more into admin/software work than I ever planned — but I’m not about to give up on this. ### **What _does_ work** - **WordPress + WooCommerce** is largely working: subscriptions, orders, admin workflows, and a custom admin layer that normalises orders and produces packing / harvest outputs. - **farmOS at the centre** : the admin app embeds the farmOS desktop in an iframe (same domain), so staff use one login and move between farmOS and the rest of the stack without separate OAuth flows. Harvest logs and other farmOS views are embedded where needed. - **Succession planning (Symbiosis side)**: backward planning from harvest windows using live farmOS taxonomy (plant types, varieties, harvest windows, season types), planning by bed and date, and batch creation of seeding / transplant / harvest logs in farmOS. - **Crop planning & harvest views** : planting charts, crop-plan timeline, embedded farmOS harvest logs, and stock syncing. - **Field Kit + quick forms** integrated into the workflow. - **Shared vocabulary** : taxonomy synced from farmOS so planning, admin, and harvesting all use the same terms. Overall, the architecture feels sound, and farmOS is very clearly the right **“farm operating system”** at the centre. ### **Where I’m stuck** The hardest part — and the part I can’t realistically finish alone — is the **farmOS side** , especially: - crop-planning gaps (I know the existing crop-planning add-on is incomplete — if it wasn’t, I wouldn’t be here), - aligning real-world, bed-based planning with farmOS entities and logs, - clean ways of importing or syncing planning data (CSV / JSON:API), - and generally finishing that last 20% that only people who really know farmOS internals can see clearly. ### **Conventions framing** One thing that’s become clearer to me is that Symbiosis is really acting as a **conventions layer** — an opinionated, documented way of using the existing farmOS data model for bed-based, ecological, direct-market farms — rather than something that belongs in farmOS core itself. In that sense, I don’t see Symbiosis as competing with or replacing farmOS crop planning, but as a possible **reference implementation of a crop-planning convention** , with tooling built around it. I’d really value guidance on whether this framing makes sense, and how best to align what I’ve built with farmOS’ conventions-first approach. ### **What I’m asking for** I’m not looking for someone to take this over, redesign it, or turn it into a product. What I _am_ hoping for is: - advice from people who know farmOS well, - pointers on the “right” way to model or extend crop planning, - and possibly one or two people interested in collaborating or reviewing specific pieces of the farmOS integration. This is an open-source, farmer-led project intended to benefit exactly the kind of farms farmOS exists for — small, ecological, direct-to-consumer growers who sit awkwardly between “market garden” and “enterprise ag”. I’ve put too much of myself into this to walk away, and too much respect into farmOS to try and hack around it blindly. If this resonates with anyone here, I’d be incredibly grateful to talk — even if it’s just to sanity-check direction. Thanks for reading, Martin 🌱 ---
**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:** [February 2, 2026, 1:10pm UTC](https://farmos.discourse.group/t/looking-for-guidance-on-farmos-crop-planning-conventions-farmer-led-project/2466/2 "2026-02-02T13:10:46Z")
Hi Martin! Thanks for sharing, and for the kind words about farmOS! This sounds like an exciting project! And it sounds like the design and responsibility of each piece makes sense! 🙂 > [@MiddleWorld](#): > > One thing that’s become clearer to me is that Symbiosis is really acting as a **conventions layer** — an opinionated, documented way of using the existing farmOS data model for bed-based, ecological, direct-market farms — rather than something that belongs in farmOS core itself. Great! This is exactly the kind of thing I’d like to see sprout up in the community: opinionated and prescribed workflows for a specific use-case built on top of the data model. > [@MiddleWorld](#): > > The hardest part — and the part I can’t realistically finish alone — is the **farmOS side** , especially: Happy to point you in the right direction where I can, or brainstorm next steps in the Crop Plan (or other) module(s). If you’re able to hop into one of the weekly dev calls, or the farmOS chat room, I can bring you up to speed on where things stand. ---
**Author:** ![MiddleWorld](https://avatars.discourse-cdn.com/v4/letter/m/ac8455/32.png) [@MiddleWorld](https://farmos.discourse.group/u/MiddleWorld)\ **Post date:** [February 3, 2026, 1:58pm UTC](https://farmos.discourse.group/t/looking-for-guidance-on-farmos-crop-planning-conventions-farmer-led-project/2466/3 "2026-02-03T13:58:52Z")
Thanks Michael — that’s really helpful, and I appreciate the guidance. One practical issue we’ve run into, which might help frame some of our questions: We’re struggling to find usable API touchpoints around crop planning itself. In other areas of farmOS, we’ve been able to interact cleanly via the API, but crop planning feels much more UI-driven. Our usual approach of embedding or extending functionality via iframes hasn’t worked well here, and at the moment we can’t see a clear way to reliably send data into or out of crop planning through the API. Is crop planning currently intended to be API-addressable, or is it still primarily designed as an internal UI workflow? And if API interaction is the right direction, are there specific entities or patterns you’d recommend building against (or avoiding) at this stage? We’re keen to stay aligned with intended conventions rather than forcing an integration that might fight farmOS long-term. ---
**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:** [February 3, 2026, 2:27pm UTC](https://farmos.discourse.group/t/looking-for-guidance-on-farmos-crop-planning-conventions-farmer-led-project/2466/4 "2026-02-03T14:27:49Z")
> [@MiddleWorld](#): > > Is crop planning currently intended to be API-addressable, or is it still primarily designed as an internal UI workflow? If you’re talking about the [farmOS Crop Plan](https://www.drupal.org/project/farm_crop_plan) module, specifically, then I wonder if you are running into this known issue: > > > \*\*Describe the bug\*\* > I receive 403 errors when attempting to create new PlanRec…ords via the API, even for Plans which I have update access to. > > \*\*To Reproduce\*\* > Steps to reproduce the behavior: > 1. Try to POST to create a plan\_record for a plan of any type > > \*\*Expected behavior\*\* > I expect a 201 successful creation response, but instead receive a 403 error. > > \*\*Desktop (please complete the following information):\*\* > - Windows 11 + WSL2 > - Chrome, but I also see this issue in Postman > - Chrome version 128.0.6613.138, farmOS version 3.2.3 > > \*\*Additional context\*\* > Here's the body of the request that's failing (this specific body is for a custom plan and plan record type but I get this error for plans and plan records of any type; the plan id is for an active plan that I can successfully PATCH to): > \`\`\` > { > "data": { > "type": "plan\_record--sample\_site", > "attributes": { > "site\_id": "LARA.24.RP.01", > "indicators": \[ > "SOC,Soil organic carbon (SOC)", > "BD,Bulk density (BD)" > \] > }, > "relationships": { > "plan": { > "data": { > "type": "plan--ag\_c\_project", > "id": "cdda83eb-a759-42ed-b8db-bb773f27eab4" > } > }, > "site": { > "data": { > "type": "asset--land", > "id": "48108a58-008d-4927-bfc3-25fcb27fea12" > } > } > } > } > } > \`\`\` Tl;dr: it isn’t currently possible to create `plan_record` entities via the API. This thread has some good general information about the crop plan data model, as well as a link to that issue, and a temporary workaround that you can use to patch the issue for now. We still need to come up with a proper long-term fix. > [@Cannot find plant assets from crop plan API](https://farmos.discourse.group/t/cannot-find-plant-assets-from-crop-plan-api/2311): > > Hello, I am experimenting on crop plans and hoping to programmatically create/add/edit crop plans through an API. Here is the screenshot of the crop plan I manually created from UI. . I can get the plan information by /api/plan/crop endpoint. However, when I requested details on a specific plan by api/plan/crop/{plan\_uuid}, I could not see information about plant assets. The return from API is below { "jsonapi": { "version": "1.0", "meta": { "links": { "self":… > [@MiddleWorld](#): > > at the moment we can’t see a clear way to reliably send data into or out of crop planning through the API. I’m curious what issues you ran into with “reading” data… that should work normally. But it is important to understand how the crop plan models things. It uses a `plan` entity (of bundle `crop`) to represent the plan itself, and then it uses `plan_record` entities (of bundle `crop_planting`) that connects the `plan` to individual `asset` entities (of bundle `plant`). The `plan_record` also contains some metadata about that relationship, which is specific to the plan, including planned seeding date (`seeding_date`), expected days to transplant (`transplant_days`), expected days to maturity (`maturity_days`), and expected harvest window (`harvest_days`). These represent the “planned” or “expected” lifecycle of each `plant` asset… but the `plant` asset itself, and the logs associated with it, represent the “actual”. More information about the crop plan module in general, if you haven’t seen it, is here: > [@farmOS Crop Plan module v3 alpha release](https://farmos.discourse.group/t/farmos-crop-plan-module-v3-alpha-release/1934): > > I’m pleased to announce that we just released the first “alpha” version of the farmOS v3 Crop Plan module! tada Read the release notes in that link for more information and to understand what to expect (and what not to expect sweat_smile). It’s safe to install this and start playing around with it, but it’s important to understand that this is still just a proof-of-concept. We have the basic data architecture nailed down (but there’s more to do!) an…