IRC logs for #farmOS, 2023-04-03 (GMT)

2023-04-02
2023-04-04
TimeNickMessage
[23:09:58]* Mo[m] has joined #farmos
[23:09:58]<Mo[m]>Yeah, it wasn't too hard and using the preprocess hook, it's easy to manipulate.
[05:00:07]* piegeux[m] has quit (Quit: You have been kicked for being idle)
[12:18:27]<mstenta[m]>jgaehring paul121 symbioquine wotnak ^
[12:18:27]<mstenta[m]>> application sent! we'll see if they accept us 🤞
[12:18:27]<mstenta[m]>Good news! Netlify accepted farmOS as an open source organization! 🎉
[12:36:38]<mstenta[m]>I need to set up the account and add everyone as a user
[12:36:57]<mstenta[m]>They also sent instructions for transferring projects to the new org if we want to
[13:02:22]<mstenta[m]>Also: I tried getting 2.0.4 released, but ran into a failing test after updating Drupal core that I need to investigate
[13:28:58]<paul121[m]>amazing! maybe we could move the farmos-demo site over too - that is a netlify site :-)
[13:29:43]<mstenta[m]>oh cool! didn't know that :-)
[13:30:32]<mstenta[m]>one thing that they did note in the email is we are still bound by the limits on traffic etc, and if we go over we gotta pay uo
[13:30:36]<mstenta[m]>up*
[13:31:31]<mstenta[m]>maybe worth reviewing the current stats on farmOS.org and the demo site
[13:32:02]<mstenta[m]>i'm sure it's all within the limits, but it would be good to have a baseline for historical reference
[13:34:19]<paul121[m]>totally. the demo site does use netlify functions (like aws lambda/"serverless") but I think they are well within the free tier. the actual demos are hosted on a free Tugboat.qa tier
[13:35:14]<mstenta[m]>ah cool
[13:36:56]<mstenta[m]>> Also: I tried getting 2.0.4 released, but ran into a failing test after updating Drupal core that I need to investigate... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/9d62bf4c6a...)
[13:37:21]<paul121[m]>link to GH action?
[13:37:54]<mstenta[m]>https://github.com/mstenta/farmOS/actions/runs/4584784653/jobs/8125132853
[13:39:24]<mstenta[m]>That is 2.x on my fork, which has two additional commits:
[13:39:24]<mstenta[m]>1) https://github.com/mstenta/farmOS/commit/e3d2a621bd43be0d32573da96eaf6ca...
[13:39:24]<mstenta[m]>2) https://github.com/mstenta/farmOS/commit/ec27773940dcaa0c04f5df8b4c1263d...
[13:39:32]<mstenta[m]>2.x on origin is passing
[13:39:54]<mstenta[m]>So it probably has something to do with drupal 9.5.7... ? 🤷
[13:40:44]<mstenta[m]>Or 9.5.6, actually... 9.5.7 came out right after and just reverts one of the commits in 9.5.6... but most of the changes are in 9.5.6
[13:40:45]<mstenta[m]>https://www.drupal.org/project/drupal/releases/9.5.6
[13:50:56]<paul121[m]>so doesn't have disabled attribute
[13:51:04]<paul121[m]>https://github.com/farmOS/farmOS/blob/a56fccaa8f846a9f489028d8839cd01675...
[13:56:39]<mstenta[m]>yea
[13:58:42]<mstenta[m]>hmm maybe related to this change? https://www.drupal.org/project/drupal/issues/994360
[13:59:12]<mstenta[m]>Definitely has to do with #states and checkboxes in our form...
[14:00:51]<paul121[m]>Yeah. The last comment in that issue is prob it
[14:01:11]<paul121[m]> $(e.target).prop('checked', e.value).trigger('change');
[14:01:11]<paul121[m]> $(e.target).closest('.js-form-item, .js-form-wrapper').find('input').prop('checked', e.value).trigger('change');
[14:01:20]<mstenta[m]>Relevant line in our code: https://github.com/farmOS/farmOS/blob/a56fccaa8f846a9f489028d8839cd01675...
[14:01:21]<paul121[m]>This code change: https://git.drupalcode.org/project/drupal/-/commit/1c58414870f333dc66b9e...
[14:02:23]<paul121[m]>ah: https://www.drupal.org/project/drupal/issues/2945727
[14:02:46]<mstenta[m]>ah ha
[14:02:51]<paul121[m]>wow, plain as day:
[14:02:51]<paul121[m]>> States on radios and checkboxes elements are currently broken until #994360: #states cannot check/uncheck checkboxes elements is resolved, but when that issue is fixed another appears.
[14:03:06]<paul121[m]>> what that issue is fixed another appears
[14:03:10]<paul121[m]>s/what/when/
[14:04:42]<paul121[m]>ugh so idk how we add those classes to the checkbox wrapper. not sure if we have access to that in our settings form?
[14:04:59]<mstenta[m]>i can run a quick test with the patch from that issue to see if it works (and still applies)
[14:05:32]<mstenta[m]>last updated in 2018 for drupal 8.7.x :-/
[14:07:54]<mstenta[m]>test started...
[14:08:12]<mstenta[m]>https://github.com/mstenta/farmOS/actions/runs/4599904179
[14:13:07]<paul121[m]>hmm I'm inspecting a settings page now. It seems that the checkboxes do have the js-form-item class in their wrapper
[14:13:08]<paul121[m]>the issue might be that the "Install modules" button does not
[14:14:29]<paul121[m]><paul121[m]> "This code change: https://git...." <- I dunno.. don't fully understand the JS states logic from just looking at this
[14:23:41]<mstenta[m]>The patch applied but did not fix our test
[14:26:46]<paul121[m]>wait have the tests completed?
[14:28:08]<mstenta[m]>Yea, sorry I re-ran failed tests - mariadb failed first, and have BOTH a failure due to the existing mariadb database connection issue BUT ALSO showed the same testInstallFunctionality failure as well
[14:29:50]<paul121[m]>dang
[14:32:49]<paul121[m]>Okay, yep
[14:37:12]<paul121[m]>When a module checkbox is clicked/checked, Drupal states logic should remove the `disabled` property from the "Install modules" button
[14:41:41]<paul121[m]>But that isn't happening because this change selects the "install modules" button itself (it has the `.js-form-submit` class), and then tries to find child `input` elements, however itself is the `input` element!
[14:41:42]<paul121[m]>https://git.drupalcode.org/project/drupal/-/commit/1c58414870f333dc66b9e...
[14:42:07]<paul121[m]>so thus, no child input is found and disabled is never applied
[14:43:02]<paul121[m]><paul121[m]> "When a module checkbox is..." <- Subtle detail: the inverse of this should happen when the page is loaded, so that is why `disabled` is never applied in the first place
[14:43:03]<paul121[m]> * so thus, no child input is found and disabled is never removed
[14:45:13]<paul121[m]>..... so I think this would be fixed if we can remove `.js-form-submit` from the "Install modules" input itself. removing a class is harder than adding :-/
[14:49:45]<paul121[m]>IMO release without updating Drupal core :-)
[14:51:39]<paul121[m]>Or, consider this as a pretty minor bug that doesn't have ill-consequences if the user clicks "install modules" without any selected. We could add form validation to give an error message
[14:52:17]<paul121[m]>(side note - quite cool that our tests caught this!! :P)
[15:26:11]<mstenta[m]>Should we just remove the disabled state logic altogether from our form?
[15:26:27]<paul121[m]>thats an option too
[15:26:38]<mstenta[m]>It's a "nice to have"
[15:26:40]<mstenta[m]>But not worth spending time fixing this IMO
[15:27:06]<paul121[m]>Right. So we could remove code and maybe add back in later... or kinda let the bug live on? 🤷
[15:27:36]<paul121[m]>I guess we need to address the test error at minimum
[15:28:19]<mstenta[m]>Yea. I say we just remove the logic, don't disable the submit button, don't test that the submit button is disabled, and call it a day
[15:28:46]<mstenta[m]>Then someone in the future can try to redo it if they want... and run into this bug and try to fix it in the process
[15:30:42]<mstenta[m]>Maybe we also add a validateForm() that checks to make sure modules that are not installed were selected
[15:32:15]<paul121[m]>sounds good to me
[15:32:31]<mstenta[m]>k i'll throw together a PR right now...
[15:33:51]<mstenta[m]>> Maybe we also add a validateForm() that checks to make sure modules that are not installed were selected
[15:33:51]<mstenta[m]>actually, maybe this isn't necessary - submitForm() basically does this and bails early if none were selected
[15:35:51]<mstenta[m]>https://github.com/mstenta/farmOS/commit/fa45b8bb21943099a9a1ecf4dc30ed9...
[15:36:27]<mstenta[m]>We don't need to do a full PR for this IMO - if the tests pass, and if you can just take a quick look at that commit paul121 ?
[15:51:55]<paul121[m]>a PR would actually be nice to find this code later on :-)
[15:51:55]<mstenta[m]>tests passed
[15:51:55]<paul121[m]>or update the changelog I guess
[15:51:57]<mstenta[m]>ok
[15:52:35]<mstenta[m]>does the commit look good, so i can just make the PR and immediately merge it?
[15:53:23]<mstenta[m]>(signing off soon - would love to get 2.0.4 released before the end of the day, not sure what your availability to review is)
[15:53:23]<paul121[m]>Yes, looks good to me
[15:53:27]<mstenta[m]>cool!
[15:53:33]<mstenta[m]>i'll wrap it up in a PR as-is
[15:53:46]<mstenta[m]>thanks1`
[15:53:49]<paul121[m]>wow didn't realize the time already
[15:53:51]<mstenta[m]> * thanks!
[16:46:11]<mstenta[m]>farmOS 2.0.4 has been released! https://github.com/farmOS/farmOS/releases/2.0.4 🎉