| [07:36:55] | <skipper_is[m]> | <mstenta[m] "So what you might want to do is "> That's quite involved.. |
| [07:37:05] | <skipper_is[m]> | Aliased it to another folder in the end... Seems to work |
| [07:38:35] | <skipper_is[m]> | I've got a load of other things in the same root |
| [07:39:07] | <skipper_is[m]> | It worked if vendor was also in /html/ but I imagine there are probably security risks associated with that |
| [07:40:47] | <mstenta[m]> | That's the main reason to keep it out, yes |
| [07:41:26] | <mstenta[m]> | Another option is to create another virtual host config for it and put it somewhere else entirely |
| [07:41:43] | <mstenta[m]> | Eg /var/farmOS |
| [07:41:57] | <skipper_is[m]> | Yea, I tried that, but couldn't figure out how to get Apache to accept a subdomain |
| [07:42:34] | <mstenta[m]> | In the Docker container the codebase is in /opt/drupal and /var/www/html is symlinked to /opt/drupal/web |
| [07:43:07] | <mstenta[m]> | But if you have other stuff in /var/www/html that won't help |
| [07:43:24] | <skipper_is[m]> | Ooh, I could just have the /html/farmOS2/ symlinked to wherever the codebase is? |
| [07:43:59] | <skipper_is[m]> | Or would that not work? |
| [07:44:17] | <mstenta[m]> | Yea could work? |
| [07:44:28] | <skipper_is[m]> | For now alias works |
| [07:44:48] | <skipper_is[m]> | Oh wow, it looks really different... |
| [07:48:12] | <skipper_is[m]> | Is it possible to import things from FarmOS1.x? |
| [07:48:24] | <mstenta[m]> | Yes! |
| [07:48:56] | <mstenta[m]> | https://docs.farmos.org/hosting/migration/ |
| [07:50:05] | <skipper_is[m]> | That's not going to overwrite the FarmOS1x data? |
| [07:50:52] | <mstenta[m]> | Nope read only |
| [07:51:28] | <skipper_is[m]> | Excellent :) |
| [07:51:57] | <mstenta[m]> | It's the PostgreSQL migration you've been waiting for skipper_is :-) |
| [07:52:28] | <skipper_is[m]> | woo! |
| [07:52:57] | <skipper_is[m]> | No more weirdd erro..... nvm |
| [07:55:29] | <skipper_is[m]> | hmm... no Drush |
| [07:56:57] | <skipper_is[m]> | Oh, it's in vendor? |
| [07:59:54] | <skipper_is[m]> | `farm_migrate_file Migration - 593 failed.` |
| [07:59:57] | <skipper_is[m]> | oOo |
| [08:04:24] | <mstenta[m]> | https://docs.farmos.org/hosting/migration/#migrating-files |
| [08:12:59] | <skipper_is[m]> | Hmm, it's also saying `Migration farm_migrate_taxonomy_plant_type is busy with another operation: Importing` |
| [08:13:09] | <skipper_is[m]> | Although I think that process failed.. |
| [08:13:12] | <skipper_is[m]> | Is there a reset? |
| [08:33:53] | <mstenta[m]> | Ah yea there is a reset... |
| [08:34:16] | <mstenta[m]> | `drush migrate:reset-status farm_migrate_taxonomy_plant_type` |
| [08:34:40] | <mstenta[m]> | might want to rollback too: `drush migrate:rollback farm_migrate_taxonomy_plant_type` |
| [09:23:51] | <symbioquine[m]> | ACTION < https://matrix.org/_matrix/media/r0/download/matrix.org/ZmDvVxKtacAIqtcj... > |
| [09:33:30] | <mstenta[m]> | symbioquine: interesting! so basically keeping things the way they are (eg: import certain OL pieces that we "support", and as new layer types or other OL features are requested, we add farmOS-map API support for them via PRs), but "lazy chunks" will offset the growing size of that |
| [09:35:10] | <symbioquine[m]> | Yes and no. We can definitely incorporate common stuff as core behaviors, but even for contrib modules my testing seems to show that modest amounts of duplicate library bundling are cheaper than the things we could do to avoid it... |
| [09:36:01] | <mstenta[m]> | > but "lazy chunks" will offset the growing size of that |
| [09:36:16] | <mstenta[m]> | but "lazy chunks" will _somewhat_ offset the growing size of that |
| [09:36:33] | <symbioquine[m]> | Yeah |
| [09:36:39] | <mstenta[m]> | cool |
| [09:36:57] | <mstenta[m]> | that makes sense |
| [09:37:00] | <mstenta[m]> | and feels like a logical next step... |
| [09:37:36] | <mstenta[m]> | i was interested in seeing what benefits might come from externalizing ol.js and/or module federation... but tbh was a bit worried about the complexity |
| [09:37:51] | <mstenta[m]> | maybe 3.x :-) |
| [09:38:17] | <skipper_is[m]> | Ah my FarmOS2x migration failed... `"Error: Call to a member function getX() on null in Drupal\geofield\Plugin\Field\FieldType\GeofieldItem->populateComputedValues() (line 240 of /var/www/farmOS2/web/modules/geofield/src/Plugin/Field/FieldType/GeofieldItem.php)."` |
| [09:38:26] | <mstenta[m]> | thanks again for taking the time to review all this so thoroughly! |
| [09:38:29] | <symbioquine[m]> | <mstenta[m] "i was interested in seeing what "> Me too. It feels like something we need to come back to. |
| [09:38:55] | <mstenta[m]> | > `Error: Call to a member function getX()` |
| [09:38:56] | <mstenta[m]> | Hmm sounds familiar... |
| [09:44:04] | <mstenta[m]> | Ah this is what I was remembering: |
| [09:44:05] | <mstenta[m]> | https://github.com/farmOS/farmOS/issues/161 |
| [09:44:10] | <mstenta[m]> | https://www.drupal.org/project/geophp/issues/3050510 |
| [09:46:10] | <mstenta[m]> | Ah hmm I'm just realizing: we aren't patching the GeoPHP anymore... we probably should be |
| [09:46:18] | <mstenta[m]> | (not sure if that explains this issue, maybe...) |
| [09:59:10] | <mstenta[m]> | skipper_is: what version of PHP are you using? |
| [10:13:13] | * appservice[m] has joined #farmos |
| [11:10:02] | * mstenta has quit (Quit: Leaving) |
| [12:54:13] | <paul121[m]> | <symbioquine[m] "Me too. It feels like something "> Dang. I was excited to have all of OL available :-) |
| [12:55:02] | <paul121[m]> | but still lots of improvements! |
| [12:55:11] | <symbioquine[m]> | All of OL is available. |
| [12:56:01] | <symbioquine[m]> | My performance testing suggests that a modest amount of duplication from bundling OpenLayers yields the best results... |
| [12:56:26] | <paul121[m]> | ah, I meant available for behaviors without bundling OL themselves. just out of convenience |
| [12:56:54] | <paul121[m]> | but maybe that's just legacy thinking anyways haha |
| [12:56:55] | <symbioquine[m]> | <paul121[m] "ah, I meant available for behavi"> Yeah, that would have been really nice! |
| [12:58:09] | <symbioquine[m]> | <paul121[m] "but maybe that's just legacy thi"> I don't know, I suspect that there will be more innovation in the module federation space... It just doesn't seem ready to help us with this scenario yet. |
| [12:58:47] | <paul121[m]> | yeah that makes sense |
| [12:59:05] | <paul121[m]> | farmOS will keep pushing the boundaries :P |
| [13:27:14] | * wgardiner[m] has quit (*.net *.split) |
| [13:27:14] | * JzsefSomogyi[m] has quit (*.net *.split) |
| [13:27:14] | * NausiyanNyancurr has quit (*.net *.split) |
| [13:27:14] | * aerocity[m] has quit (*.net *.split) |
| [13:27:14] | * dee has quit (*.net *.split) |
| [13:27:15] | * paul121[m] has quit (*.net *.split) |
| [13:27:15] | * kunigunde[m] has quit (*.net *.split) |
| [13:27:15] | * skipper_is[m] has quit (*.net *.split) |
| [13:27:15] | * JasonGMS[m] has quit (*.net *.split) |
| [13:27:15] | * calbasi_matrix has quit (*.net *.split) |
| [13:27:15] | * cw28cycles[m] has quit (*.net *.split) |
| [13:27:15] | * symbioquine[m] has quit (*.net *.split) |
| [13:27:15] | * shane_aldrich[m] has quit (*.net *.split) |
| [13:27:15] | * mstenta[m] has quit (*.net *.split) |
| [13:27:15] | * lg0[m] has quit (*.net *.split) |
| [13:27:15] | * botlfarm[m] has quit (*.net *.split) |
| [13:27:15] | * kta[m] has quit (*.net *.split) |
| [13:27:15] | * dazinism has quit (*.net *.split) |
| [13:27:15] | * ssoyrnoz[m] has quit (*.net *.split) |
| [13:27:15] | * med65[m] has quit (*.net *.split) |
| [13:27:15] | * appservice[m] has quit (*.net *.split) |
| [13:27:15] | * JulianF has quit (*.net *.split) |
| [13:27:15] | * andyepx[m] has quit (*.net *.split) |
| [13:27:15] | * svenn has quit (*.net *.split) |
| [13:27:15] | * mmn has quit (*.net *.split) |
| [13:27:16] | * Kingdutch has quit (*.net *.split) |
| [13:33:30] | * Kingdutch has joined #farmos |
| [13:33:30] | * appservice[m] has joined #farmos |
| [13:33:30] | * andyepx[m] has joined #farmos |
| [13:33:30] | * paul121[m] has joined #farmos |
| [13:33:30] | * kunigunde[m] has joined #farmos |
| [13:33:30] | * dee has joined #farmos |
| [13:33:30] | * skipper_is[m] has joined #farmos |
| [13:33:30] | * JasonGMS[m] has joined #farmos |
| [13:33:30] | * ssoyrnoz[m] has joined #farmos |
| [13:33:30] | * wgardiner[m] has joined #farmos |
| [13:33:30] | * shane_aldrich[m] has joined #farmos |
| [13:33:30] | * symbioquine[m] has joined #farmos |
| [13:33:30] | * med65[m] has joined #farmos |
| [13:33:30] | * JzsefSomogyi[m] has joined #farmos |
| [13:33:30] | * botlfarm[m] has joined #farmos |
| [13:33:30] | * lg0[m] has joined #farmos |
| [13:33:30] | * mstenta[m] has joined #farmos |
| [13:33:30] | * NausiyanNyancurr has joined #farmos |
| [13:33:31] | * kta[m] has joined #farmos |
| [13:33:31] | * cw28cycles[m] has joined #farmos |
| [13:33:31] | * JulianF has joined #farmos |
| [13:33:31] | * calbasi_matrix has joined #farmos |
| [13:33:31] | * dazinism has joined #farmos |
| [13:33:31] | * aerocity[m] has joined #farmos |
| [13:33:31] | * svenn has joined #farmos |
| [13:33:31] | * mmn has joined #farmos |
| [13:47:21] | <skipper_is[m]> | <mstenta[m] "skipper_is: what version of PHP "> PHP 7.4 |
| [13:48:13] | <mstenta[m]> | Hmm which migration were you running when it failed? |
| [13:48:21] | <skipper_is[m]> | logs |
| [13:48:39] | <mstenta[m]> | Ok I wonder if maybe one of them has a malformed geometry |
| [13:48:49] | <mstenta[m]> | I would probably try to figure out exactly which log failed |
| [13:49:51] | <mstenta[m]> | Each log type has a separate migration (in the `farm_migrate_log` group) - so you can probably figure out which log type it was to narrow it down |
| [13:50:08] | <mstenta[m]> | `drush migrate:status --tag="farmOS 1.x"` will show you the status of all migrations, organized by group |
| [13:50:30] | <skipper_is[m]> | In messages I've got 407 has geom and movement, but it is happy with that now I've changed settings.php |
| [13:50:33] | <mstenta[m]> | look in the `farm_migrate_log` group to see which one was partially completed |
| [13:50:54] | <mstenta[m]> | ahhhh yes... |
| [13:51:04] | <mstenta[m]> | did you read the info about that in the docs? |
| [13:51:10] | <skipper_is[m]> | Yea |
| [13:51:19] | <skipper_is[m]> | So I'm assuming it isn't that causing problems now |
| [13:51:47] | <skipper_is[m]> | ACTION uploaded an image: (56KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/ogSteChJSWtarSpn... > |
| [13:52:02] | <skipper_is[m]> | Done 192/493, but that doesn't equal ID number.. |
| [13:52:11] | <mstenta[m]> | Yea the `getX()` issue is something different |
| [13:52:27] | <mstenta[m]> | ok so it's an activity log probably |
| [13:52:57] | <mstenta[m]> | the fact that it worked for some means it's probably an issue with just that one log |
| [13:53:03] | <mstenta[m]> | might have an invalid geometry |
| [13:53:28] | <mstenta[m]> | so next step is to figure out the original log ID (from 1.x) |
| [13:53:49] | <skipper_is[m]> | Indeed... |
| [13:54:00] | <skipper_is[m]> | There are some other erros before hand: |
| [13:54:08] | <mstenta[m]> | the `migrate_map_farm_migrate_log_activity` should help... |
| [13:54:14] | <mstenta[m]> | * the `migrate_map_farm_migrate_log_activity`database table should help... |
| [13:54:22] | <skipper_is[m]> | ACTION uploaded an image: (205KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/swecBYplpHWyviFm... > |
| [13:54:33] | <mstenta[m]> | that will show all the original IDs and new IDs created during the migration |
| [13:54:54] | <skipper_is[m]> | Ah, so look for the one it stopped on, and add one? |
| [13:55:14] | <mstenta[m]> | yea maybe |
| [13:56:00] | <mstenta[m]> | re: those messages... those are not from the farmOS migrations... the core `migrate_drupal` module adds some migrations of its own, which you don't need... what caused those to show up for you? what command did you run? |
| [13:56:30] | <skipper_is[m]> | Those came up alongside the log migration I think |
| [13:56:53] | <mstenta[m]> | hmm that should not happen |
| [13:57:13] | <mstenta[m]> | can you copy the exact commands you ran? |
| [13:57:45] | <mstenta[m]> | (i'm assuming you're following the steps outlined here: https://docs.farmos.org/hosting/migration/) |
| [13:57:59] | <skipper_is[m]> | I am indeed |
| [13:58:09] | <skipper_is[m]> | That is from messages |
| [13:58:16] | <skipper_is[m]> | migrate:messages |
| [13:58:18] | <mstenta[m]> | ah ok |
| [13:58:22] | <mstenta[m]> | that makes sense i think |
| [13:58:37] | <mstenta[m]> | use `drush migrate:messages [migration-id]` to get specific migration messages |
| [13:58:47] | <mstenta[m]> | eg: `drush migrate:messages farm_migrate_log_activity` |
| [13:59:03] | <mstenta[m]> | otherwise it will give messages for ALL migrations (including the drupal ones you don't want) |
| [13:59:24] | <skipper_is[m]> | The last migration ID was 589, but id 590 doesn't seem to have anything weird.. |
| [13:59:44] | <skipper_is[m]> | No custom geometry, no movement |
| [13:59:44] | <mstenta[m]> | `--tag="farmOS 1.x"` will also limit which migrations are referenced... but i'm not sure if that works with `migrate:messages` |
| [13:59:48] | <skipper_is[m]> | Just tagged the garden |
| [13:59:54] | <mstenta[m]> | did you look at 589 too? |
| [13:59:58] | <mstenta[m]> | maybe it was that one? |
| [14:00:27] | <skipper_is[m]> | Ah fair point |
| [14:00:28] | <mstenta[m]> | (more likely maybe) |
| [14:00:41] | <mstenta[m]> | (because the migration would have created the new log before it hit this issue) |
| [14:00:42] | <skipper_is[m]> | Same really |
| [14:01:10] | <skipper_is[m]> | Weird |
| [14:01:49] | <skipper_is[m]> | Ah, so that error is from migration:status |
| [14:02:20] | <mstenta[m]> | ooh ok - so yea use `drush migrate:status --tag="farmOS 1.x"` instead |
| [14:03:09] | <skipper_is[m]> | Oh, I've just set it up to rollback the log changes |
| [14:03:14] | <mstenta[m]> | couple things to check on that log: |
| [14:03:14] | <mstenta[m]> | - is the geometry Data field completely blank, or does it have `GEOMETRYCOLLECTION EMPTY` or something like that? |
| [14:03:14] | <mstenta[m]> | - is there a "Move to" area referenced in the movement, but no geometry? |
| [14:04:09] | <mstenta[m]> | also curious: does that log ID show up in the `Log 123 has both a geometry and a movement geometry.` or `Log 123 has both area references and movement area references.` messages? |
| [14:04:54] | <skipper_is[m]> | So with that tag, there is no big red error page |
| [14:05:14] | <mstenta[m]> | lastly, what happens if you try to edit that log in the 2.x site? it sounds like the log may have been created, even if the migration failed... |
| [14:05:24] | <mstenta[m]> | curious if the new log has a geometry |
| [14:07:00] | <mstenta[m]> | FWIW I've only really tested migrations on a couple of different databases thus far, so this is still very much an alpha migration testing phase right now... you're helping to find bugs! :-) |
| [14:07:33] | <mstenta[m]> | (and/or finding issues with old data... which i've also encountered) |
| [14:09:53] | <skipper_is[m]> | Found it! |
| [14:09:57] | <skipper_is[m]> | Geometry Empty Collection |
| [14:10:41] | <skipper_is[m]> | So, the import that failed, is there a retry? Or resome? Or is it a matter of migrate:stop x migrate:reset-status and run it again? |
| [14:10:45] | <mstenta[m]> | oh? where? in the movement geom or the regular geom? |
| [14:10:54] | <skipper_is[m]> | No, so different log |
| [14:11:02] | <mstenta[m]> | (i'm not sure that is actually an issue or not... curious if this will make a difference) |
| [14:11:12] | <skipper_is[m]> | I pulled up the database table again |
| [14:11:29] | <skipper_is[m]> | And looked at the last item on the list, then realised that they were not actually incremented |
| [14:11:47] | <skipper_is[m]> | (There was a 600 and something a few cells above the bottom one of 589( |
| [14:12:04] | <skipper_is[m]> | So I sorted them by ID, thinking that maybe they're done by ID order... makes sense |
| [14:12:12] | <skipper_is[m]> | And the last one +1 was a empty geom |
| [14:12:14] | <mstenta[m]> | ah! |
| [14:12:27] | <mstenta[m]> | ok interesting... this might warrant a bug report if it is indeed the cause |
| [14:12:32] | <mstenta[m]> | i wouldn't think that would break things... |
| [14:12:42] | <mstenta[m]> | so let's see... did you clear that out in the 1.x log? |
| [14:12:51] | <mstenta[m]> | (and was that in the movement geom or the normal geom?) |
| [14:13:20] | <skipper_is[m]> | It was just a log about clearing some weeds in a field, and I'd tagged the area, but the geom was empty |
| [14:13:23] | <skipper_is[m]> | So I've just done stop, reset-status and rollback |
| [14:13:24] | <mstenta[m]> | > So, the import that failed, is there a retry? Or resome? Or is it a matter of migrate:stop x migrate:reset-status and run it again? |
| [14:13:24] | <mstenta[m]> | yes do `drush migrate:reset-status farm_migrate_log_activity` then `drush migrate:rollback farm_migrate_log_activity` and then `drush migrate:import farm_migrate_log_activity` |
| [14:13:37] | <skipper_is[m]> | Had to do stop first, or it hated me... |
| [14:14:01] | <mstenta[m]> | very curious if this will actually fix it... might now... |
| [14:14:07] | <mstenta[m]> | * very curious if this will actually fix it... might not... |
| [14:14:12] | <skipper_is[m]> | Indeed |
| [14:14:39] | <skipper_is[m]> | I skipped importing sensor data, is that likely to be game breaking? |
| [14:14:40] | <mstenta[m]> | `GEOMETRYCOLLECTION EMPTY` is still valid I believe... |
| [14:15:02] | <skipper_is[m]> | A location was tagged though, the location has valid geom |
| [14:15:08] | <skipper_is[m]> | But the geom box was empty |
| [14:15:18] | <mstenta[m]> | > I skipped importing sensor data, is that likely to be game breaking? |
| [14:15:18] | <mstenta[m]> | if you're just testing this out, then i would recommend AGAINST importing sensor data for now... we need to make that migration more performant... it takes a silly long time |
| [14:15:31] | <skipper_is[m]> | Yea, I can imagine... |
| [14:15:39] | <mstenta[m]> | > But the geom box was empty |
| [14:15:39] | <mstenta[m]> | empty? or `GEOMETRYCOLLECTION EMPTY`? |
| [14:16:17] | <mstenta[m]> | brb toddler naptime |
| [14:16:50] | <skipper_is[m]> | GEOMETRYCOLLECTION EMPTY empty |
| [14:17:18] | <skipper_is[m]> | So maybe it was displeased tjhat there was disparity between the location geom and the geom I'd told it? |
| [14:17:54] | <skipper_is[m]> | Oh, I've only got 370707 sensor readings! |
| [14:18:14] | <skipper_is[m]> | (Activity log has succeeded) |
| [14:19:17] | <skipper_is[m]> | harvest also worked, but input failed.. |
| [14:25:35] | <skipper_is[m]> | So same issue on input, a location was tagged, but the geometry was empty collection |
| [14:31:52] | <skipper_is[m]> | Ok, so import all worked :) |
| [14:34:31] | <skipper_is[m]> | I shall have a play. The only main issue on importing is that none of my areas have imported, as they're a custom location type (pasture) |
| [14:34:59] | <skipper_is[m]> | And no quick forms? |
| [14:58:18] | <mstenta[m]> | > GEOMETRYCOLLECTION EMPTY empty |
| [14:58:18] | <mstenta[m]> | interesting... i will open a bug report for this... we can pretty easily discard these empty geometries during migration so that they don't throw an error (and the geometry will be automatically repopulated from the location) |
| [15:06:44] | <mstenta[m]> | https://www.drupal.org/project/farm/issues/3216608 |
| [15:07:47] | <mstenta[m]> | > So maybe it was displeased tjhat there was disparity between the location geom and the geom I'd told it? |
| [15:07:47] | <mstenta[m]> | This shouldn't matter... farmOS allows location geom =/= log geom - it's probably an issue with the Geofield module not working with `GEOMETRYCOLLECTION EMPTY` WKT |
| [15:08:36] | <mstenta[m]> | > The only main issue on importing is that none of my areas have imported, as they're a custom location type (pasture) |
| [15:08:36] | <mstenta[m]> | Did you make a custom module to provide this `pasture` area type in 1.x? |
| [15:08:54] | <mstenta[m]> | If so, it's pretty easy to make a 2.x version of your module to provide the same... |
| [15:09:15] | <mstenta[m]> | You basically need two pieces: a new "land type", and a migration for it |
| [15:10:03] | <mstenta[m]> | https://docs.farmos.org/development/module/fields/#land-type |
| [15:10:56] | <mstenta[m]> | check out the `farm_land_types` module in 2.x that provides default land types: https://github.com/farmOS/farmOS/tree/2.x/modules/asset/land/types |
| [15:11:39] | <mstenta[m]> | That'll show how to define a new land type in your module, as well as how to add a map style to give it a color in the map |
| [15:12:22] | <mstenta[m]> | (available color names: https://github.com/farmOS/farmOS-map/blob/4892a77f7d3ef4abb7c7c1472a8682...) |
| [15:13:46] | <mstenta[m]> | For the migration, you just need a file like this in your modules `config/optional` directory: https://github.com/farmOS/farmOS/blob/2.x/modules/core/migrate/config/op... |
| [15:14:11] | <mstenta[m]> | (alternatively, you could just hack that file in farmOS 2.x core to add `pasture`) |
| [15:14:47] | <mstenta[m]> | > And no quick forms? |
| [15:14:47] | <mstenta[m]> | Nope not yet... that's one of the next things on the list... |
| [16:43:08] | <shane_aldrich[m]> | ACTION uploaded an image: (126KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/vkLHulwqVrIfnQYI... > |
| [16:43:27] | <shane_aldrich[m]> | <shane_aldrich[m] "image.png"> Woo hoo! |
| [16:59:51] | <skipper_is[m]> | ACTION < https://matrix.org/_matrix/media/r0/download/matrix.org/arXMiiXneyPSnTAU... > |
| [17:01:00] | <skipper_is[m]> | So I'd need to make a custom migration and a custom module to add those and migrate those? |
| [17:02:27] | <mstenta[m]> | Yup |
| [17:03:10] | <mstenta[m]> | Custom module to add the types at the very least (can hack them into the existing migration if you want) |
