Add setup page to farmOS core


As a part of the work I am doing with @gbathree @AmberS and Mo I am exploring adding a new “Setup” page & menu to farmOS. This would directly support at least two of the projects we are building modules for: Products & inventory + Templates & Plans. Instead of making a third contrib module to house these Setup features I would like to propose adding these Setup features directly to farmOS core to also improve some existing issues.

Why a setup page?

Both of these modules are adding specific features & UI to farmOS but still require some initial configuration or “setup” before they can really be used. We think that keeping the “setup” UI separate from a streamlined “feature” UI simplifies the user experience. Maintaining all of these setup pages under a common location/menu creates consistency that we also hope can help to guide users when initially setting up a new farmOS instance and/or new modules.

As an example, the Products & inventory requires creating product types and product assets to represent the “inventory locations” before you can being tracking product inventory in the UI. In the initial MVP of the product module I tried to combine this “setup” page with the improved UI for managing inventory but after reviewing we think this is overly complex. The UI for setting up product types & assets does not need to be visible day-to-day when managing inventory, but only when initially adding or later changing the product types and assets the farm is using.

What about settings?

Currently farmOS has a Settings page that is accessible via a toolbar item in the top right corner. The settings page acts as a home for other modules to add their own pages for configuring things like the farm info, languages, system of measurement and API keys for third party services, as well performing actions like installing modules. Many of these settings are for things that do not change very often, if ever. As a result the settings page requires a special permission and is normally only accessible by users who are considered the “owner” or “administrator” of a farmOS instance.

The case for a Setup page is similar to Settings in that are not used very often. But otherwise I think they differ for two main reasons:

  • Setup pages would often be used for creating content instead of changing settings (although they could do that, too!)
  • Most setup pages should be accessible by normal (worker/manager) users, not only the owner or administrator of the farm.

Existing issues

First the “Administration” menu & pages…

farmOS core only uses this menu for 3 pages. We also grant the access administration pages permission to make this menu visible even though the permission is not needed for any of the 3 pages. I think all 3 could be moved to a “Setup” page and be more accessible. “Administration” just isn’t a great word to cover these use-cases in the farm context:

  • Drupal core taxonomy overview (see below)
  • Drupal core People page (maybe not necessary?)
  • The farmOS Import menu

Taxonomy terms…

I think we have a fairly common issue/pain point around creating and managing taxonomy terms right now. Which is important because almost all use-cases in farmOS require creating taxonomy terms! At minimum, most people setting up a farmOS instance will end up creating taxonomy terms for plants or animals. And once they do, it’s quite possible they won’t even know they did so! Of course there is the page for viewing terms but it is buried under “Administration->Structure->Taxonomy” and is not very intuitive to find. A lot of this experience would be improved by locating the Taxonomy menu item directly under a “Setup” page that is more inviting for users to navigate to.

Better taxonomy UI

There is another argument for improving the existing taxonomy pages. Perhaps the most requested is for plant_type and crop_family to have a dedicated UI to make it more clear how they should each be used, perhaps to create plant assets at the same time. And such a UI should likely be different from managing other taxonomy terms like log categories… however it ends up, these seem like other cases of “content setup” that could be located under a Setup page.

Better setup experience

Currently the Settings page is only available from the top toolbar. It is visible, but not as visible as items in the main menu. Instead, I think we could add a Setup toolbar & menu item, with settings as a sub-item.

Also when someone is new to farmOS I think it is especially important they see the Module form, and wonder if the Module form might be better off under the “Setup” page anyways?

Too many settings

I think it is also possible that we end up with “too many settings”. One example could be the Notifications page… in the future if many modules provide notifications this settings page gets pretty cluttered. It’s also not possible to have sub-sub tabs. But with notifications as a dedicated Setup page, modules could each have a primary tab & control their own sub tabs.

Also possible we end up with “too many setup” pages, too…


Proposed UI


A base install of farmOS might have a simple setup page. This includes moving Modules from Settings to Setup:


With other modules enabled there are more setup items. This includes Products + Templates and moving Notifications from Settings to Setup. Too many setup pages?


I love this idea @paul121 - and thanks for describing it in such nice detail with considerations and screenshots! I really really like how it looks/works in your mockup, and I think all the decisions you proposed make sense.

Drupal core People page (maybe not necessary?)

I think this should be hidden to everyone except user 1. If it isn’t already, then that may be a bug (or I’m forgetting some other reason why it’s visible).

Taxonomy terms…

Agreed about the pain points with the default Drupal UI. There are others I can think of too - like the fact that Drupal allows multiple parents for terms (which is never a good idea IMO), and splits longs lists of terms up over multiple pages, which conflicts with the ability to arrange them hierarchically, etc.

So maybe instead of MOVING the Drupal core taxonomy UI to the Setup menu, we should just provide our own, and fix all the issues in one fell swoop. This would require more work, though, so maybe we think through a phased approach to this and make a dedicated issue for it.

Apart from that it seems like a lot of the first steps for the “Setup” section you describe are pretty easy!

Nice work Paul! I like it!

1 Like

@mstenta asked on the pull request:

One thing I’m wondering: do we need a “Setup” toolbar item? Maybe we should just add it to the bottom of the main menu, move “Settings” into there, and remove the separate toolbar item completely. It is a bit of an odd-ball up there as it is - and it made sense when we just had “Settings” - but makes less sense to have a like to “Setup” in two places IMO.

I agree it isn’t necessary to have it in two places. But like the concept of having “quick access” to these pages even if only visually. But maybe that is silly!

Anyone here have an opinion? @AmberS @gbathree

1 Like

To be clear, by “in the toolbar” I mean having a “Setup” link in the top right of the page next to the user account dropdown menu. This would be in addition to being available on the left menu, which would also always be visible.

I think the key is making sure it’s as clear as possible. Comparing to other services, the setup tab is at the same level as the other major options provided to the user.

In my mind the left side bar is that place, but again depends on the UX concept


Agreed - my vote is to have the new “Setup” item in the main menu (on the left) that @paul121 added. And not duplicate it in the top right.

1 Like

Makes sense. Our original discussions on this referenced other services with Setup in the top toolbar, but indeed, our UI is different. Let’s drop it and see how it goes!

1 Like

A very minor part of what’s been brought up, but here is the (needs work) core issue to give sitebuilders the option to disable multiple parents for taxonomy terms ([#2081835] on

1 Like

Thanks for the link @mlncn - and welcome to the forum! This makes me wonder if we should take the opportunity to prevent multi-parent terms as a breaking changing in farmOS 3.x ( which will be coming soon. It’s an opportunity to make a decision like that, although it would require some more thinking (and probably a dedicated thread).