| [12:36:02] | * botlfarm[m] has joined #farmos |
| [12:44:22] | <botlfarm[m]> | Hey all, Im having an issue with map areas displaying on the dashboard the /areas page. I recently updated a few of my existing areas. I changed some geometries and changed some area types. I also created some new areas. The areas all display fine when looking at a single area (/farm/area/corral), but the map on the dashboard and on the areas page change almost every tie i refresh a page. Sometimes it will sho me no |
| [12:44:22] | <botlfarm[m]> | areas at all and be zoomed out to earth level. some times it shows me only 1 area. some times only a small handful of areas. I have not been able to find a pattern to what areas it will display. |
| [12:45:24] | <mstenta[m]> | Hey Nick! Huh that sounds strange |
| [12:45:51] | <mstenta[m]> | I'm feeding the kids lunch right now, but quick thing to try: |
| [12:46:11] | <mstenta[m]> | Open your browser dev tools and go to the network tab, then refresh |
| [12:46:27] | <mstenta[m]> | There should be a request for each area type |
| [12:46:52] | <mstenta[m]> | Check to see if there are any errors, or if maybe some are taking a long time to load... |
| [12:47:22] | <mstenta[m]> | The separate requests each load the GoeJSON for areas of that type fyi |
| [12:48:57] | <botlfarm[m]> | ah, yes im getting a "Insufficient Storage" error |
| [12:49:27] | <mstenta[m]> | Oh huh. Never saw that before. Is that server side or client side I wonder |
| [12:49:55] | <botlfarm[m]> | "The method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. There is insufficient free space left in your storage allocation. |
| [12:49:55] | <botlfarm[m]> | Additionally, a 507 Insufficient Storage error was encountered while trying to use an ErrorDocument to handle the request." |
| [12:51:39] | <mstenta[m]> | Oh wow |
| [12:51:51] | <mstenta[m]> | Sounds like the server doesn't have enough disk space? |
| [12:52:31] | <symbioquine[m]> | Could it be on the browser side? |
| [12:52:40] | <symbioquine[m]> | i.e. local storage |
| [12:52:58] | <symbioquine[m]> | oh, nvm |
| [12:53:10] | <botlfarm[m]> | Yeah, that is what is sounds like, yet im showing only a 4% utilization of my server disk space. Maybe I need o to call my host. |
| [12:55:32] | <mstenta[m]> | Huh yea that's weird |
| [12:57:52] | <mstenta[m]> | I wonder if it could actually be related to the size of the response |
| [12:58:44] | <mstenta[m]> | Or maybe not... Sounds like it could be a few different things |
| [12:59:04] | <mstenta[m]> | Couldn't find anything Drupal specific but this describes the issue in Wordpress: https://bobcares.com/blog/507-insufficient-storage-error/ |
| [12:59:49] | <mstenta[m]> | Were any of the new areas you added particularly big or complicated? |
| [13:00:05] | <mstenta[m]> | If not, I'd probably contact your host |
| [13:00:22] | <symbioquine[m]> | <mstenta[m] "Were any of the new areas you ad"> or maybe a lot of small ones |
| [13:01:11] | <botlfarm[m]> | not really. I added about 10 areas total. each abtou 1/2 acre in size with a 6 sided polygon at most. |
| [13:02:41] | <botlfarm[m]> | I did have a few windows open at once with farmos editing in multiple locations at once. just was easier for me getting the correct info. |
| [13:09:23] | <mstenta[m]> | Hmm yea that should all be fine |
| [13:26:43] | <symbioquine[m]> | What's the recommended pattern for a contrib module in 2.x to pull in JS resources which need a build step? [farm_map does this](https://github.com/farmOS/farmOS/blob/83fe014b246a597c7b6ba7dd35195dafae...), but that only works because it's a core module and [depends on hard-coded configuration in the top-level composer.json |
| [13:26:43] | <symbioquine[m]> | file](https://github.com/farmOS/composer-project/blob/f00490da3b62930d8a29ceca...)... |
| [13:27:58] | <symbioquine[m]> | I don't see a way for a contrib module to get it's assets into the `/web/libraries/` directory without either changing that top-level composer.json file or writing an install step to manually copy them there. |
| [13:28:04] | <mstenta[m]> | That's a tricky question symbioquine |
| [13:28:24] | <mstenta[m]> | Because there isn't a JS build step to Drupal deployment typically |
| [13:28:37] | <mstenta[m]> | There are lots of ways to do it, each with costs and benefits |
| [13:28:53] | <symbioquine[m]> | Oh, I'm hoping the build step will be done already - as part of publishing to NPM |
| [13:29:21] | <symbioquine[m]> | That ensures no NPM/node.js requirements for the server running the module afaik |
| [13:30:24] | <mstenta[m]> | It's most complicated for farmOS core... Because we need to support various deployment strategies |
| [13:30:56] | <mstenta[m]> | But for a custom module, one simple thing would be to just commit the built JS file directly to the repo |
| [13:31:10] | <mstenta[m]> | Or: use GitHub actions to package a release, which includes a build step |
| [13:31:25] | <symbioquine[m]> | Yeah, that was starting to look like the only option... |
| [13:31:29] | <mstenta[m]> | But in either case you end up with the pre built JS in the module itself |
| [13:32:24] | <mstenta[m]> | Another option is to include it via NPM using asset-packagist in your project composer.json, similar to farmOS-map |
| [13:33:06] | <symbioquine[m]> | <mstenta[m] "Another option is to include it "> But then folks couldn't just install the contrib module, there'd be extra steps first right? |
| [13:33:24] | <symbioquine[m]> | i.e. adding a repository or install path to the top-level composer.json |
| [13:34:15] | <mstenta[m]> | That's right |
| [13:34:30] | <mstenta[m]> | Works for custom deployments |
| [13:34:46] | <mstenta[m]> | But for contrib modules: yea best to just package the built JS |
| [13:35:07] | <symbioquine[m]> | Bummer |
| [13:35:28] | <mstenta[m]> | (FWIW I still question whether or not we should package built JS of farmOS-map) |
| [13:35:41] | <symbioquine[m]> | oh? |
| [13:35:41] | <mstenta[m]> | Rather than use asset-packagist |
| [13:35:48] | <symbioquine[m]> | ah |
| [13:36:18] | <symbioquine[m]> | Yeah, I see. |
| [13:36:35] | <mstenta[m]> | Lots of considerations to balance :-/ |
| [13:36:38] | <symbioquine[m]> | But there'd need to be a layer around it right? |
| [13:39:04] | <symbioquine[m]> | It seems nice to keep the farmOS-map package agnostic to Drupal concerns. |
| [13:39:44] | <symbioquine[m]> | A second package could wrap the farmOS-map artifacts up in the right format to be installable as a Drupal module. |
| [13:44:40] | <paul121[m]> | not sure what layer would be needed? are you thinking the js/css folder structure? |
| [13:45:45] | <symbioquine[m]> | Yeah, and it would probably be better to define the farmOS-map `libraries.yml` there. |
| [13:56:55] | <paul121[m]> | hmm. tricky because `libraries.yml` has other Drupal specific stuff too :-/ |
| [13:58:02] | <symbioquine[m]> | What do you mean? |
| [13:58:53] | <paul121[m]> | the Drupal specific map behavior JS is defined in there too |
| [13:59:49] | <symbioquine[m]> | Oh, yeah the parts that are specific to loading `js/farmOS.map.behaviors.wkt.js` et al would stay where they are |
| [14:00:28] | <symbioquine[m]> | I was just talking about pulling [this part](https://github.com/farmOS/farmOS/blob/83fe014b246a597c7b6ba7dd35195dafae...) into the separate package |
| [14:01:32] | <paul121[m]> | ah yeah |
| [14:28:34] | * shane_aldrich[m] has joined #farmos |
| [15:53:22] | * Kingdutch has quit (*.net *.split) |
| [15:55:06] | * Kingdutch has joined #farmos |