farmos-legacy / farmos.org Goto Github PK
View Code? Open in Web Editor NEWThis is the code that runs the official v1.farmOS.org website.
Home Page: http://v1.farmos.org
This is the code that runs the official v1.farmOS.org website.
Home Page: http://v1.farmos.org
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
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
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?
Add information about how to use the REST API endpoints provided by the Restful Web Services module.
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
Release procedure
projects[farm][version]
in build-farm.make
FARMOS_VERSION
in Dockerfile
www
container's image
in docker-compose.yml
www
container image
in docker-compose.yml
build-farm.make
to use the version
release, instead of the Git repository and 7.x-1.x
branch.git revert HEAD
commit that reverts the release commit (which switches the commented lines).latest
tag on Dockerhub and trigger a rebuild (https://hub.docker.com/r/farmos/farmos).
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
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
.
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/)
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
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.
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.
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?
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)
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:
Used Software and Hardware:
Tried Steps to solve the issue:
Is there a possibility to access any logs on the Android Device?
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).
There's some crappy documentation on farmos.org/doc currently - copy it into this repo.
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.
I think there are also a few things from beta18 that haven't been added yet, as well:
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.
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...
After 7.x-1.0-beta13 was released, all the demo screencasts became out-dated. Major differences include:
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.
See comment: farmOS/farmOS#58 (comment)
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.
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 add
ed these w/o git rm
ing 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?
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.
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.
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.
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
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
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.
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
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.
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:
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)
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
Is there any demand for an full windows guide? Then i could try to provide one
Corran Farm (St.Austell, Cornwall, United Kingdom)
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
Cross post: Document Google Maps API key requirements
Farm Soil
Farm Soil Test
Farm Soil NRCS
@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):
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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.