ucdavis/sitefarm_seed

SiteFarm Drupal base install profile.

SiteFarm Seed

SiteFarm Seed is a base profile for Drupal 8 meant for extending by a custom built sub-profile.

It provides sensible defaults and features that most websites will need.

Documentation

Documentation is found in the /docs or at github https://github.com/ucdavis/SiteFarm_seed/tree/8.x-1.x/docs.

Test Coverage

SiteFarm Seed has complete test coverage with both PhpUnit and Behat.

Features

FYI, the following links show fully themed components. SiteFarm Seed does not include any theming so that you can implement theming however you need something to look.

1. Sensible Defaults: We did the tedious work that most websites need so you don't have to
2. Content Types: Basic Page, Article, Event, Person, & Photo Gallery
3. Block Types: Basic Block, Focal Link, Focus Box, Hero Banner, Marketing Highlight, & Marketing Highlight - Horizontal
4. User Roles and Permissions: Contributor, Editor, Site Manager, Site Builder, & Administrator
5. Image Styles: Pre-built images styles are ready to be overridden to match a custom theme
6. Views: Dozens of Views create blocks and pages ready for content
7. Polished: Lots of Drupal 8's rough edges have been smoothed out for regular day-to-day users

Example Sub-Profile template

An example template for using SiteFarm Seed with a sub-profile can be found on github. https://github.com/ucdavis/SiteFarm-distro-template

Composer is a requirement.

sitefarm_seed's Issues

In what ways can a sub profile overwrite configuration coming from a Base profile?

Should field Data and Display (view modes) be individual modules?

Is it possible for subprofiles to delete or remove fields from a content type?

Remove all Block config files since we will not have any block instances in the base

Do Blocks need to be in their own individual module?

An example of a use case is the Sub Menu block and Social Icons block on the Basic Page. Many sites may not want these.

Rather than modifying fields on an existing content type, is it a better idea to simply override the entire module that provides the content type?

The only requirement then would be that the content type machine name is named the same as the base machine name

Create Functional tests for the Block Style Plugins module

Should Views be added in individual modules?

Create a configuration setting for Custom Block Types to autogenerate an instance title

Currently Custom Block Types will autogenerate an instance title, but this may not be desireable in a subtheme. A boolean config option would be nice so that a subtheme can turn it off if not desired. Currently it is hardcoded in each modules .module file.

Perhaps this could be a setting available under the Configuration > Sitefarm settings.

Can subprofiles define their own single-signon system?

UCLA and UCSF want to use Shibboleth.

Remove the "Branding" vocabulary and field reference on the Basic Page

Via #33, this is not something everyone will want. Subprofiles can add it back in if needed.

Can a subprofile add custom migrations for their own sources?

build out testing distro

Can a subprofile define a content moderation workflow?

And what happens if/when the base profile defines content moderation workflows? Are there conflicts?

Should the Branding Taxonomy be removed from Seed?

The branding taxonomy works well for UC Davis because we have lots of branding colors to choose from. I this something other campuses would want? Perhaps we should remove it from the base profile.

Should we change the composer module versions to use a ^ prefix so that only a minimum module version is required?

Would #5 cause problems with update hooks?

For example, if the update hook in the base profile is reverting a field that doesn’t exist in the sub-profile’s overridden content type, will this blow things up?

Can a subprofile disable or declare a module as not a dependency?

Article Views need to be refactored so they are not hardcoded to a specific term

Currently the following views are hardcoded to specific term ids.

views.view.sf_articles_category_filter.yml
views.view.sf_articles_latest_blog.yml
views.view.sf_articles_latest_news.yml

These assume two "Article Type" terms called "News" and "Blog". The reason for doing this originally is so that all news articles could be displayed on their own unique pages /news and /blog. Then when filtering by an "Article Category" the result would still be contextual to the Article Type.

For example, a news article with an "Article Category" term called "Environment" (tid=19) and a title called "Test Article" would have a content type alias of /news/test-article. It would appear with other news articles on the /news page. Then if on that page it was filtered to only show "Environment" news articles it would go to /news/19 where that article would still appear.

In doing this, every new "Article Type" term would require it's own unique views for the page and filter block.

This should be refactored to be simpler. If a subprofile wants this kind of workflow then it can make it within the subprofile. I would recommend instead to have a single generic Articles page with a filter block view for filtering all articles on the page.

Consider moving the Vue.js dependency in the RSS Feed Block to sitefarm_core so that it can better be overridden by a theme

Because the RSS Feed Block requires vue.js, there is the possibility that at some point there could be multiple instances of the library. It would be better to have one central point where the library is defined.

Write Unit tests for classes provided by the Base profile

Can a subprofile add new content types?

Via Features and have them enabled by default.

Remove all UC Davis specific Behat tests

Evaluate whether js/css in sitefarm_core should be abstracted out

Are update hooks a problem when the subprofile overrides configuration files?

Should the "Sitefarm Custom Social Links" module be removed from the base profile?

This module provides a new set of icons for the "Social Media Links" module. Is this something wanted by everyone? I don't think it hurts being there, but it was designed with the UCDavis theme in mind.

Can a subprofile add more modules?

Can field displays on forms be overridable?

For example, what happens if one university wants to drop a bunch of fields into a field group and make it collapsible?

Can subprofiles create their own Block Types?

Replace the custom Block Style Plugins module with the Drupal contrib version

Remove unneeded parts of sitefarm_core.module from Seed

Can an image style be changed on an existing View Mode?

How does the Config Actions module work with update hooks?

Create Event Subscribers for the sitefarm_simple_configuration module

Subprofiles should be able to lock down custom config pages or to allow custom config pages.

Add a menu item for the Simple Configuration module's Restrict Configuration Pages Form

A menu item needs to be set up for /admin/config/sitefarm/restrict-configuration.

Create a documentation video on using the Block Style Plugins module

This module is critical to themes, and it needs to be very clear how to use it.

Remove modules that are UC Davis specific or unneeded by everyone such as the Trumba module

admin_toolbar
cas
externalauth
fancy_file_delete
geolocation
inline_entity_form
migrate_plus
migrate_source_csv
migrate_tools
scheduled_updates
trumba

Can a subprofile add their own roles and override permissions or existing roles?

Create a base Image Style module

This will only be for default image styles. It is assumed that a theme will override the image styles with their own dimensions and config. Config Actions will likely be the solution for implementing this.

Article's require an "Article Type" taxonomy term. Should it be set in base or sub profile?

In order to submit an Article, the Article Type must be set. Normally this would have taxonomy terms preset to "News" and "Blog". Should this default content be set in the base Seed profile, or should it be a requirement that all sub profiles need to implement default taxonomy terms for the Article Type vocabulary?

Remove legacy Update Hooks in all modules

Refactor Behat tests to work with the Bartik theme

Clean up legacy files such as .install files that are empty after removing update hooks

Refactor the lock_sitefarm_features module to allow subprofiles to extend what parts should be locked

Subprofiles will need the ability to lock down their own content types and features that they build out. So they will need a way to declare what should be locked down.

Currently, some features are locked down by prefix 'sf_'. They should have a way to add a new prefix such as 'ucsf_'. Everything else is hard coded in the class. Theses should be broken out into configuration or perhaps better would be to make everything use a 'sf_' prefix rather than needing to remember adding each new item that should be locked down.

Perhaps an event subscriber would work to inject new items that should be locked down.

Can a new View Mode be added to an existing content type?

Should the Marketing Highlight custom block type and the Marketing Highlight Horizontal be merged?

The Marketing Highlight Horizontal is a stripped down version of the Marketing Highlight. Both are contained in the "sitefarm_marketing_highlight" module.

Marketing Highlight fields
Title
Link
Image
Description (text)
Call to Action (text)
Badge Label (text)

Marketing Highlight - Horizontal fields
Title
Link
Image

The horizontal part of this can be easily defined by a view mode with an image style. The reason we created 2 different block types was so that users wouldn't be confused about which one they were getting since the vertical one had more possible fields.

I'm inclined to remove the Badge Label either way. I'm not sure how needed that it. It's also caused a lot of problems for us since only so much text can fit in the space. That space however is a theme specific restriction.

Write Unit tests for sitefarm_core services

Is there a way for a sub profile to exlude a configuration file?

For example, if a subprofile does not want to use the "Listing" view mode, is there a way for it to ignore the base profiles config that adds it in?

Can a subprofile define and install a Search system like Solr?

Is it possible for a subprofile to add new fields to a content type?