We are on the cusp of a new world: Drupal 8

With it will come many good things. But it will take time, and we need to wait for a lot of the dependency modules to be ported before we can really start thinking about FarmOS on D8.

This meta issue will be used to discuss and document the plans for Drupal 8, as well as link to relevant D8-porting issue for other projects.

Contrib Modules

Colorbox - WORKING DEV RELEASE
Diff - #2267033: [meta] Port to Drupal 8
Entity Reference View Widget - #2446505: Is there a plan for Drupal 8 port? (possible replacement: Entity Browser)
EXIF Orientation - #2573701: Drupal 8 Port
Features - WORKING ALPHA RELEASE (not needed due to CMI?)
Feeds - #1960800: Port Feeds to Drupal 8 (investigate core Migrate API as alternative)
Feeds Tamper - #2493059: Plan to port to D8? (only necessary if we use Feeds)
Field Collection - #1443960: Field Collection for Drupal 8
Field Group - #2578743: [field_group] Field Group
Fraction - DONE
Geocoder - #2146393: Drupal 8 Upgrade
Geofield - #1957760: Geofield D8 port
GeoPHP - #2362577: Drupal 8 status?
Job Scheduler - #2615256: Port "Job Scheduler" to Drupal 8 (this is only needed if we use Feeds, and Feeds still depends on it in D8)
Libraries - #1779714: Port to Drupal 8
Libraries CDN - #2575511: Drupal 8 port
Log - #2361713: [meta] Port Log to Drupal 8
Openlayers - #2361715: Port to Drupal 8
Openlayers Geolocate Button - #2575517: Drupal 8 Port
Pathauto - #2168193: Pathauto for Drupal 8
Pathauto Entity - #2496701: Drupal 8
Role Delegation - #2400813: Port to Drupal 8
Token - #1962358: Token Drupal 8 port
Views Data Export - #2421061: Porting module to Drupal 8
Views GeoJSON - #2527636: Port to Drupal 8
Views Tree - #2575521: Drupal 8 port of Views Tree

Deprecated (no longer needed in Drupal 8)

Ctools - IN D8 CORE (check to see if anything else we're doing needs it)
Date - IN D8 CORE (confirm that Views integration and Select widget are in core as well)
Entity - IN D8 CORE
Entity Reference - IN D8 CORE
jQuery Update - UNNECESSARY (confirm that the jQuery included in D8 core is all we need)
Module Filter - IN D8 CORE
Multiupload Filefield Widget - IN D8 CORE
Multiupload Imagefield Widget - IN D8 CORE
Navbar - IN D8 CORE
Registry Autoload - IN D8 CORE
Rest Web Services - IN D8 CORE (confirm that this works the same)
Service Container - IN D8 CORE
Strongarm - UNNECESSARY (CMI!)
Views - IN D8 CORE
Views Bulk Operations - IN D8 CORE? (need to confirm all necessary features are present. here is the VBO module's D8 initiative: #1823572: Port Views Bulk Operations to Drupal 8)

Farm Modules

Farm Access - #2851955: Merge farm_access into farmOS 8.x-2.x
Farm Admin - #2851940: Merge farm_admin into farmOS 8.x-2.x
Farm Area - #2851941: Port farm_area to Drupal 8
Farm Asset - #2851942: Port farm_asset Drupal 8
Farm Crop - #2851943: Port farm_crop to Drupal 8
Farm Equipment - #2851944: Port farm_equipment to Drupal 8
Farm Fields - #2851945: Port farm_fields to Drupal 8
Farm Livestock - #2851946: Drupal 8
Farm Log - #2851947: Port farm_log to Drupal 8
Farm Map - #2851948: Port farm_map to Drupal 8
Farm Map Norway - https://github.com/farmOS/farm_map_no/issues/1
Farm MapKnitter - #2851949: Port farm_mapknitter to Drupal 8
Farm Maple - #2851950: Drupal 8
Farm Mushroom - #2851951: Drupal 8
Farm Quantity - #2851956: Port farm_quantity to Drupal 8
Farm Sensor - #2851952: Port farm_sensor to Drupal 8
Farm Soil - #2851953: Port farm_soil to Drupal 8
Farm Taxonomy - #2851954: Port farm_taxonomy to Drupal 8

Themes

Bootstrap - WORKING DEV RELEASE(?)
Farm Theme - #2851938: Merge farm_theme into farmOS 8.x-2.x

Comments

m.stenta’s picture

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.

m.stenta’s picture

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

m.stenta’s picture

Issue summary: View changes

Added: Libraries, GeoPHP, Proj4JS

m.stenta’s picture

Issue summary: View changes

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

m.stenta’s picture

Issue summary: View changes

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

m.stenta’s picture

Issue summary: View changes

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

m.stenta’s picture

Title: [META] Drupal 8 » [META] Drupal 8 / farmOS 8.x-2.x

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

m.stenta’s picture

m.stenta’s picture

Issue summary: View changes
m.stenta’s picture

Issue summary: View changes
m.stenta’s picture

Issue summary: View changes

Role Export has been removed from farmOS.

m.stenta’s picture

Issue summary: View changes
m.stenta’s picture

Issue summary: View changes
cosmicdreams’s picture

Issue summary: View changes

Separated the modules that are deprecated thanks to the functionality provided by Drupal 8 core from the list of contributed modules that we need to wait for.

It would also be good to discuss why we need each of the contributed modules. For example: do we need Logintobaggan for a specific reason? Or just to have more control over the login page?

Also, given the Entity API's breath and depth in Drupal 8, I don't expect that a separate module for it will be required. Pathauto will likely consume it's functionality just by properly integrating with Drupal 8.

m.stenta’s picture

@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.

m.stenta’s picture

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.
m.stenta’s picture

Issue summary: View changes

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.

m.stenta’s picture

Issue summary: View changes

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

m.stenta’s picture

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

m.stenta’s picture

m.stenta’s picture

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.

m.stenta’s picture

m.stenta’s picture

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

cosmicdreams’s picture

I applaud the reduction. Fewer modules means the support work will be less.

m.stenta’s picture

Issue summary: View changes

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.

m.stenta’s picture

Issue summary: View changes
m.stenta’s picture

Issue summary: View changes

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.

m.stenta’s picture

Issue summary: View changes

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

There is already a release of Markdown for Drupal 8.

Wim Leers’s picture

The switch to Markdown is interesting, because Drupal 8 ships with a deeply integrated CKEditor by default. Out of curiosity: why choose Markdown instead? Especially considering the target audience.

m.stenta’s picture

@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 Leers’s picture

Cool, thanks for the perspective :)

Just one note: you can use Markdown and CKEditor side-by-side. If by that you mean use them for different data/fields. Given a certain formatted/rich text field, you can not just switch to and from Markdown. They'd be two different text formats.

m.stenta’s picture

@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!

Wim Leers’s picture

Using CKEditor implies using a text format that has few filters. E.g. you don't want automatic paragraph creation like filtered_html in D7 does when using CKEditor, because CKEditor already creates paragraphs.

On the other hand, when using Markdown, you also don't want automatic paragraph creation, because Markdown already provides that for you.

Finally, how could CKEditor render Markdown input? And if it could, would it then have to generate Markdown instead of HTML?

Those problems are just the tip of the iceberg when it comes to mixing Markdown + CKEditor, or even Markdown + "traditional Drupal text formats".

m.stenta’s picture

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.

m.stenta’s picture

m.stenta’s picture

Issue summary: View changes
Wim Leers’s picture

Having Markdown is fine, but it will indeed complicate things. So, if you want to KISS… then this seems like the better approach :)

howards’s picture

A note to ease the issues of creating so many features, Drupal 8 has a built-in ECK using the field_ui along with the Drupal Console functions. It allows quick creation of entities and bundles; perhaps something like a farm entity might work well for future functionality. I have been testing some stuff using the CMI and it seems to work well, but there are some issues with settings.php in how it manages the $config_directories[] configuration. I don't yet know how it will work with distributions. As far as I know, the configuration management initiative kind of uses a generated code during install to determine what configurations are for the same site versus a different site.

Just a heads-up and potentially a quicker path to a D8 release along with migrate functions to move data from D7. As well, some things to consider when it comes to the D8 CMI.

m.stenta’s picture

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

m.stenta’s picture

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

m.stenta’s picture

Version: 7.x-1.x-dev » 8.x-2.x-dev

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...

m.stenta’s picture

Issue summary: View changes

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.

m.stenta’s picture

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.

m.stenta’s picture

Issue summary: View changes

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

m.stenta’s picture

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

m.stenta’s picture

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?

m.stenta’s picture

Issue summary: View changes

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.

m.stenta’s picture

Issue summary: View changes

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.

m.stenta’s picture

Issue summary: View changes

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: Port Feeds to Drupal 8). It may be worth looking into using Drupal core's Migrate API instead. This will require more investigation...

m.stenta’s picture

Issue summary: View changes

Also Feeds Tamper (see previous comment).