Hi, in log edit view when I try to click on “add quantity” or “select asset” I receive the following error message as a js popup:
An error occurred while attempting to process /log/294/edit?ajax_form=1&_wrapper_format=drupal_ajax: ajax.$form.ajaxSubmit is not a function
Any idea on how to solve it? I just realized it some days ago. I don’t know what caused the error. Maybe it came with the last update of the docker image.
I’m using the regular farmos/farmos:latest docker-hub image.
Thanks for reporting @PDorfFarm!
I just tried this in farmOS 2.0.0 and wasn’t able to replicate it. Would you mind sharing a screenshot?
What browser/OS are you using? Does it work in a different browser?
Are you seeing any errors in your browsers console (in development tools)?
I’m using the regular farmos/farmos:latest docker-hub image.
FYI we recommend always using a specific version like farmos/farmos:2.0.0 instead of latest, so that you can be sure you are in control of updates. If you were to docker pull farmos/farmos:latest you won’t really know what version you were on and what version you are upgrading to, and you MUST remember to run drush updb immediately after each update.
As described here:
thank you once again @mstenta for your instant help!
I’m running Firefox on Ubuntu but I also tried chromium and safari. All showed the same error.
Browser console only showed a warning - no errors.
and you MUST remember to run
drush updbimmediately after each update.
I misunderstood the update instructions. I thought this is only required when using a packaged release. Thank you for this hint!
FYI we recommend always using a specific version like farmos/farmos:2.0.0 instead of latest, so that you can be sure you are in control of updates. If you were to docker pull farmos/farmos:latest you won’t really know what version you were on and what version you are upgrading to
I was already wondering how one can get the version of the image it is currently using. Your hint explained.
Now I have modified my docker to use farmos:2.0.0 and started the update procedure.
How ever the update fails. This is one of the error messages:
Drupal\Core\Database\DatabaseExceptionWrapper: Exception in Farm Asset GeoJSON[farm_asset_geojson]: SQLSTATE[42S02]: Base table or view not found: 1146 Table ‘farmos2.asset__owner’ doesn’t exist: SELECT “t”.* FROM “asset__owner” “t” WHERE (“entity_id” IN (:db_condition_placeholder_0, :db_condition_placeholder_1, :db_condition_placeholder_2, :db_condition_placeholder_3, :db_condition_placeholder_4, :db_condition_placeholder_5, :db_condition_placeholder_6)) AND (“deleted” = :db_condition_placeholder_7) AND (“langcode” IN (:db_condition_placeholder_8, :db_condition_placeholder_9, :db_condition_placeholder_10, :db_condition_placeholder_11)) ORDER BY “delta” ASC; Array ( [:db_condition_placeholder_0] => 49 [:db_condition_placeholder_1] => 50 [:db_condition_placeholder_2] => 51 [:db_condition_placeholder_3] => 52 [:db_condition_placeholder_4] => 53 [:db_condition_placeholder_5] => 54 [:db_condition_placeholder_6] => 67 [:db_condition_placeholder_7] => 0 [:db_condition_placeholder_8] => en [:db_condition_placeholder_9] => de [:db_condition_placeholder_10] => und [:db_condition_placeholder_11] => zxx ) in main() (Zeile 19 in /opt/drupal/web/index.php).
I think I missed to call the update procedure also with previous updates. maybe this now causes the issue.
I need to stop for today. will spend some more time on in tomorrow.
Anyways, thank you so far.
Do you know what version you were on previously? Did you take a backup snapshot of the database before attempting the update? Can you roll back to that version and restore the snapshot?
unfortunately i do not know which version I was on before. The docker image was pulled on 2022-09-29 with tag :latest
I did have a docker image saved with that state and I also had a backup of the database.
Now I reverted back the image to 2022-09-29. I imported the database with state 2 days ago.
Then I was able to run drush updb without errors.
Afterwards I switch image to tag :2.0.0 and when I try to run drush updb I get:
------------------- ------------------- ------------- ------------------------
Module Update ID Type Description
------------------- ------------------- ------------- ------------------------
farm_lab_test migrate_lab_terms post-update Migrate laboratory
names to taxonomy
terms.
farm_log_category create_log_catego post-update Create log categorize
rize_action action.
farm_migrate fix_input_log_qua post-update Fix migrated input log
ntity_materials quantity materials.
quantity plain_text_view_m post-update Create plain text view
ode mode for quantities.
------------------- ------------------- ------------- ------------------------
Do you wish to run the specified pending updates? (yes/no) [yes]:
> yes
> [notice] Update started: farm_lab_test_post_update_migrate_lab_terms
> [error] SQLSTATE[42S22]: Column not found: 1054 Unknown column 'lab_value' in 'field list': SELECT entity_id, lab_value FROM "log__lab" WHERE deleted = 0; Array
> (
> )
>
> [error] Update failed: farm_lab_test_post_update_migrate_lab_terms
> [notice] Reverted config: core.entity_form_display.taxonomy_term.plant_type.default
> [notice] Reverted config: core.entity_view_display.asset.animal.map_popup
> [notice] Reverted config: core.entity_view_display.asset.equipment.map_popup
> [notice] Reverted config: core.entity_view_display.asset.land.map_popup
> [notice] Reverted config: core.entity_view_display.asset.plant.map_popup
> [notice] Reverted config: core.entity_view_display.asset.structure.map_popup
> [notice] Reverted config: core.entity_view_display.taxonomy_term.plant_type.default
> [notice] Reverted config: log.type.input
> [notice] Reverted config: log.type.lab_test
> [notice] Reverted config: system.action.asset_assign_action
> [notice] Reverted config: system.action.asset_parent_action
[error] Update aborted by: farm_lab_test_post_update_migrate_lab_terms
[error] Finished performing updates.
However I do not see any of the previous errors when I access farmos and try to edit log entries. But I would like drush updb to complete successfully.
Should I move on to 2.0.1 and run drush updb
or should I start again with image 2022-09-29 and an older backup of the database (e.g. 1 month old)
What would you suggest?
So I tried
A) continue to update to version 2.0.1 after my previous post. ==> same error as in the post above
B) I think the image I have been using before recognizing the initial issue dates back to 2022-09-29 (don’t know which version this was). I took a database backup from 2022-08-21 and ran this with image from 2022-09-29. I was able to run drush updb with out any errors.
Then I update image to version 2.0.0 and I receive the same error message as posted above. Same happens if I update Image to 2.0.1
It seems that my error is somehow related to farm_lab_test table. This error appears as soon as I update to version 2.0.0 or above.
I do have one log entry of type lab test. I also tried to delete this entry and still not able to run drush updb successfully.
However I do not experience any issues in using farmos.
I’m running out of ideas. Any suggestions what I could try?
Based on the dates of releases, that probably mean you were either on 2.0.0-beta6 or 2.0.0-beta7 (beta 7 was released on 2022-09-29, but it’s hard to say which one it was pointed to when you pulled). It shouldn’t really matter though. These updates should work regardless, unless something strange happened.
[error] SQLSTATE[42S22]: Column not found: 1054 Unknown column 'lab_value' in 'field list': SELECT entity_id, lab_value FROM "log__lab" WHERE deleted = 0; Array
This is coming from this line: https://github.com/farmOS/farmOS/blob/18599f80c3d2e298a62aff276e10e3f898f22a66/modules/log/lab_test/farm_lab_test.post_update.php#L65
What’s happening is: the update function is trying to query the lab_value column of your log__lab database table, but it doesn’t exist in your database. The purpose of that update hook is to convert the lab field on lab_test logs from a text field to a taxonomy term reference field (and create a taxonomy term for each lab), so it has to query that table to get all the existing lab values. One of the things this update function does is delete that table, after it is done gathering information from it, so that it can recreate the table with a different structure.
No idea why you’re running into this… only thing I can think is that a previous attempt at the update actually succeeded (partially), but maybe something failed before it completed so Drupal thinks it still needs to run.
I do have one log entry of type lab test. I also tried to delete this entry and still not able to run drush updb successfully.
Since you only have one lab test log, the easiest workaround I can think of is: comment out all the code inside that farm_lab_test_post_update_migrate_lab_terms() function, run drush updb, and then go back in and fix the “lab” on your one lab test log. 
Depending on how your Docker volume mounts are set up (I’m making some assumptions based on context in this thread), you will probably need to edit it from inside the www container while it’s running. Here are the rough steps to do that on the command line (find the container ID via sudo docker ps):
www container: sudo docker exec -it [container-id] bashapt-get install -y vimvi /opt/drupal/web/profiles/farm/modules/log/lab_test/farm_lab_test.post_update.phpfarm_lab_test_post_update_migrate_lab_terms:farm_lab_test_post_update_migrate_lab_terms to find the function.return; (this will tell the function to stop immediately before running any of the other logic in it - easier than commenting/deleting every line, but either will work).:wq, and press “Enter”.exit to exit the container’s bash shell.drush updb again.Good luck!
thank you very much for your detailed description on how to fix the issue.
I followed your instructions (using image version 2.0.0). When I skip the function farm_lab_test_post_update_migrate_lab_terms() with a return statement right after opening I receive another error on a different module. I’m wondering how this related to farmos v1? I did a migration of v1 to v2 already in summer last year.
root@4379b46fecfd:/opt/drupal# drush updb
-------------- --------------------- ------------- ------------------------
Module Update ID Type Description
-------------- --------------------- ------------- ------------------------
farm_migrate fix_input_log_quant post-update Fix migrated input log
ity_materials quantity materials.
quantity plain_text_view_mod post-update Create plain text view
e mode for quantities.
-------------- --------------------- ------------- ------------------------
Do you wish to run the specified pending updates? (yes/no) [yes]:
> yes
> [notice] Update started: farm_migrate_post_update_fix_input_log_quantity_materials
> [notice] This update will attempt to fix an issue with the migration of input log material data from farmOS v1. To skip this update, add this line to settings.php: $settings['farm_migrate_skip_input_log_migration_fix'] = TRUE;
> [notice] There are 14 logs affected by this issue.
> [error] Could not connect to the farmOS v1 database. Add `migrate` database to settings.php and re-run this update to continue.
> [error] Update failed: farm_migrate_post_update_fix_input_log_quantity_materials
> [notice] Reverted config: core.entity_form_display.taxonomy_term.plant_type.default
> [notice] Reverted config: core.entity_view_display.asset.animal.map_popup
> [notice] Reverted config: core.entity_view_display.asset.equipment.map_popup
> [notice] Reverted config: core.entity_view_display.asset.land.map_popup
> [notice] Reverted config: core.entity_view_display.asset.plant.map_popup
> [notice] Reverted config: core.entity_view_display.asset.structure.map_popup
> [notice] Reverted config: core.entity_view_display.taxonomy_term.plant_type.default
> [notice] Reverted config: log.type.input
> [notice] Reverted config: log.type.lab_test
> [notice] Reverted config: system.action.asset_assign_action
> [notice] Reverted config: system.action.asset_parent_action
[error] Update aborted by: farm_migrate_post_update_fix_input_log_quantity_materials
[error] Finished performing updates.
The log__lab table does exist before I ran drush updb. This is what it looks like
I realized that this one entry in this table has a special character ‘ü’ in the field lab_value. Do you think this could cause a problem? But I also tried out with removing this special character and started from scratch again and it did not change anything…
Do you have any further advice?
Yea, it looks like my suggestion got you through ONE of the update hooks, but then you encountered an error on a DIFFERENT one.
Yes it is. See the release notes for farmOS 2.0.0-beta8 for a description of what’s happening here: https://github.com/farmOS/farmOS/blob/2.x/CHANGELOG.md#200-beta8-2022-11-25
This release fixes an issue with the input log migration from farmOS v1. If you have migrated input logs from farmOS v1, and they referenced multiple material types, they may have been affected. An update hook is included with this release that will attempt to re-connect to the v1 database used during migration to automatically fix the issue. If the v1 database is no longer available, then you will need to fix these logs manually. For more information, see: #579
If you would like to skip the automatic fix, add the following line to your
settings.php(this can be removed after running update.php):
$settings['farm_migrate_skip_input_log_migration_fix'] = TRUE;
So… you have a choice. If you still have your v1 database available, and you think you may have been affected by this issue (according to the error you have 14 logs that are affected), this update hook will fix it. But it needs to be able to connect to the v1 database just like you did during the initial v1->v2 migration. If you no longer have your v1 database available, then your only choice is to add that line to settings.php and run the update again so it can complete.
Thank you once again @mstenta ! I had my v1 database still available and I was able to overcome this issue as well.
One thing is left:
I think the table log__lab is not availabe anymore. Am I correct? Are there other tables I can remove from my database?
The log__lab table IS still used - it was just changed so that it references Lab taxonomy terms now. Don’t delete it! 
Generally speaking you should never have to touch database tables/columns directly… if we’re doing our job right it’s all handled automatically.
