IRC logs for #farmOS, 2020-12-04 (GMT)

2020-12-03
2020-12-05
TimeNickMessage
[10:26:01]<mstenta[m]>FYI paul121 and symbioquine the Docker `drupal:9` image that we inherit from updated to PHP 8 yesterday (with the release of Drupal 9.1). This caused some issues which broke our tests. I experimented a bit to see if I could make it work, but there are some upstream deps that need to declare their PHP 8 support. So instead I changed our Docker image so it inherits from `drupal:9.0` explicitly, and created an issue to
[10:26:01]<mstenta[m]>document next steps: https://www.drupal.org/project/farm/issues/3186530
[10:26:44]<mstenta[m]>Apart from that, tests are still failing due to an issue in Drupal 9.1 upstream.... but it looks like they just fixed it, so hopefully there will be a patch release soon and tests will magically start passing again. :-)
[10:26:49]<mstenta[m]>https://www.drupal.org/project/drupal/issues/3186443
[14:43:35]<mstenta[m]>symbioquine: XDebug ALSO updated recently (what a month!) - not sure if you're using that at all, but if so you'll need to update some environment variables to make it work. Ping me if you need help!
[14:55:11]* skalakm[m] has joined #farmos
[14:57:11]<skalakm[m]>ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/buoyINlCWPQNiFIW... >
[14:58:16]<mstenta[m]>skalakm: hmm
[14:58:49]<mstenta[m]>Try adding `form_set_error('test', 'hold up!');` right at the beginning of `testing_validation()`
[14:59:34]<mstenta[m]>Your validation is not stopping the form from being submitted... so you may not actually be seeing submitted values. If the form is reloading after submission you may be seeing the fresh (empty) values of a new form.
[14:59:46]<mstenta[m]>`form_set_error()` will throw a validation warning, preventing submission
[15:00:23]<skalakm[m]>That did it.
[15:00:44]<mstenta[m]>tip: install the devel module, and you can just put `dpm($form_state['values'])` instead of the echos and print_rs - and it looks pretty :-)
[15:00:52]<mstenta[m]>https://drupal.org/project/devel
[15:01:52]<mstenta[m]>one other small observation... `farm_form_alter()` should be named `[mymodule]_form_alter()` (where `[mymodule]` is the name of your module)
[15:02:19]<mstenta[m]>`farm_form_alter()` essentially means "`hook_form_alter()` provided on behalf of the `farm` module"
[15:02:53]<skalakm[m]>My intention was to grab every form going through. Is that not what it will do?
[15:03:03]<mstenta[m]>it will
[15:03:07]<mstenta[m]>yes, what you have works
[15:03:33]<mstenta[m]>it's just that it should be named based on your module
[15:03:37]<mstenta[m]>not `farm_*`
[15:03:48]<mstenta[m]>are you doing this in a custom module?
[15:04:08]<skalakm[m]>Yes.
[15:04:18]<mstenta[m]>(this is a "best practice" tip...)
[15:04:27]<mstenta[m]>ok so if your module is `mymodule.module`
[15:04:37]<mstenta[m]>then the function should be named `mymodule_form_alter()`
[15:04:46]<mstenta[m]>if you rename it to that, it should still work for you
[15:06:14]<mstenta[m]>Drupal basically calls out to all modules and says "hey! any of you modules got a function named `$modulename . '_form_alter'`? ok go!"
[15:06:29]<mstenta[m]>so your hooks should always start with the name of your module
[15:06:49]<skalakm[m]>Okay, I wasn't clear on that. I thought it needed the name of the module it was altering.
[15:07:04]<mstenta[m]>`farm_form_alter()` works because `farm` is already a module (technically it's the install profile, but works the same as far as hooks go) - but it essentially means you're writing a hook on behalf of another module
[15:07:21]<mstenta[m]>ah nope! it uses the name of the module that is implementing the hook itself
[15:07:40]<mstenta[m]>("implementing" means providing a hook function, "invoking" means running the hook function (which is what Drupal does))
[15:08:19]<skalakm[m]>So if I wanted to use the more specific form it would be something like module_form_farm_log_harvest_alter?
[15:09:09]<skalakm[m]>mymodule_form_farm_log_harvest_alter
[15:09:26]<mstenta[m]>ah yea... so now that's getting into the available hooks...
[15:09:30]<mstenta[m]>there are two options:
[15:10:02]<mstenta[m]>`hook_form_alter`: https://api.drupal.org/api/drupal/modules%21system%21system.api.php/func...
[15:10:13]<mstenta[m]>`hook_form_FORM_ID_alter`: https://api.drupal.org/api/drupal/modules%21system%21system.api.php/func...
[15:10:33]<mstenta[m]>they both work the same... `hook_form_alter` just gives you a `$form_id` parameter to check
[15:11:12]<skalakm[m]>Yeah, I get that I can just user hook_form_alter, but I'm just checking if I'm understanding the setup.
[15:11:13]<mstenta[m]>so if you want to alter `log_form`, for instance:
[15:11:24]<skalakm[m]>*just use
[15:11:24]<mstenta[m]>`mymodule_form_log_form_alter()`
[15:11:50]<mstenta[m]>yea, i prefer to use `hook_form_FORM_ID_alter()` whenever possible - keeps things separated into functions nicely
[15:12:12]<mstenta[m]>if you need to do dynamic logic that affects multiple forms, then the more general hook is useful
[15:13:59]<mstenta[m]>skalakm: how's the FarmData -> farmOS stuff going?
[15:14:32]<mstenta[m]>I was thinking about you the other day...
[15:14:35]<skalakm[m]>Well Grant has started using it in class and he won an award from Gnome.
[15:14:40]<mstenta[m]>We're working on farmOS 2.x - and the migration capabilities are pretty awesome
[15:15:34]<skalakm[m]>We're still working with the Dickinson Farm to figure out what forms/customizations they want.
[15:15:48]<skalakm[m]>Is farmOS 2 on Drupal 8?
[15:15:55]<mstenta[m]>Drupal 9 in fact :-)
[15:15:56]<skalakm[m]>Or 9?
[15:16:23]<mstenta[m]>> Well Grant has started using it in class and he won an award from Gnome.
[15:16:23]<mstenta[m]>Cool! Do you mean with FarmData? Or farmOS?
[15:17:13]<skalakm[m]>He is using FarmData2 on farmOS.
[15:17:19]<mstenta[m]>Awesome!
[15:19:19]<mstenta[m]>Have you done a lot of customization on top?
[15:19:48]<skalakm[m]>Just the custom modules that Allen added so far.
[15:19:50]<mstenta[m]>(I'm trying to make sure folks are aware of 2.x... and planning ahead0
[15:20:36]<skalakm[m]>I'll bring it up when I see them next Tuesday. How hard will it be to migrate custom modules, data, etc.?
[15:20:47]<skalakm[m]>And when do you think it will roll out?
[15:21:02]<mstenta[m]>Depends on what customizations you've made
[15:21:46]<mstenta[m]>We're aiming for the Spring, but that will be "beta" - might still be rough around the edges
[15:21:58]<mstenta[m]>We're writing automated migrations for all core farmOS data
[15:22:11]<mstenta[m]>So if you're not adding new fields, log types, etc, then you're covered
[15:24:27]<skalakm[m]>Ok. While I got you here, how would I get a list of all planting assets in the code?
[15:26:07]<mstenta[m]>You might try `EntityFieldQuery`
[15:26:08]<mstenta[m]>https://www.drupal.org/docs/7/creating-custom-modules/howtos/how-to-use-...
[15:26:49]<mstenta[m]>Or, you could do a `SELECT id FROM {asset} WHERE type='planting'` and then plug that into `farm_asset_load_multiple()`
[15:27:04]<mstenta[m]>`farm_asset_load_multiple()` takes an array of asset IDs
[15:27:33]<skalakm[m]>Any reason to not just hit the database directly?
[15:28:28]<mstenta[m]>It couples your code to the raw db structure, rather than using the higher level APIs like `EntityFieldQuery`
[15:28:52]<mstenta[m]>but that said... `EntityFieldQuery` is not in D8, so I'd say just do database queries
[15:28:56]<mstenta[m]>might be easier to migrate
[15:29:34]<mstenta[m]>(have to balance "best practice" with "a lot of things are changing in D9 anyway")
[15:29:34]<skalakm[m]>Alright. Thanks again for the help and I'll let you know what everyone thinks about the farmos2 stuff.
[15:30:04]<mstenta[m]>Cool. We are beginning to document things here: https://2x.farmOS.org
[15:30:18]<mstenta[m]>we gotta get Github to fix that SSL cert :-/
[15:30:29]<mstenta[m]>(hosted on github pages, but ssl is broken for some reason)
[15:30:56]<skalakm[m]>Good luck with that. ttyl