IRC logs for #farmOS, 2021-06-18 (GMT)

2021-06-17
2021-06-19
TimeNickMessage
[00:50:48]* ahmetartu[m] has joined #farmos
[01:07:20]* ahmetartu[m] is now known as artu[m]
[10:36:20]<symbioquine[m]><mstenta[m] "so for contrib modules that need"> As a module vendor, that would be a non-starter IMHO. As far as I'm concerned, modules should take at most two steps to install; 1) `composer require x/z` 2) `drush en z` (Plus possible subsequent UI configuration away from sensible/functional defaults.)
[10:36:54]<mstenta[m]>i agree
[10:37:02]<mstenta[m]>but if you're including a library now it will already require three steps
[10:37:18]<mstenta[m]>(i think?)
[10:37:36]<symbioquine[m]>Not necessarily...
[10:37:39]<mstenta[m]>(unless of course you package the library itself in your module directly)
[10:38:16]<symbioquine[m]>https://github.com/symbioquine/farmOS_vue_page_demo
[10:39:09]<mstenta[m]>true... so in that case you're bundling the JS dependencies in your packaged JS
[10:39:14]<symbioquine[m]>yep
[10:39:25]<mstenta[m]>and maybe for contrib that's just the best way to go
[10:39:55]<mstenta[m]>I think paul121 's point about adding additional libs for use in core is still a good consideration... eg: a charting library
[10:39:58]<symbioquine[m]>It seems like it - then you can use Webpack to minimize/tree-shake/etc
[10:40:34]<mstenta[m]>unless of course we decide to adopt a webpack step in our own build/packaging process...
[10:40:53]<symbioquine[m]>With Drupal's per-page aggregation, I don't think clients would get caching benefits from having the library's JS as a stand-alone file.
[10:41:18]<symbioquine[m]>So the main benefit I think I see is that the library would be versioned directly in the composer.json file...
[10:42:36]<symbioquine[m]>but, my understanding is that Composer isn't (and shouldn't be) a full-featured JS dependency manager, so things like managing locks on transitive JS dependencies will be harder.
[10:42:44]<mstenta[m]>right
[10:42:55]<mstenta[m]>> unless of course we decide to adopt a webpack step in our own build/packaging process...
[10:42:55]<mstenta[m]>paul121 maybe we should consider this again...
[10:43:10]<mstenta[m]>i think the main reason against it is supporting shared hosting environments that can't run npm
[10:43:28]<mstenta[m]>but... if we ran it as part of our packaging script then it would be built into our tarballs
[10:43:36]<mstenta[m]>which means shared hosting could at least use the tagged releases
[10:43:50]<mstenta[m]>if you were hosting a non-tagged release, you would have to install npm perhaps
[10:44:17]<mstenta[m]>(we should create a dedicated issue for this - i am probably forgetting some other considerations)
[10:45:57]<symbioquine[m]><mstenta[m] "but... if we ran it as part of o"> Or publish an NPM package that models the library dependencies and copies built versions into its "dist/" directory, then use Composer to include *that* package.
[10:46:44]<symbioquine[m]>Named something like `farmos.org/farmos-core-js-deps`
[10:46:51]<mstenta[m]>hmm
[10:46:55]<mstenta[m]>that's an interesting idea
[10:48:19]<symbioquine[m]>Or maybe `farmos.org/farmos-core-js` if it includes any first-party built code...
[10:52:09]<symbioquine[m]><symbioquine[m] "Either of 8 or 9 am PST sound go"> This is probably my fault for leaving it at "either A or B" :) paul121 `et al` Do you want to meet in 10 minutes or in 70 minutes? https://meet.jit.si/farmos-dev?
[10:53:37]<mstenta[m]>ah i'll have to miss it :-( let me know how it goes! :-)
[10:53:48]<mstenta[m]>gotta run... let's make an issue to think about the JS stuff soon!
[10:54:38]<paul121[m]>Could we do 70 min?
[10:54:48]<symbioquine[m]>Sounds good
[15:08:38]<skipper_is[m]>Quick function question. We've got the farm_log_create() function, but that doesn't take an area arguement, is there a similar log creation function that we can pass area to? Or do we need to use a log_wrapper and pass area to that?
[15:09:05]<skipper_is[m]>There is the farm_movement_log() but that's for moving assets...
[15:34:17]* farmBOT has joined #farmos
[15:45:09]<mstenta[m]>skipper_is you could just add the area reference after calling that function and then save the log
[15:45:20]<mstenta[m]>We might actually do that in a quick form already I can't remember
[15:45:25]<skipper_is[m]>Yea, that's what I've done with the log_wrapper function
[15:45:37]<skipper_is[m]>$log_wrapper->field_farm_area[]=$area;
[15:45:44]<skipper_is[m]>entity metadata wrapper even
[15:46:00]<mstenta[m]>Fwiw we might not have the same helper functions in 2.x and just use the lower level stuff everywhere
[15:46:33]<mstenta[m]>The helper functions are nice but as you can see they are limited in their usefulness :-)
[15:47:01]<mstenta[m]>Plus the entity system is just all around better in drupal 9
[15:47:15]<mstenta[m]>It's basically all like the D7 wrapper stuff
[15:47:46]<skipper_is[m]>I'm not sure whether we'll be making the switch to 2.x though, as there have been comments on the complexity of it compared to the 1.x. I thought 1.x was quite complex, but I guess it's around what you're used to
[15:49:23]<skipper_is[m]>Most of the team just use the quick forms for everything
[15:49:34]<mstenta[m]>If 1.x is working for you then stick with that! Certainly no rush to switch :-)
[15:49:42]<skipper_is[m]>There are like 2 of us who use the other bits..
[15:50:01]<mstenta[m]>Definitely the more custom stuff you build the more work it will be of course
[15:50:46]<skipper_is[m]>I'll have to look at the custom modules and stuff for 2.x and see if I can get some simplified processes for the team in there
[15:50:50]<mstenta[m]>And fwiw Drupal 7 will no longer be supported in 2022, although for an intranet site like farmOS you can just put it behind a firewall and it doesn't really matter
[15:51:42]<mstenta[m]>(more of an issue for drupal based websites that are public facing)
[15:52:05]<skipper_is[m]>Ouch, fair enough
[15:52:24]<skipper_is[m]>Is there quick form functionality coming to 2.x?
[15:52:56]<mstenta[m]>There will be... That's one of the next things we'll be porting
[15:53:39]<skipper_is[m]>Ah ok, cool. I'll have a look at doing a 2.x version of some of my quick forms and see if the team manage with them
[15:54:23]<mstenta[m]>And yea I agree the 1.x -> 2.x is a big jump, because the same is true of D7->D8/9... But moving forward major drupal upgrades will never be as bad as this one (at least that's what they say) :-)
[15:55:02]<skipper_is[m]>Yea, it's a very different layout and way to interact
[15:56:12]<mstenta[m]>The main menu is one of the biggest UX changes .. but actually there is a setting to make it a top menu like the old one .. might try that!
[15:56:53]<skipper_is[m]>aah
[15:58:14]<skipper_is[m]>I'm not sure whether it's my monitor being an issue, but everything seems really big as well, like button wise
[15:58:59]<mstenta[m]>Mm yea I can understand that
[15:59:08]<mstenta[m]>Maybe Ctrl - ?
[16:00:00]<skipper_is[m]>Zoom is at 100%
[16:00:34]<mstenta[m]>(or maybe you could make a farmOS 2.x Bootstrap theme using https://www.drupal.org/project/bootstrap) :-D
[16:00:52]<mstenta[m]>Maybe better at 90%?
[16:01:36]<mstenta[m]>Tbh I always zoom my 1.x to 120% 😂
[16:05:03]<mstenta[m]>We chose to use this as our base theme in 2.x: https://www.drupal.org/project/gin
[16:05:37]<mstenta[m]>But it's possible to change the theme that your instance uses if you want to experiment with others
[16:06:54]<mstenta[m]>All theme tweaks that are specific to Gin are in this module: https://github.com/farmOS/farmOS/tree/2.x/modules/ui/theme
[16:07:11]<mstenta[m]>So if you try another theme you should disable that I think
[16:07:30]<mstenta[m]>1.x used Bootstrap as a base theme
[16:22:54]<paul121[m]>the latest release of Gin makes the menu a bit smaller!
[16:24:07]<paul121[m]>there were a couple bugs before they tagged a release but we should try it again
[16:25:38]<skipper_is[m]>I'll do some more testing with the team, it's early days