-
Notifications
You must be signed in to change notification settings - Fork 395
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BLT + Standard Profile Configuration Issues #4244
Comments
Update: Updating / overriding this to use lightning instead of standard makes this a non-issue. Is there a reason that we ship Lightning w/ the recommended project but install standard by default in BLT 12? Again, I think if this was exposed in blt.yml it would be much more obvious. |
choices are: use lightning (not standard) |
Thanks @mikemadison13. Regarding the config-override, Im assuming this would be adding to our settings.php something like:
Unfortunately we cant remove the actual links since those arent in config so what exactly would we be overriding in this case? |
no, i would do this in the blt.yml file:
|
you could also grab the lightning "fix" for these to iterate through and delete the shortcuts on install: https://github.com/acquia/lightning/blob/5.0.x/lightning.install#L41 |
gotcha, now that im looking at another blt project or ours we are using that allow-overrides setting. In this case what worked was that setting plus I had to change the uuid on shortcut.set.default.yml to null. |
I don't see any way for BLT to solve this, it's a perennial bug with the Drupal config management system (or the standard install profile, however you prefer to look at it). The problem is that many profiles dynamically create content (such as shortcuts) that will generally have different UUIDs than whatever's stored in your config on disk, and so Drupal refuses to import your version from disk. The only surefire solutions are to use a more well-behaved profile that doesn't dynamically generate config, or install from config (bypassing profile hook_installs).
Because BLT 12 can be added to any distribution, many of which aren't Lightning. The only safe defaults are profiles available in Drupal core, i.e. standard. Even if we change this back to Lightning (not a trivial ask btw, we'd need to dynamically set it in blt.yml during composer installs of BLT) it leaves non-Lightning users in the lurch. |
i'm fine not doing lightning, but i don't think we can do standard either (unless we want to start shipping a fix for standard, which i agree isn't in our scope). how do you feel about minimal? maybe this isn't an issue there. all i know is that out of the box our recommended config strategy doesn't work because of our own default settings and the way standard works. that's not cool! |
I should state right up front that this isn't necessarily a BLT bug. But I think we need a way to work around it.
Describe the bug
After spinning up a new site and exporting configuration the first time, config imports and updates fail immediately due to https://www.drupal.org/node/2583113
To Reproduce
Steps to reproduce the behavior, ideally starting from a fresh install of BLT:
Expected behavior
Config Import will run
Detailed error output
System information
Additional context
Based on what's going on, I think we have a few options:
The text was updated successfully, but these errors were encountered: