| [20:13:12] | * FarmerEd[m] has joined #farmos |
| [20:29:32] | * Timmy[m] has joined #farmos |
| [20:53:55] | * Greg[m] has joined #farmos |
| [21:10:35] | * abraham_jabangwe[m] has joined #farmos |
| [21:14:24] | * waterleat[m] has joined #farmos |
| [21:15:43] | * jgaehring[m] has joined #farmos |
| [21:18:55] | * RUros[m] has joined #farmos |
| [21:24:04] | * serenelion[m] has joined #farmos |
| [21:44:45] | * pcambra[m] has joined #farmos |
| [21:57:20] | * mstenta[m] has joined #farmos |
| [21:59:36] | * amber_s[m] has joined #farmos |
| [22:11:23] | * botlfarm[m] has joined #farmos |
| [22:17:26] | * ezkl[m] has joined #farmos |
| [23:16:51] | * BolajiAyodeji[m] has joined #farmos |
| [23:16:59] | * AlexAnder[m] has joined #farmos |
| [23:22:16] | * nstancliff[m] has joined #farmos |
| [23:39:31] | * paul121[m] has joined #farmos |
| [23:54:05] | * ander[m] has joined #farmos |
| [23:55:08] | * symbioquine[m] has joined #farmos |
| [06:40:25] | <RUros[m]> | symbioquine: Yes indeed, usually there is no need for many types in land assets. Particulary in my case it would be enough if i could rename some of existing, which are not useful for my case. Thanks for representing examples, i tried with Skipper's farm_vhffieldtypes, which did not work as it is (on installing module server response was Error 500), then with some minor modification worked. I asume because is create for FarmOS V2. |
| [06:41:38] | <RUros[m]> | * symbioquine: Yes indeed, usually there is no need for many types in land assets. Particulary in my case it would be enough if i could rename some of existing, which are not useful for my case. Thanks for representing examples, i tried with Skipper's farm\_vhffieldtypes, which did not work as it is (on installing module server response was Error 500), then with some minor modification worked. I asume because it was build for FarmOS V2. |
| [06:41:49] | <RUros[m]> | * symbioquine: Yes indeed, usually there is no need for many types in land assets. Particulary in my case it would be enough if i could rename some of existing, which are not useful for my case. Thanks for representing examples, i tried with Skipper's farm\_vhffieldtypes, which did not work as it is (on installing module server response was Error 500), then with some minor modification worked. I assume because it was build for FarmOS V2. |
| [06:42:08] | <mstenta[m]> | RUros: Yea I meant to chime in yesterday... the reason land types are more strictly defined is so that they can be relied on by other modules. For example, in farmOS v1, the Grazing module relied on "Paddock" land assets for rotational grazing. |
| [06:42:51] | <mstenta[m]> | Although I'm not aware of other examples currently. It is mostly a historical decision that they are structured that way. |
| [06:43:19] | <mstenta[m]> | For what it's worth, you can disable the farm_land_types module to remove all of the default ones if they aren't useful to you. |
| [06:43:24] | <mstenta[m]> | Then only other will be an option. |
| [06:43:35] | <mstenta[m]> | And then you can create your own in a module. |
| [06:44:28] | <RUros[m]> | Yes, make sense with connection to others. |
| [06:45:37] | <RUros[m]> | Currently I bumped at issue that I installed module with some new field types (testing names), but now i cannot revert it to original state. |
| [06:45:57] | <RUros[m]> | After deleting module, names are still present in web interface as option |
| [06:46:34] | <mstenta[m]> | Ah - that can happen if the module was not written in a way that properly cleans up after itself. |
| [06:46:36] | <RUros[m]> | Probably I should delete it manualy via bash command in docker/drupal ? |
| [06:46:47] | <mstenta[m]> | It is possible to delete them manually yes. |
| [06:47:08] | <mstenta[m]> | Technically, land types are represented as "configuration entities" in Drupal. |
| [06:47:41] | <mstenta[m]> | (So if you noticed, they are defined as YML files in the config/install directory of the module... which means when the module gets installed, it creates the configuration entities that it finds in that directory) |
| [06:48:03] | <mstenta[m]> | Have you learned how to use drush commands? |
| [06:48:25] | <mstenta[m]> | (drush is the command line tool for Drupal) |
| [06:49:11] | <RUros[m]> | yes just basic one, since i cleared cache and tried some commands to manual delete types, but deleting was not succesful... yet |
| [06:49:49] | <RUros[m]> | have to take a deeper look, since i am not familiar with this kind of programming |
| [06:51:35] | <mstenta[m]> | Are these the types you are trying to delete? https://github.com/Skipper-is/farm_vhffieldtypes/tree/b55350f94c13a43f7d... |
| [06:51:56] | <RUros[m]> | yes |
| [06:52:09] | <mstenta[m]> | If so, I think the command is: |
| [06:52:09] | <mstenta[m]> | `drush config:delete farm_land.land_type.garden` |
| [06:52:34] | <mstenta[m]> | and: |
| [06:52:34] | <mstenta[m]> | `drush config:delete farm_land.land_type.pasture` |
| [06:53:24] | <RUros[m]> | thank you |
| [06:53:28] | <mstenta[m]> | It is worth noting: it IS possible to create new config entities like these without a module... I can explain how to do that if you're interested. |
| [06:53:52] | <RUros[m]> | yes of course |
| [06:54:15] | <mstenta[m]> | The benefit of putting them in a module is that it's a bit "cleaner" from a maintenance standpoint - you can manage them in source control - and share them with others. But it isn't strictly necessary. |
| [06:54:32] | <mstenta[m]> | Did those commands work? |
| [06:55:42] | <RUros[m]> | jap |
| [06:56:30] | <mstenta[m]> | Great |
| [06:56:58] | <mstenta[m]> | OK so here's how to create config entities through the UI... this is "advanced" and it might be possible to break things (!!) so be warned... |
| [06:57:16] | <mstenta[m]> | (or hopefully Drupal performs validation to ensure that doesn't happen ... but I don't know) |
| [06:57:35] | <RUros[m]> | ok, no problem I have test enviroment so it does not matter |
| [06:57:41] | <mstenta[m]> | As user 1 (the "root" Drupal user with all permissions), go to Administration > Configuration > Development > Configuration Syncronization |
| [06:58:16] | <RUros[m]> | ok |
| [06:58:29] | <mstenta[m]> | Click the "Import" tab, and then the "Single item" tab |
| [06:58:46] | <RUros[m]> | ok |
| [06:58:46] | <mstenta[m]> | In the "Configuration type" dropdown, select "Land type" |
| [06:59:16] | <mstenta[m]> | Then just copy and paste the YML from one of the farmOS core land type config files, and modify it to your needs |
| [06:59:21] | <mstenta[m]> | Here are the default core types: |
| [06:59:36] | <mstenta[m]> | https://github.com/farmOS/farmOS/tree/4.x/modules/asset/land/modules/typ... |
| [07:00:19] | <mstenta[m]> | It is very important that the id is unique |
| [07:00:21] | <mstenta[m]> | (It probably won't let you import otherwise) |
| [07:00:24] | <mstenta[m]> | Also: WARNING... |
| [07:01:12] | <mstenta[m]> | If you create a land type here, and then in the future farmOS core adds a land type with the same ID, or you try to install another module that provides one with the same ID, it will conflict and could end up in a broken state |
| [07:01:48] | <mstenta[m]> | So it might be safe to create an ID with a namespace that won't conflict. eg: instead of pasture, maybe ruros_pasture |
| [07:02:05] | <mstenta[m]> | the label can still be Pasture - that is what is shown in the UI |
| [07:03:40] | <RUros[m]> | Great ! It is working. |
| [07:03:52] | <RUros[m]> | Ok, I understand |
| [07:04:36] | <RUros[m]> | I assume also in all future updates of core, this will be overriden ? And I have to set it up again ? |
| [07:06:34] | <mstenta[m]> | No this will be maintained. |
| [07:06:42] | <mstenta[m]> | But it only exists in your database. |
| [07:07:11] | <mstenta[m]> | If you were to edit existing config provided by core, then yes you would risk losing it. |
| [07:08:19] | <mstenta[m]> | However... and this is another reason why packaging things in modules is better: if in a future major version of farmOS core (eg: v4, v5, v6, etc)... we decide to change the way that land types are defined, THEN it could break or be lost during an upgrade. |
| [07:08:59] | <mstenta[m]> | That's the benefit of a module. The module can declare in it's info.yml file that "I am compatible with these versions of farmOS core" and they can provide upgrade paths for any config that they have provided... so that they can help transition to new versions seamlessly. |
| [07:09:28] | <mstenta[m]> | For the land type config, since it is very simple, I think that risk is low. |
| [07:09:41] | <mstenta[m]> | And the worse case scenario would not be that bad. |
| [07:09:53] | <mstenta[m]> | For other more complicated configuration types, I would advise against it. |
| [07:10:32] | <mstenta[m]> | FYI: we follow semantic versioning https://semver.org/ |
| [07:11:40] | <mstenta[m]> | Which means that we promise not to introduce "breaking" changes like that in minor version releases (eg: 3.4.x, 3.5.x, 3.6.x, etc) but we MAY break things between major version releases (eg: 4.x.y, 5.x.y, 6.x.y). And we always publish details about those breaking changes so that module maintainers can update accordingly. |
| [07:14:32] | <RUros[m]> | OK, thank you for explanation. Means a lot, since this is (for me) complex system. |
| [07:35:32] | <mstenta[m]> | Yea - this is advanced usage :-) |
| [07:37:49] | <RUros[m]> | Thank you for now. Sure I will come back with new questions 😀 |
| [07:39:26] | <RUros[m]> | ChatGPT / Gemini does not alwasy give working solutions 😆 |
| [07:39:49] | <RUros[m]> | s/alwasy/always/ |
| [07:41:29] | <mstenta[m]> | Totally. farmOS is a bit too niche for LLMs (even Drupal results are not great, because LLMs are trained on a lot of documentation taken from the web, including very old stuff that is no longer relevant - so you end up with a nonsensical mix) |
| [07:42:54] | <RUros[m]> | Yes, I figured this 😀 |
| [07:47:34] | <FarmerEd[m]> | I can confirm the above. But Can still be useful if you are almost there. For example if you just ask it to build something with Drupal it will be a mess, but using it to help understand the document can be very useful, just work in small increments and understand each bit before moving on. And use some sort of version control so you can go backwards when needed. |
| [07:50:10] | <mstenta[m]> | Yes. Use it to learn. Not to think. |
| [07:50:51] | <mstenta[m]> | I like to think of it as asking advice from an overconfident teacher who knows a lot but is also wrong a lot. |
| [07:54:45] | <FarmerEd[m]> | Oh yeah, for some simple tasks it could produce perfect elegant code, other times it's like dealing with a drunk toddler who won't admit when it's wrong. |
| [07:55:38] | <mstenta[m]> | Spot on. |
| [07:56:34] | <FarmerEd[m]> | (we don't have drunk toddlers, that's just an Irish stereotype 🤣) |
| [10:46:25] | <mstenta[m]> | @room Heads up to anyone who is using composer to manager their farmOS codebase, and using CSV importers... you might want to avoid running composer update for a bit... the migrate_tools module (which our CSV importers depend on) introduced a breaking change in their 6.1.0 release which they are working on fixing now: https://www.drupal.org/project/migrate_tools/issues/3536657 |
| [10:46:35] | <mstenta[m]> | * @room Heads up to anyone who is using composer to manage their farmOS codebase, and using CSV importers... you might want to avoid running composer update for a bit... the migrate_tools module (which our CSV importers depend on) introduced a breaking change in their 6.1.0 release which they are working on fixing now: https://www.drupal.org/project/migrate_tools/issues/3536657 |
| [10:47:05] | <mstenta[m]> | I'm going to hold off on putting out a new release of farmOS that pins to the previous version, in hopes that they release a fix in the next few days. |
| [10:47:14] | <mstenta[m]> | But if they don't then we will have to. |