[META] Map out Drupal 8 / farmOS 8.x-2.x Dependencies

Field Collection can be removed if we go through with this: #2361831: Remove dependency on Field Collection

Update: For now I decided to keep Field Collection.

Less critical to the FarmOS project in general, but very important to me with Farmier... Aegir does not yet support installing/managing Drupal 8 sites. Related issue: #1194602: [meta] Support the hosting of Drupal 8 sites

Added: Libraries, GeoPHP, Proj4JS

Remove modules that are no longer dependencies: Proj4JS, Commerce, Commerce Pickup, Text List Formatter

Made an exhaustive list of all the contrib modules, farm modules, and themes used by farmOS. I will add more information to each...

Added info and links to each project outlining its D8 status.

I created an initial commit on a new 8.x-2.x branch. It is basically just a clean slate for us to build upon. No contrib or farm modules/themes are included yet.

http://cgit.drupalcode.org/farm/commit/?id=fdacd8e

Added EXIF Orientation module (#2575639: Use the EXIF Orientation module to automatically rotate images.).

Role Export has been removed from farmOS.

@cosmicdreams: thanks for the reorganization! Makes good sense, and it's easier to plan.

Re: Logintoboggan and other modules - yea we can definitely consider dropping some of the lesser dependencies. Logintoboggan is a good candidate. The primary uses for it are: a) ability to log in via email address, b) display login form on "Access Denied" pages. Neither of which are strictly necessary for farmOS, so I could be convinced to drop them. Maybe there are new ways of achieving the same things in D8 too...

Other contrib modules that could potentially be axed are:

Backup & Migrate - Definitely nice to have, but it's not the only way to backup, so maybe we should leave that decision to the end-users.
Colorbox - This is how we're handling the display of images in farmOS, so we would need a replacement.
Devel - Not enabled by default, only included for convenience.
Diff - Same as devel, not strictly necessary, but makes development and working with Features easier. But maybe we won't use Features in D8 anyway because everything can be done in YAML files.
Filefield Paths - Nice for file organization, but maybe the same can be done with core Field properties. Need to explore in more detail.
Panels - The only thing we're using Panels for right now is the Farm Dashboard (in the farm_admin) module. We certainly don't need to use Panels for that, and it could be converted to a simple theme function or something instead.

I think you're right: we should document what ALL the dependencies are used for. Ideally this would be in some form of documentation, not just the issue queues... although we could start here.

Continuing the last comment, here's an outline of each dependency's usage in farmOS: (not including the ones I just mentioned - these ones are more critical in my opinion)

• Entity Reference View Widget - This is essentially a widget for Entity Reference fields that displays a View of entities you can select from. This makes it a whole lot easier to reference multiple entities when you're creating a Log. We are using this for the field_farm_asset entity reference field on various Logs.
• EXIF Orientation - This automatically rotates photos that are uploaded form a phone, so the right side is up. Maybe not critical - but pretty dang annoying without it.
• Features - Most of farmOS is built as Features modules. In D8 - I would love to see a lot of that move to the new CMI (config management) system. I still have to familiarize myself with what that will look like, exactly, and if/how Features might still be needed. At the very least the ability to see a diff (with the Diff module) of what has changed in a Feature is extremely useful for development.
• Field Collection - This is being used to create the "Quantity" field (which contains both a "value" and a "unit"). Eventually, I may turn the concept of "Quantity" into something new entirely, though - so the Field Collection module may go away. Not 100% sure yet.
• Fraction - This is how all decimal field values are being stored. Already has a D8 release.
• Geocoder - Allows KML files to be geocoded into Geofields.
• Geofield - Stores geodata. Openlayers sits on top of this to display the geodata in map form.
• GeoPHP - Dependency of Geofield.
• Libraries - Dependency of various other modules that use external JS libraries.
• Libraries CDN - Openlayers uses this to load the Openlayers Javascript library over CDN, rather than requiring that it's stored locally.
• Log - Provides the "log" entity type, used for all logs in farmOS.
• Openlayers - All the maps.
• Openlayers Geolocate Button - Provides a nifty little button to automatically zoom you in to your current location within Openlayers.
• Pathauto - Gives assets, logs, and taxonomy terms a nice path like "farm/planting/2015-corn" instead of "farm/asset/125"
• Role Delegation - The "Farm Manager" role has permission to delegate Farm roles to other users.
• Token - Used for auto-generating log titles. And it might be a dependency of some other things too.
• Views Data Export - Currently only used in the Farm Soil Test module for exporting soil tests to CSV, but the hope is that eventually we will build similar CSV exports for other entities as well.
• Views GeoJSON - Used along with Openlayers to generate maps of areas (which have Geofields).
• Views Tree - Used in Views of taxonomy terms to show them in a hierarchy, like Crops, Animal Types, Animal Groups, etc.

Just noticed that Pathauto Entity was in the Deprecated group, which is a mistake. Moved it up to the Contrib Modules group.

Pathauto Entity gives us the ability to auto-generate paths on non-standard entity types, like Farm Assets.

Added a link to https://www.drupal.org/project/entity_browser as a possible replacement for Entity Reference View Widget.

I'm going to remove the Panels/Page Manager dependency in Farm Admin to ease the D8 upgrade process. See #2651442: Remove dependency on Panels

I'm also going to remove Backup & Migrate and Devel from the distribution. Folks can add these manually if they need them. See #2651444: Remove Backup & Migrate and Devel

Done: #2651444: Remove Backup & Migrate and Devel

I am also going to propose removing Views Data Export: #2651452: Remove dependency on Views Data Export

It is only used in the Farm Soil Test module currently. Ultimately we want to be able to export all kinds of entities, so I propose we temporarily remove it from Farm Soil Test, get onto Drupal 8, and then reassess our options.

Done: #2651452: Remove dependency on Views Data Export

I'm going to remove Filefield Paths: #2655588: Remove dependency on filefield_paths

This is done: #2655588: Remove dependency on filefield_paths

Filefield Paths will be automatically uninstalled in the next release, and removed entirely in the following.

This is also done now: #2651442: Remove dependency on Panels

I also removed LoginToboggan. It doesn't make sense for farmOS to include that by default. It can be installed in sites/all/modules if anyone wants it.

I added the Markdown module to farmOS. See #2643882: Add Markdown support

There is already a release of Markdown for Drupal 8.

@Wim: Thanks for the input!

So, we're not really "switching" to markdown - just adding it as an option to the "Farm Format" text format. Currently farmOS doesn't use any WYSIWYG, because the only longtext fields it uses are for simple notes and descriptions, and thusfar those didn't need the full capabilities of a WYSIWYG. Markdown gives us some simple flexibility (ie: easy bulleted lists), with minimal effort.

I added Markdown because:

1. I use Markdown myself a lot, and really like its simplicity (all farmOS documentation is written in markdown and compiled into the pages here: http://docs.farmos.org).
2. It gives farmOS a quick-and-easy way to handle simple things like bullet-lists, which I often need to put into the Notes field of my farm logs.
3. Markdown can exist side-by-side with CKeditor (as far as I know). And there is already a D8 release of it, so adding it does not slow down our upgrade path.

When we do move to D8, I'm excited to leverage the built-in CKeditor! So as soon as we get all the farmOS module ported, we can decide if that would be helpful. :-)

@Wim: Ah ok - I assumed they could be used in the same Text Format - but I've never tried it. I will have to familiarize myself with the way D8 + CKeditor is working. Thanks for the heads up!

Ah yea that all makes sense. Hmm - always more complicated than you think. :-)

Well, I don't see Markdown as a requirement by any means - so if it is going to introduce complexities for future CKeditor integration then it's not worth it. And as you said: it probably wouldn't be used by most of the farmOS target audience. If anyone really wants it, they can always create a separate Text Formatter for it, and make that the default on their site.

Thanks for the points Wim - I think I'll revert the Markdown addition - keep things simple now as we prepare to upgrade to D8.

#2658234: Remove Markdown support

Taxonomy still depends on Node, so we might not be able to disable Node entirely in 8.x. :-(

However, there is an effort underway for 8.2.x: #2339235: Remove taxonomy hard dependency on node module

Convert to new Drush Make YAML format: http://www.drush.org/en/master/make/

Initial commits of the 8.x-2.x branch are up on Github and drupal.org. Starting very simple and building up a piece at a time...

I also started a new set of documentation to go along with the 8.x-2.x branch development, included in the repository in the "docs" directory. It is written in Markdown, and automatically converted to HTML with Mkdocs (http://mkdocs.org), hosted on Github pages: http://8x-2x.farmos.org - I intend to make this the canonical documentation once 8.x-2.x is stable and becomes the recommended branch.

More thoughts to come soon...

I am planning on merging most of the separate farm_* modules into the main farmOS repository (see #2784927: Should farmOS repositories be merged?).

I created a separate issue for each of the modules, and added links to the issue description above. We can use those issues to dissect each module and figure out what needs to be done in 8.x-2.x. It will also be an opportunity to rethink/reorganize some things.

I decided to revert #2651452: Remove dependency on Views Data Export so that we could do #2663998: Data export in the 7.x-1.x branch. It's a very commonly requested feature.

Added Views Data Export back to the list of modules in this issue's description. When the time comes, we should explore what alternatives exist in D8. Perhaps https://www.drupal.org/project/csv_serialization

Some notes...

There is some discussion around deprecating Field Collection in Drupal 8 in favor of Paragraphs: #2784931: Proposal: Deprecate Field Collections for Drupal 8, focus on Entity Reference Revisions & Paragraphs

I will have to review that in more detail to see if Paragraphs can be used to accomplish what we are using Field Collection for currently (and/or if changing the way we are structuring things might make sense).

On a related note, look into Entity Reference Revisions instead of normal Entity Reference fields? https://www.drupal.org/project/entity_reference_revisions

Re: field_collection vs paragraphs... we may actually be better off just writing our own field types for the few things we need compound fields for. Paragraphs seems too focused on content editing, broadly speaking. We are really just using field_collection to create reusable compound fields.

Currently we are using field_collection for the following things:

* Quantity - reusable compound field that is added to most log types, which contains a "value" field (fraction) and a "units" field (taxonomy reference).
* Animal tag - compound field used on Animal assets with a tag id (textfield), type (select list), and location (textfield). Users can add multiple animal tags, which is why this is a field_collection and not simply individual fields on the animal record.

I am also considering adding a new field_collection for movements (so that they can be used on all log types). This would have a "from" field (taxonomy reference), a "to" field (taxonomy reference), and a "geometry" field (geofield). This compound field would be reused on most log types.

Since the use-cases for those are so specific, and we don't need the ability to add/modify the sub-fields via UI, maybe it makes more sense to just create some custom field types in code, rather than packaging them as config from field_collection/paragraphs.

Hmm, although... here's the tricky part... how do I create a new field type that inherits from BOTH taxonomy reference fields AND geofield fields? Is something like that even possible?

I am looking into adding multiupload widgets for file and image fields in farmOS 7.x-1.x: #2879556: Multiupload file and image fields

I will add these two modules to this issue description, although their functionality is included in Drupal 8 core, so upgrading won't be an issue.

Per #2879934: Improve editing UI/UX with Field Groups I am adding the Field Group module to farmOS. Updating this issue accordingly... notably Field Group is in its 6th release candidate for Drupal 8, so we should be covered.

The Feeds and Job Scheduler modules have been added to farmOS 7.x-1.x for #2892181: CSV importers for assets and logs. Updating the dependencies on this issue accordingly...

The Feeds module is currently in development for Drupal 8 (see #1960800: [meta] Feeds 8.x roadmap). It may be worth looking into using Drupal core's Migrate API instead. This will require more investigation...

Also Feeds Tamper (see previous comment).

We added the restws_file module to farmOS (see #2992637: Add support for file uploads via REST API).

From what I understand, this functionality is already covered in Drupal 8 core, so I don't think it will affect our upgrade plans at all. Although the API details may change a bit (but that was probably anyways).

I've removed Libraries CDN. See https://www.drupal.org/project/farm/issues/3009628#comment-12837494

Removed role_delegation: #3033701: Do not grant "administer users" permission

See this relevant issue regarding Drupal-specific namespaces inside farmOS: #2991398: Remove Drupal namespacing from REST API

And this comment in particular:

I am leaning towards just removing all "farm_" (and "farm_field_") namespaces in the 8.x-2.x branch of farmOS - so that we don't need to do any of this stuff, and we use the same names internally. This would be somewhat improper from a traditional Drupal namespacing perspective, but I think it is warranted for farmOS moving forward.

I created a new contrib module and added it to farmOS: https://www.drupal.org/project/restws_field_collection

This will not be needed in farmOS 8.x-2.x as long as we move away from using Field Collections and instead just create some custom compound field types.

@diosbelmezquia - the Drupal 8 version of farmOS has only barely gotten started. All active development is still happening the 7.x branch. I am eager to begin the Drupal 8 upgrade, but there is no timeframe for it yet. So if you are interested in using farmOS, the 7.x branch is the only option.

Update: I am in the process of replacing the Drupal OpenLayers code in farmOS with the new farmOS-map JavaScript library. See #3083352: Migrate to farmOS-map library

This will allow us to remove the following dependencies from farmOS:

Modules:

• OpenLayers
• Registry Autoload
• Service Container

Libraries:

• OpenLayers (the necessary elements of OL are included in farmOS-map.js)

When #3083352: Migrate to farmOS-map library is complete, I will update this issue's description accordingly.

This will be a huge step forward towards the farmOS 2.x branch, as the Drupal OpenLayers module's lack of an 8.x version is one of our biggest blockers.

Consider splitting the farm_mapknitter module out to a separate contrib module in the 8.x branches. It doesn't need to be included in farmOS core.

We can also remove openlayers_geolocate_button when #3083352: Migrate to farmOS-map library is merged.

Updated status of dependencies in issue description.

The upstream dependency landscape of farmOS is looking really good for 2.x!

Oops forgot to update Bootstrap theme. Stable release available for that too!

I opened a fresh new issue to use as the canonical roadmap for the overall farmOS 2.x initiative: #3092830: [META] farmOS 2.x Roadmap

Please subscribe to that issue if you are interested in updates.

I am renaming this issue to indicate that it was focused on mapping out dependencies - and I am closing it.

I also closed all the child issues I had created for individual modules, because they were no longer comprehensive, and it will make more sense to create new child issues based on functionality rather than module.

All further updates will be made in the new roadmap issue, as well as new child issues of that.

Onward!!! :-D