Document how the Farm Sensor module works, as well as the Farm Sensor: Listener module, and how to set up sensors and stream them to farmOS.

Cross post: Document Google Maps API key requirements

https://www.drupal.org/node/2768895

We currently use Mkdocs to generate farmOS.org as a static site from Markdown files. Mkdocs is nice because it is very simple, provides a default template (no theming necessary), and focuses on creating documentation.

Hugo is another static site generator that is more general (not specific to documentation). We may want to consider transitioning to Hugo in the future to give us more flexibility. Hugo provides some things that Mkdocs does not, like URL aliases/redirects (we're currently hacking that in with some custom JS), and it would allow more than 2 levels of menus (which is a pretty big limitation for us now, especially as the farmOS.org User Guide grows).

It may also allow us to host documentation for both the 7.x-1.x branch and the 8.x-2.x branch in the same repo, and potentially merge all of that directly into the farmOS repo itself (farmOS/farmOS.org#22).

https://github.com/peaceiris/actions-gh-pages

Hi,

I would like to translate farmOS to Spanish. Having English and Spanish, farmOS would cover two of three most spoken languages in the World.

Could you document how to translate? If so, I would happy to translate all farmOS components.

Just had this idea a moment ago: rather than maintaining a FAQ page on farmOS.org, perhaps we should just create a pinned forum topic that we use to organize frequently asked questions (along with links to relevant forum posts).

farmOS Forum: https://farmOS.discourse.group

Something to consider during the Gatsby redesign perhaps? #76

I realized we never really documented this, I guess because we had farmos.app as a default, but I think it would be good to add to documentation once we merge in the multiple_origins branch (farmOS/farmOS#271) so anyone can add additional clients to their list of allowed origins. Realizing this would be good for farmOS/field-kit#214, as well, if someone wants to host a fork of Field Kit in another language.

Leaving this issue here in the hopes I'll remember to do so.

It's come up a few times that users are trying to connect Field Kit to their farmOS server that is not running with an SSL cert (ie, on http instead of https). I need to remember to add a requirements section for Field Kit. I'm wondering, however, if this should include a link to the docs being added by PR #66, for configuring https and a reverse proxy on local networks.

Specifically here: http://docs.farmos.org/development/best-practice

For example, custom fields can be added to entities, but beware of future namespace collisions: https://www.drupal.org/node/2735785#comment-11239875

Modifying Views columns are a little more tricky, because the only way to get updates is to revert the View entirely. Perhaps the recommended approach should be to clone the View and set it up to take the place of the original (maybe even manually disable the original).

What other components would people be customizing regularly?

Farm Soil
Farm Soil Test
Farm Soil NRCS

This farmOS.org documentation repository is currently separate from the core farmOS repo. In the 8.x-2.x branch of farmOS I have decided to include the documentation directly in the repo. Should we merge this repo into the 7.x-1.x branch for consistency?

The homepage is not displaying responsively on mobile because the video embeds are breaking the layout. This is especially an issue with the menu, which is pushed off the screen.

Add information about how to use the REST API endpoints provided by the Restful Web Services module.

Hello together,
as you probably have seen in the riot chat i had some problems with my farmOS running on an nginx server.
So i looked a bit deeper into the reverse proxy guide and tried to setup it up on my Windows 10 machine and after some try and error i was successful.

One problem i can into with the docker file:

Problem: Mounting files on windows

docker-compose.yml

volumes:
      - './nginx.conf:/etc/nginx/nginx.conf'
      - './nginx/error_logs:/etc/nginx/error_logs'
      - './devcerts:/etc/nginx/certs'

It seems like its not possible to mount files in windows (as described here: https://stackoverflow.com/questions/58864411/cant-mount-file-on-windows-container - i couldn't find a source for that from docker)

Solution:

docker-compose.yml

volumes:
      - './nginx:/etc/nginx/'

i moved all files in one dir to solve that issue. The new structure looks like this:

nginx/ 
--| nginx.conf 
--| error_logs/
--| certs/
       --| cert.pem
       --| key.pem

Conclusion:

Is there any demand for an full windows guide? Then i could try to provide one

farmOS 7.x-1.0-rc1 was released on November 14th: https://www.drupal.org/project/farm/releases/7.x-1.0-rc1

There are still some things that need to be updated in the farmOS.org user guide to reflect new features and changes. I have a todo list, but haven't had a chance to wrap it up myself, so I'm posting it here in case anyone else has time before I do.

• cloning assets
• KML export
• sale and purchase logs
• map address lookup
• php 7 support?
• openlayers not via CDN?
• sensor graphing
• sensor data csv export
• update list of modules in farmOS
• farmOS on raspberry pi
• rename "area generator" to "bed generator"

I think there are also a few things from beta18 that haven't been added yet, as well:

• Bulk area geometry importer
• add log in bulk to assets

See comment: farmOS/farmOS#58 (comment)

After 7.x-1.0-beta13 was released, all the demo screencasts became out-dated. Major differences include:

• Simplex Bootstrap theme
• Field groups
• Movement logs are gone

I updated the documentation around movements, and removed the movement screencast (because it was no longer accurate).

I will recreate and readd the movement screencast along with updating all the other screencasts.

I started playing around with this during It's My farmOS! and figured I'd leave some notes here on my findings and the steps I think we need to take going forward.

One thing that occurred to me was that I want to be careful how I duplicate and/or move files around so that git is able to track the files' history. When I scaffolded the Gatsby project, I put it into its own separate directory, gatsby/, but would eventually like to move everything in there up to the level of root. My first inclination was to copy all the markdown files into gatsby/content/ but I realized if I git added these w/o git rming the original files in the same commit, git would not be tracking these as renamed files, but as totally new files, which would not retain the original file history. So I think I either need to mv all the file right off the bat, or perhaps create some test markdown files and paths while I work on layout and configuration, then mv the files when everything is all said and done, and I'm ready to move it all up to root.

I am using the gatsby-starter-blog template, and one issue that came up immediately was that it did not preserve the full relative path for individual pages; eg, instead of getting the url http://localhost:8000/guide/quick for the file gatsby/content/guide/quick.md, we're getting http://localhost:8000/quick. The solution I found for this was to modify the gastby-source-filesystem plugin in gatsby-config.js as such:

    {
      resolve: `gatsby-source-filesystem`,
      options: {
        path: `${__dirname}/content`,
        name: `site`,
      },
    },

I actually reverted this change, because I wanted to give more thought to the git history as mentioned above, but it should be easy to reproduce.

Another consideration is that with Gatsby we have the opportunity to provide separate layouts for the User Guide vs the Community pages vs etc. I think we may want to start conservatively here, but it would be nice to think about how their needs may differ and how we can handle that in the layout. I think for starters we will want to configure the gatsby-source-filesystem plugin to separate the content into layout types (another reason to hold off configuring that right away). We'll also need to modify gastby-node.js to use separate layout components when createPages is called.

I think the first step should be to prototype some layouts in Figma, so we have a better idea what those different layout types should be.

Sidenote regarding layouts: found a helpful plugin, gatsby-remark-table-of-contents, which can help us reproduce the table of contents like we currently are in the left margin of each page.

Also, do we want to close #32?

Pre install, how can I configure the base url so that I can correctly run FarmOS behind a reverse proxy. My only option at the moment is to use IIS as the reverse proxy but some resources are being blocked because they're not served over the secure endpoint.

Thanks

I've been talking with @kadaan in IRC about the need for a more official "farmOS Contribution Guidelines" document, outlining some of the standard practices we employ in farmOS development.

I am starting to sketch up a list of things I think should be included. I will post here soon...

Question or Suggestion

Following on the monthly call (13/3/29).

We spoke about finding ways to encourage or open community participation in the continued development of FarmOS. One of the suggestions was to have places to point people for contributing and learning. In my time learning R I used a number of different books written in RMarkdown using Bookdown to help me manipulate my own coding. I think that there is a lot of content on the current website that would fit nicely into a #bookdown format. I have attached links to a few examples if you are not familiar with the format.

https://happygitwithr.com/
https://bookdown.org/yihui/bookdown/
https://bookdown.org/yihui/rmarkdown/
https://bookdown.org/

PS, I can't find the tags function or know the markdown to make it pretty

Corran Farm (St.Austell, Cornwall, United Kingdom)

There's some crappy documentation on farmos.org/doc currently - copy it into this repo.

@jgaehring and I are talking about setting up a more formal API documentation section in farmOS.org, which outlines the available features of the API, and gives examples using the API libraries we are developing in different languages (as well as straight curl commands):

• https://github.com/farmOS/farmOS.js
• https://github.com/farmOS/farmOS.py
• https://github.com/farmOS/farmOS.php

Hi :)

as noted yesterday in the forum i can't upload any logs with the Fieldkit App. The PWA App (farmos.app) works as normal.

Steps to reproduce:

1. Login into the App (successful)
2. (create an log)
3. press the upload button
4. Login screen appears again. No error message.

Used Software and Hardware:

• farmOS (farm-7.x-1.4) (behind an NGINX Proxy)
• newest Android App version on different Honor and Huawei devices in different Networks

Tried Steps to solve the issue:

• clear Android App cache
• Reinstall Android App
• different phones & different networks
• setting up a new FarmOS environment (but also behind the same proxy) (waiting for the access to a farmier version at the moment)

Is there a possibility to access any logs on the Android Device?

• Home
• User Guide
  • Mapping your farm
  • Entering assets
  • Keeping records
  • Movements and locations
• Hosting
  • Installing
  • Upgrading
• Development
  • Projects
  • Architecture
  • Entity types
  • Contributing
    • Issue queues
    • Features development
      • Avoiding divergence
    • Submitting patches

There's an issue and pull request in the farmOS repo to add a Dockerfile:

farmOS/farmOS#6
farmOS/farmOS#8

We should add documentation to farmOS.org for people interested in using Docker for local farmOS development/hosting.

There are a few tips that we can document for making the development process easier. I'll use this issue's comments to list the ones I use as I think of them.

(Note a lot of these assume you're using the Docker environment described here: https://farmos.org/development/docker/)

When the next version of farmOS is released, we will start creating "latest" tags in Docker Hub that build the latest stable tagged release of farmOS. Currently, the Docker image builds the 7.x-1.x dev branch.

We need to document on farmOS.org how to move from the dev branch to the tagged release.

We may also want to consider moving/splitting the Docker documentation so that it includes details for both development setups (7.x-1.x dev branch) and well as stable local hosting (tagged releases). It might make sense for the Docker page to exist under http://farmos.org/hosting instead of http://farmos.org/development

Add a documentation page that outlines what the standard procedure is for rolling out a new release of farmOS.

Here is the procedure that I currently go through:

Final release preparations

• Make sure Drupal core version is up-to-date (e.g. farmOS/farmOS@d682318)
  • Evaluate whether or not any core patches are still necessary, and remove them if not (e.g. farmOS/farmOS@028dc18)
• Make sure all contrib modules are up-to-date (e.g. farmOS/farmOS@d831fef)
  • If any updated contrib modules are patched in farmOS, evaluate whether or not the patch is still necessary (e.g. farmOS/farmOS@7d2e30a)
• Ensure that the 7.x-1.x Docker Hub image is building successfully: https://hub.docker.com/r/farmos/farmos/builds
• Test all update hooks
• Test fresh Drush make build and installation

Release procedure

• Create a "Prepare for release of farmOS [version tag]." commit that updates the farmOS release tag references: (e.g. farmOS/farmOS@babc708)
  • projects[farm][version] in build-farm.make
  • FARMOS_VERSION in Dockerfile
  • The www container's image in docker-compose.yml
• Create a release commit "farmOS [version tag]." (with period) (e.g. farmOS/farmOS@7d1108c)
  • Swap commented www container image in docker-compose.yml
  • Swap comments in build-farm.make to use the version release, instead of the Git repository and 7.x-1.x branch.
• Tag the release commit in Git.
• Create a git revert HEAD commit that reverts the release commit (which switches the commented lines).
• Push the tag and revert commits to drupal.org and GitHub.
• Create a release node in drupal.org (e.g. https://www.drupal.org/project/farm/releases/7.x-1.0) with release notes that include:
  • farmOS updates - Brief descriptions in HTML list form (copying commit messages is a good way to do this, but very minor changes can be excluded).
  • Drupal core updates (with link(s) to core release notes)
  • Contrib updates (with link(s) to project release notes)
• Wait for the packaged release to be built...
• Update the latest tag on Dockerhub and trigger a rebuild (https://hub.docker.com/r/farmos/farmos).
  • When build is complete, test launching a new instance in Docker.
    • git clone https://github.com/farmOS/farmOS.git farmOS_7.x-1.0-beta14
    • cd farmOS_7.x-1.0-beta14
    • git checkout 7.x-1.0-beta14
    • sudo docker-compose up
• Close the roadmap for this release (move any outstanding issues to the next roadmap)
• Update project page: https://drupal.org/project/farm
• Edit Github release tag (ie: https://github.com/farmOS/farmOS/releases/tag/7.x-1.0-beta16)
  • Add a link to the drupal.org release node
  • Upload the packaged tar.gz file generated by drupal.org
• Announce
  • Twitter @farmOSorg (ie: https://twitter.com/farmOSorg/status/1118981883101052929)
  • OpenCollective (ie: https://opencollective.com/farmos/updates/farmos-1-1-has-been-released)

FYI: The reason for creating a release commit, and then reverting the release commit, is so that the dev branch (e.g. 7.x-1.x) checks out a working copy of the farmOS Git repository, while the tagged releases use the official packaged versions. If you were to use drush make to build farmOS on a commit that is not a release commit, you would get the latest development code - not the latest packaged (stable) release that is included in the tagged distro release. It requires some extra steps during the release procedure, but I think it's worth it for ensuring that up-to-date development environments can be built with drush make.

GEOS is required for the Area Generator module that comes with Farm Area.

Document where and why it is required, and where to find information about installing it.

This came up in the d.o issue queue: https://www.drupal.org/node/2736221

https://github.com/farmOS/farmOS-client

https://github.com/farmOS/farmOS-native

The docs on https://farmOS.org are all for farmOS 1.x currently, while the 2.x docs are being created on https://docs.farmOS.org. As we get closer to the first beta release of farmOS 2.0, this is going to cause more confusion (eg: https://github.com/farmOS/farmOS.org/pull/114). We've been discussing bigger ideas of a farmOS.org redesign, but it might be worth taking a very simple first step by putting a banner up on the current site that makes it clear that the docs are for farmOS 1.x, and that farmOS 2.x is coming soon - with a link to https://docs.farmOS.org.

I am currently doing an overhaul of the dependencies in the native and client repos (see farmOS/field-kit#7 (comment)). This is likely to introduce some significant changes to the architecture, but should also represent a stable point in the architecture. All that makes it seem like pretty good time to hammer out some more substantial documentation on the topic, while it's all right in front of me and fresh in my brain.

I'd like to start building a library of "example use-cases" for farmOS on farmOS.org. This could include things that new users may not think of - but would be very useful to them.

Some folks are finding the built-in Drupal module updater in their farmOS sites when they are hosting themselves. This updater can cause issues, because sometimes the modules that farmOS uses require patches. Also, it does not pull in updates to the farmOS distribution itself, which means that the module updates may conflict with the farmOS code.

farmOS users should ALWAYS download the packaged release of farmOS from http://drupal.org/project/farm (or use the Docker image, which does that itself).

The packaged version of farmOS will always have the correct versions of modules, and any patches that are required for them.

We are compiling a list of farms using farmOS, to be included on farmOS.org: http://farmos.org/community/farms/

If you would like your farm listed, please add a comment to this issue! Use the following format:

[farm name] ([city], [state], [country])

Example:

Stone Grown Farm (Mansfield, CT, United States)

Chrome recently made a change requiring that any sites utilizing the Geolocation API must be served over HTTPS. This means that the Geolocation button used in farmOS (provided by this module: https://www.drupal.org/project/openlayers_geolocate_button) does not work when you have farmOS running without an SSL certificate (non-HTTPS).

The Geolocate Button is primarily a convenience, and is not necessary to use farmOS's core features, so this isn't a critical issue, but it is an annoyance - especially because there's no obvious explanation presented to the user (unless they open Console).

We should add some information to the documentation of farmOS.org outlining this so that people who are installing farmOS themselves are aware.

Refer to the following issues:

farmOS/farmOS#9
openlayers/openlayers#5700

We need to update the Docker Mac instructions per @kadaan in farmOS/farmOS#25 (comment):

@mstenta BTW, looks like dlite is dead, but I'm able to get decent performance using your normal instructions if I suffix all the volumes with :delegated. See tuning-with-consistent-cached-and-delegated-configurations

farmOS provides a lot of flexibility in record keeping. It leaves it up to you to decide which log types to use for each type of activity you are performing.

For example: when you give an animal some medicine, do you use an Input log or a Medical log? What is the difference between an Activity and a Seeding? Some of these are easy to answer, and some are hard.

Ultimately it depends on what you will be using the logs for later. If one of the primary goals is to provide records to a certifying agency (Organic Cert, FDA, etc) then organizing them with that audience in mind makes the most sense, so perhaps that can be the starting point for defining some standard practices of record keeping in farmOS.

Quantity measurements are undergoing an architectural change, which will make them easier to work with over the REST API. See: https://www.drupal.org/project/farm/issues/2991378

When that is done, we should document how to work with quantity measurements over the API. The link above contains some good information.

Hi
Current Hangout timing of 1pm EDT equates to 5am in New Zealand. I'd love to be part of the call but find 5am a bit outside my comfort zone.

Propose we change the time to 2pm EDT starting with the August hangout.

Anyone have an problem with this. If so, please propose another time
Thanks
Rory