Questions about D8 Lightning by Acquia

Events happening in the community are now at Drupal community events on www.drupal.org.
skyriter's picture

At the upcoming Omaha Drupal Meetup, @phenaproxima will be joining us to talk about the Acquia Lightning Drupal 8 distribution.

So that any would-be interested party has some input, I wanted to see if anyone had any questions they would like to have addressed.

What would you like to know about Lightning?

Comments

https://www.drupal.org/projec

kreynen's picture

https://www.drupal.org/project/openedu was rewritten for D8 as a Lightning subprofile. Not only has OpenEdu not applied critical security updates (hasn't been updated since April again), the core patch required for profile inheritance support was broken by other updates merged into 8.6.0. That patch has been updated for 7 years. While it has been supported by the maintainers of most popular distributions, I think everyone other than @phenaproxima has given up ever seeing that in core.

So the questions for @phenaproxima is there anything large organizations like the University of Colorado and University of California can do to get support for sub-profile/inheritance support in core? Does he think that will ever get merged? Is that considered something Acquia supports for organizations who want to use Lightning?

Thanks for the question

skyriter's picture

I'll pass that question along.

I'm not sure I understand what a sub-profile is and how it might be different from what we're doing at Creighton University, where we're building our own platform based on Lightning: https://github.com/cu-webteam/d8-platform

I wrote two entire paragraphs

phenaproxima's picture

I wrote two entire paragraphs to answer this question and then my Internet died while I was submitting it so...ask me again in the meetup! :)

EDIT: Eh, I might as well have another go. So here's the rub:

I actually have given up hope of seeing it land in core, at least in its current form. The Lightning team is no longer maintaining the patch beyond the "life support" level, which is to say we reroll it when it conflicts with changes in core, and nothing else.

As for why, well...I've discussed this extensively with Alex Pott, who knows the config system and the installer inside and out. Although he agrees with us all that the functionality is extremely useful for distributions and large organizations, he's absolutely right that the implementation has serious shortcomings. For one thing, it touches significant portions of the installer, which is easily the most brittle part of core and damn near impossible to maintain. On top of that, it adds "superpowers" (Alex's word) to an already ill-defined part of Drupal's API -- namely, install profiles themselves. At the API level, which is the level that core developers need to care about, their boundaries are not very clear and adding more functionality to them risks introducing a lot of dangerous technical debt into the already very fragile install system. Additionally, there are many unanswered questions surrounding the way it interacts with how the config system is designed to work in Drupal 8. This is a part of the problem that I don't understand half as well as Alex does (and isn't helped by the fact that I'm not building sites as my day-to-day job anymore), but the config system is already getting an overhaul (the CMI 2.0 Initiative) and the subprofile patch as it exists might conflict with that in totally unforeseen ways.

Basically, the profile/installation system is in such a crappy state right now (it is incrementally improving, but very slowly, because so few people understand it), and the subprofile patch adds too many unknowns into that jungle, for it to be committed to core.

That said, all is not lost. Although I think the subprofile patch as implemented is a dead end, the idea of extending a distribution (i.e., "compositing your dependencies") is most certainly not. The way to do that is to embrace Composer, and to embrace modules as the smallest unit of composition in Drupal. And there is a initiative going on right now to bring proper Composer support to core. The end result, I think, would allow us to have all of the benefits of the subprofile patch with none (or at least very few) of the drawbacks. The Composer initiative is still in its early days, but my personal feeling is that large organizations, if they want to help, should direct their efforts there. I think they are among the people who stand to benefit the most from that work. As for who's working on that, Mixologic is the guy spearheading it, and he could certainly use more eyes and hands on the work he's doing in that space.

I hope that was helpful, and hopefully not too sad-making! :) I can cover that again in the meetup if anyone asks.

It looks like you are just

kreynen's picture

It looks like you are just building sites on Lightning without a profile/sub-profile of your own. I see you are already a member of https://edudu.slack.com/. There is a thread on there from @dhsieh about how PSU is using profile_switcher to switch sites from the Lightning back to standard. You might want to read more about their experience before you go too much further down this path.

I think we have a custom profile

skyriter's picture

We do have a Creighton install profile here:

docroot/profiles/custom/creighton

There's not too much different in it yet. Actually, it is only blocks.

Is that different than what you are describing?

Compare

kreynen's picture

Compare https://github.com/cu-webteam/d8-platform/blob/master/docroot/profiles/c... with https://cgit.drupalcode.org/openedu/tree/openedu.info.yml#n8

OpenEdu defines Lightning as the base profile meaning that it won't duplicate what's in Lightning, but build on top of it. I'm really not sure what you are doing with that Creighton profile. Are you planning on forking the Lightning profile and re-using the features?

Our dream was to rebuild the Express install profile we use at multiple campuses within the University of Colorado system as a base install profile for other edus interested is using our more locked down, Drupal as a Service approach.

So similar to what OpenEdu did with Core -> Lightning -> OpenEdu profile, we'd have Core -> Express -> CU Boulder profile and Core -> Express -> CU Denver profile, etc. In theory this would have increased the number fo developers working on common features while still allowing each campus to customize their offering as needed to meet their campus specific need.

Our original intent is to use

nixter's picture

Our original intent was to use a base profile. Currently we use lighting to take care of most of the install, and we tack on our custom items used for our marketing team. The idea behind this was to make one profile that could be used for any marketing site and we could make a different profile for other sites across campus that were not marketing sites.

What we are doing seems very similar to how you describe Express working if I am understanding it correctly.

After reviewing our profile I realize that most of our settings are being set on Config Import and not directly turned on or modified at the profile level.

I went back in our history to a different repo before Acquia came in and helped us and I found this install profile we were originally using.

name: 'Creighton ACSF'
type: profile
version: 8.x-dev
description: 'Site Factory Sub-Profile of Lightning'
core: '8.x'
base profile:
  name: lightning
  excluded_dependencies:
    - lightning_roles
    - lightning_workflow
    - lightning_page
    - lightning_landing_page

dependencies:
  - acsf
  - acsf_sso
  - admin_toolbar
  - admin_toolbar_tools
  - content_browser
  - ds_switch_view_mode
  - editor_advanced_link
  - entity_clone
  - redirect
  - features
  - features_ui
  - focal_point
  - imagemagick
  - address
  - admin_toolbar
  - auto_entitylabel
  - eva
  - field_group
  - field_permissions
  - field_validation
  - honeypot
  - mailsystem
  - menu_admin_per_menu
  - menu_block
  - menu_breadcrumb
  - mimemail
  - module_filter
  - context
  - context_ui
  - name
  - pathauto
  - paragraphs
  - plupload
  - quicktabs
  - recaptcha
  - redirect
  - robotstxt
  - role_delegation
  - rules
  - social_media_links
  - social_media_links_field
  - token
  - twig_tweak
  - twig_field_value
  - slick
  - ultimate_cron
  - views_bulk_operations
  - views_data_export
  - views_slideshow
  - webform
  - xmlsitemap

  ## Creghton features
  - creighton_features_creighton_image_presets
  #- creighton_features_core
  #- creighton_features_header_alert
  #- creighton_features_content_page

themes:
  - bartik
  - seven
  - cu2017

Notice the base profile.

Web conference / recording?

chyatt's picture

Do you offer web conferencing or recordings of the meetups? I'm interested in the answers to Kevin's questions too.

To join remotely

skyriter's picture

To join remotely
We'll be using Zoom to connect to Adam and any one else who'd like to join from off-site:
https://creighton.zoom.us/j/867134630

And we'll be recording the session, too.

Drupal in Education

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: