| [10:10:17] | * farmBOT has joined #farmos |
| [11:36:33] | <paul121[m]> | shane_aldrich: did you make any progress on this? |
| [11:37:02] | <paul121[m]> | You shouldn't need the plugin system, I think you're just wanting to make fields that reference the `material_type` vocabulary ? |
| [11:52:50] | <mstenta[m]> | I wasn't able to chime in yesterday, but for context I think shane_aldrich is interested in adding a few fields to the `fungi_type` vocabulary, which is provided by the `farm_fungi` module: https://git.drupalcode.org/project/farm_fungi/-/blob/2.x/config/install/... |
| [11:52:57] | <mstenta[m]> | Specifically `genus` and `species` fields |
| [11:53:45] | <mstenta[m]> | This could be done in his `farm_shane_fungi` module to start, and/or we could open an upstream issue to consider adding them directly to the `farm_fungi` module |
| [11:54:28] | <mstenta[m]> | In either case, it will probably be similar to the way that we added fields to the `plant_type` terms in core |
| [11:56:51] | <mstenta[m]> | (thinking bigger, it also reminds me about this issue: https://www.drupal.org/project/farm/issues/3190851) |
| [11:57:33] | <mstenta[m]> | shane_aldrich: I wish I could easily summarize all the considerations there, but it's a bit of a dive into the deep end :-) |
| [11:58:18] | <mstenta[m]> | for your immediate purposes the simplest approach is to add YML config files for the fields you want to add - either to your module or to `farm_fungi` directly (although I might be inclined to suggest starting it in your module) |
| [11:59:19] | <mstenta[m]> | (if you start them in your module, you can open an issue in your repo to "look ahead" to what the transition will look like if/when they move to `farm_fungi` - this might be a good exercise in understanding how that process works more generally) |
| [13:57:11] | <shane_aldrich[m]> | I'll be in and out today. Need to do some shopping and work on transferring files amongst my external hard drives. I really need to get a regular backup schedule going so I don't lose anything. |
| [13:57:11] | <shane_aldrich[m]> | 1. paul121 mstenta I want to be able to reference `farm_material` and `farm_fungi` with my `taxonomy.vocabulary` and `taxonomy_term` files in `farm_shane_fungi`. I just pushed those to https://github.com/s33a/farm_shane_fungi/tree/0.0.1/config/install |
| [13:57:11] | <shane_aldrich[m]> | 2. Thanks for letting me know I don't have to worry about the plugin system! |
| [14:03:21] | <shane_aldrich[m]> | Also, do you possibly have a link to what all of the configuration options are for `taxonomy.vocabulary` and `taxonomy_term` YML files? I think that would help me out too. Thanks! |
| [14:58:24] | * Guest9489 has joined #farmos |
| [15:05:20] | * Guest9489 has quit (Quit: Client closed) |
| [16:01:33] | <mstenta[m]> | shane_aldrich: typically you just let Drupal generate those YML files for you - I don't know of any reference |
| [16:03:30] | <mstenta[m]> | It's pretty neat... install the `config_update_ui` module (actually just the `config` module for this, but `config_update_ui` adds some really useful tools for diffing config), then go to `/admin/config/development/configuration/single/export` |
| [16:03:37] | <mstenta[m]> | you'll see ALL the possible config that your Drupal instance is currently using |
| [16:03:45] | <mstenta[m]> | and you can export them to YML files individually |
| [16:03:52] | <mstenta[m]> | this is typically how you go about adding them to your module |
| [16:04:53] | <mstenta[m]> | one thing to note: you need to delete the `uuid` property from config YML files that you provide in your module |
| [16:07:51] | <mstenta[m]> | Whoa check this out! https://www.internetofelephants.com/news/open-source |
| [16:40:43] | <shane_aldrich[m]> | Just got back from shopping. |
| [16:41:00] | <shane_aldrich[m]> | <mstenta[m]> "It's pretty neat... install the..." <- I assume this is on drupal's site. |
| [16:42:02] | <mstenta[m]> | `drush en config_update_ui` will do it! and then yea... you go to `http://[domain]/admin/config/...` in your browser |
| [16:42:39] | <shane_aldrich[m]> | Cool. I should run that from the `web` directory, correct? |
| [16:44:16] | <mstenta[m]> | oh i think `vendor/bin/drush en config_update_ui` is what you want (ran from the directory that has `vendor` in it) |
| [16:45:37] | <shane_aldrich[m]> | that is the root directory that has `composer.json` and `phpcs.xml` |
| [16:46:00] | <mstenta[m]> | the `drush` binary is in `vendor/bin` |
| [16:47:07] | <mstenta[m]> | or forget drush and just go to `/admin/modules` and enable "Config Report UI" module :-) |
| [16:47:14] | <shane_aldrich[m]> | you're right. but I have drush as an alias like you taught me way back when. so that should work, right? |
| [16:47:26] | <mstenta[m]> | * or forget drush and just go to `/admin/modules` and enable "Configuration Update Reports" module :-) |
| [16:47:32] | <mstenta[m]> | oh ok yeas |
| [16:47:39] | <mstenta[m]> | i can't remember everything :-) |
| [16:51:58] | <shane_aldrich[m]> | looks like that worked. now I'll play around for a bit after I grab a beer. 🍻 |
| [17:01:38] | <mstenta[m]> | cheers! |
| [17:02:05] | <mstenta[m]> | here is the Drupal documentation on config management more generally: https://www.drupal.org/docs/configuration-management |
| [17:02:23] | <mstenta[m]> | a lot of that might be more general than you need - but if you have the time/interest definitely worth skimming! |
| [17:05:01] | <shane_aldrich[m]> | One thing I'm not seeing in the export options is `taxonomy_term`. But I get that this can be extremely useful! What `taxonomy.vocabulary` should I export to see how to work with my vocabularies and terms? |
| [17:05:51] | <mstenta[m]> | under "Configuration type" select "Taxonomy vocabulary" |
| [17:06:17] | <mstenta[m]> | then you can export individual vocabulary definitions |
| [17:06:56] | <mstenta[m]> | the other main types you'll want are "Field storage" and "Field" |
| [17:07:12] | <mstenta[m]> | note that in order to export a field, you need both the storage and the field |
| [17:07:47] | <mstenta[m]> | (storage defines how the field is configured across ALL bundles... field defines how it is configured on a SINGLE bundle) |
| [17:08:10] | <mstenta[m]> | have you played around with the Field UI module yet? i forget |
| [17:09:44] | <mstenta[m]> | (or have you just been copying other YML files and editing them?) |
| [17:09:54] | <mstenta[m]> | Field UI lets you add fields by clicking buttons :-) |
| [17:09:58] | <mstenta[m]> | and then you can export it to YML files using this export page |
| [17:12:57] | <shane_aldrich[m]> | I saw 'taxonomy vocabulary`. So for this instance, would it be best for me to create all of these: `field`, `field.storage`, `taxonomy.vocabulary`, and `taxonomy_term` in the UI, then export those files for me to play with? I have only been doing configuration on the phpstorm side of things and not through the UI. However, I do have that module enabled. |
| [17:13:42] | <mstenta[m]> | yea always best to do it in the UI and then export... that way Drupal generates the YML so you can be sure it's all correct |
| [17:14:07] | <mstenta[m]> | note that there is no "taxonomy term" config... terms are "content" entities... so you can't export/import that actual terms themselves |
| [17:14:26] | <mstenta[m]> | (well you can... with something like https://www.drupal.org/project/default_content - but not as config) |
| [17:14:41] | <mstenta[m]> | so you just define the vocabularies and the fields on them |
| [17:14:46] | <mstenta[m]> | but not the terms themselves |
| [17:14:49] | <mstenta[m]> | if that makes sense |
| [17:15:10] | <shane_aldrich[m]> | But those terms should be easy to work on after I have the `fields`, `storage`, and `vocabulary. |
| [17:15:13] | <mstenta[m]> | (as the end user of your module, you would add the terms that you want to your instance of farmOS) |
| [17:15:27] | <shane_aldrich[m]> | * But those terms should be easy to work on after I have the `fields`, `storage`, and `vocabulary`. |
| [17:15:32] | <mstenta[m]> | (but the module itself is agnostic of the "content" that will be in the site) |
| [17:15:59] | <mstenta[m]> | (eg: the `farm_plant` module doesn't provide any crops/variety terms... leaves that up to the end user) |
| [17:20:38] | <shane_aldrich[m]> | Here is what I'm thinking in regards to this: |
| [17:20:38] | <shane_aldrich[m]> | 1. `fungi_type` from `farm_fungi` would need `genus` and `species` in the form of terms provided by `farm_shane_fungi` |
| [17:20:38] | <shane_aldrich[m]> | 2. `material_type` from `farm_material` would need the `substrate_type` vocabulary from `farm_shane_fungi`, as well as `raw_material` and `supplement` as term. |
| [17:20:38] | <shane_aldrich[m]> | 3. Or is it better to hierarchically have all of those terms as vocabulary? If so, how many levels can drupal handle? |
| [17:21:46] | <mstenta[m]> | 1 makes sense |
| [17:21:46] | <mstenta[m]> | not sure what you mean by 3 |
| [17:21:46] | <mstenta[m]> | still not sure i understand the data model described in 2 |
| [17:22:36] | <mstenta[m]> | might be worth taking a step back one more time and thinking about how everything relates and will be used |
| [17:23:18] | <mstenta[m]> | i hesitate to recommend adding those things to `material_type` terms, because they are very specific to mushroom cultivation, but the `material` module is intended for more than just that |
| [17:23:38] | <mstenta[m]> | you certainly could, but it would always be custom to your module/instance - could never be generalized |
| [17:25:06] | <mstenta[m]> | it might make more sense for some of these references to be on logs... and maybe on custom log types for your use case |
| [17:25:11] | <mstenta[m]> | the key question is: what are "things" you're managing (assets) and what are the "events" (logs)? |
| [17:25:42] | <mstenta[m]> | my feeling is that you will have many types of `material` assets, that you are managing inventory of |
| [17:25:57] | <mstenta[m]> | and those will be combined together (via a log) to create a `fungi` asset, ultimately |
| [17:27:00] | <mstenta[m]> | question: what do `substrate_type`, `raw_material`, and `supplement` represent in your mind? |
| [17:27:12] | <mstenta[m]> | that's the part i'm not clear on i think |
| [17:27:13] | <shane_aldrich[m]> | I wish I could visualize this better for you. It all makes sense in my head when I think of the physical aspect of mushroom cultivation. But then that goes out the window to a degree when I think about how to accomplish this with drupal. |
| [17:27:56] | <mstenta[m]> | haha yea understood - and i'm also challenging it a bit more because i like to think about keeping things general/reusable across non-mushroom contexts, so i'm pushing that a bit :-) |
| [17:28:56] | <mstenta[m]> | as soon as your module adds things to a core asset type (like `material`) that are mushroom specific, then that means the module can't really be installed on any farmOS instance that has OTHER use-cases... because those fields would show in those contexts as well |
| [17:29:42] | <mstenta[m]> | > question: what do `substrate_type`, `raw_material`, and `supplement` represent in your mind? |
| [17:29:42] | <mstenta[m]> | can you elaborate on each of these a bit? |
| [17:29:48] | <shane_aldrich[m]> | mstenta[m]: This comes back to one of our earlier conversations. `substrate_type` is the growing medium for all fungi. And this can be simple (a wood log in the field for oyster mushrooms), or more complex for other species (coco coir, vermiculite, gypsum, and amino acids). |
| [17:30:25] | <mstenta[m]> | ok yup - that one makes sense (and we have `substrate_type` as a vocabulary in the old `farm_mushroom` module for that exact purpose |
| [17:31:12] | <mstenta[m]> | * ok yup - that one makes sense (and we have `substrate_type` as a vocabulary in the old `farm_mushroom` module for that exact purpose) |
| [17:31:33] | <mstenta[m]> | along with a `substrate_type` reference field on the old `substrate` asset type (which is now becoming the `fungi` asset type) |
| [17:31:41] | <shane_aldrich[m]> | I want to keep this as stripped down as possible for `core`. |
| [17:32:22] | <mstenta[m]> | so: in the old module, you basically created an asset to represent your fungi (for it's entire lifecycle from inoculation to harvest), and you referenced what type of substrate it was on |
| [17:33:20] | <mstenta[m]> | > (for it's entire lifecycle from inoculation to harvest) |
| [17:33:20] | <mstenta[m]> | actually this isn't exactly right... you could also have an asset that was just the agar tray, or just the spawn, and then another for the harvestable bag or something |
| [17:33:30] | <mstenta[m]> | and ideally each would have a "parent" lineage to connect them |
| [17:33:58] | <mstenta[m]> | ah! i gotta run - sorry |
| [17:34:04] | <shane_aldrich[m]> | ACTION posted a file: (6KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/JMfPIKxOqGE... > |
| [17:35:19] | <shane_aldrich[m]> | That's cool. You type too fast for me to respond. This is the document I shared with you before about the flow of cultivation. It covers just about everything we've talked about so far. I'll start diving into the UI stuff to export YML files this afternoon. |
| [17:40:01] | <shane_aldrich[m]> | Is there a good place to share this file with you guys so we could all make notes/comments as this moves along? |
| [17:40:53] | <shane_aldrich[m]> | I'm open to any and all suggestions on how everything should be represented in the module! |