I started with farmos using the docker-composer.development.yml because at first I was just trying the tool.
But now I have a lot of taxonomic terms on crop family, related with a lot of plant types, related with a lot of seed assets and plants, all the property locations… Well I think that the more tedious work is done for me… in development.
I changed the docker-compose to match the docker-composer.production.yml and use the 2.0.0-beta4 image and noticed that instead of mounting the complete www (/opt/drupal) is only mounting the sites folder (/opt/drupal/web/sites). After upgrading, all installed modules where wiped out. So I copied all previously installed modules from a backup and got it working (with the error on the map layers that is reported here farmOS 2.0.0-beta4 has been released - #2 by oliverp44 )
I think all is fine, I tested and created new assets and logs, edited them, etc. But I’m not sure and I don’t wan’t to loose all data. If somebody reads this message and finds that I made some errors on the migration, please let me know.
Thanks in advance!
Edit: Another thig I had to do is chown www-data -R sites and chmod 755 -R sites and clear all caches
1 Like
The sites folder is the only one which is a bind mount on your production docker-compose.yml to start with, you will need to add additional bind mounts for any additional farmOS/Drupal modules which are not part of the farmOS docker image.
Which modules were you missing?
Did you just convert your dev server to production? It’s probably a good idea to keep a dev environment alongside production for testing out such major changes, I would have created a new separate production instance and then backed up and restored the data as it would have not left you with the danger of losing data and also given a trial run for restoring in case of future failures/misadventures.
2 Likes
After upgrading, all installed modules where wiped out.
I assume these were modules that you downloaded and installed alongside farmOS? Where did you install them?
The sites/all/modules directory is the recommended location (if you aren’t building via Composer), because you’ll preserve the whole sites directory between upgrades, as opposed to the modules directory in the Drupal webroot (which is populated by the Composer build process).
If you had the modules in another directory, and then moved them, Drupal may complain that it can’t find the files until you rebuild the cache (thankfully Drupal 8+ is more forgiving about this than Drupal 7 was - sometimes you could end up in a broken state).
I strongly second @Farmer-Ed’s suggestions. ALWAYS make sure you have a backup of both your database and files before moving things around like this. Be ready to roll back if/when something breaks. Or better yet, spin up a second instance and move things over to it, so you leave the “working” one untouched in the process.
I converted my dev folder to production 
I have docker installed in all the computers I have around and I was using a pen-drive with farmos as a portable app. But I was using the dev image and I changed it to the prod image.
I installed some modules (farm_map_google, farm_forest) via composer require+drush en, and it looks like this way the modules are installed as core. Now I copied the modules to sites/default/modules, cleaned all the caches (drush cc->the all option doesn’t work and you need to manually clear all caches one by one).
That was my initial intention, but I didn’t find how to do it. I found the “Backup and Migrate” project, I’ve read that drush can do that kind of things, but I wasn’t really sure. How would you do it?
1 Like
I installed some modules (farm_map_google, farm_forest) via composer require+drush en
Ah I see. Our documentation doesn’t cover how to manage your farmOS deployment via Composer currently - so that’s an “advanced” usage. I can provide some guidance, but you’re a bit on your own from there.
Are you very familiar with Composer? If so, then you can consider managing your deployment and pulling in additional modules with it. If you aren’t, then I would say stick with the “drag and drop” approach of adding modules to sites/all/modules. This isn’t always perfect either - if a module has other dependencies that need to be pulled in via Composer - but most of the known farmOS modules right now work fine.
If you do take that approach then what you would want to do is start a new Git repository and check your composer.json and composer.lock files into it, and manage it as a project, where farmOS is just one of your dependencies basically.
If you do that, then you would either need to continue bind-mounting the whole codebase (/opt/drupal) directory into the container (ignoring the recommendations in docker-compose.production.yml), or you would need to create your own downstream Docker image (very advanced).
drush cc->the all option doesn’t work and you need to manually clear all caches one by one
Use drush cr. That’s the new way to do it in Drupal 8+. drush cc was for Drupal 7-.
I found the “Backup and Migrate” project, I’ve read that drush can do that kind of things, but I wasn’t really sure.
Unfortunately, Backup and Migrate does not support PostgreSQL databases (see https://www.drupal.org/project/backup_migrate/issues/2930369).
I would just use pg_dump to create a database dump and then import that into your new database.
I installed them using composer require because it was the recommended way on the modules github repositories. Now are copied to sites/default/modules. Is that wrong? I’m not planning for multisite.
I don’t really NEED any of the installed modules. Ok, farm_map_google looks very nice, but the farm_forest I installed only to see a working plan entity (and, well, …) I also had the ledger, but I don’t intend to sell anything and uninstalled it.
I will install a clean image in a new folder and try to migrate the data from the actual database. I think I had some problems with the UUID of some taxonomic terms when I tried something similar with a broken instance, but maybe it was too broken… In the installed update I have the Assets tab in the taxonomic terms but not the Logs one, maybe it’s actually broken and I didn’t notice…
1 Like
That should work fine.
I will install a clean image in a new folder and try to migrate the data from the actual database.
Be sure to completely uninstall any modules from the old site that you do not plan to use in the new site. Otherwise Drupal will complain that they are missing.