Use Stark as default theme for Minimal install profile

See also #815020: Make Seven the default theme for profile Minimal.

We are currently installing two themes - which isn't very 'minimal'.

This would be great, and doing it quickly would help dramatically with what I'm looking to accomplish from a CSS cleanup standpoint.

Crosspost? Reverting version.

Oops! Thanks @tstoeckler.

Here is a patch that sets the default theme to Stark based on an install using the Minimal profile.

I think it got skipped because of the d8 prefix? I can't find the docs where I think I read that. Anyways, another try with renamed patch.

This one should do it.

Not quite one line. But what I had was too much as well. One reason for no is the line: $default_theme = variable_get('theme_default', 'bartik'); If we were to only make the one line change the variable wouldn't match below. But we can make it a two liner quite easily.

+++ profiles/minimal/minimal_new.install	2011-01-10 21:07:04.951099481 -0500
@@ -7,8 +7,10 @@
+  variable_set('theme_default', 'stark');
+  $default_theme = variable_get('theme_default', 'stark');

The only reason for sticking $default_theme into a separate variable, instead of directly putting 'stark' everywhere, is to make it easier to change the default theme later on. We use the indirection of variable_get() (with a default value of 'bartik'), so that the code below works with and without a preceding variable_set(). Since we now want a custom default theme, we precede the variable_get() with a variable_set() and all is well. So far, so good.
BUT: There is no need to change the default value of variable_get(), because as long as we precede that with the variable_set(), the variable_get() will always return 'stark'. And if we ever remove the variable_set() we still want the profile to work, and we want it to use the system-default, which is 'bartik'. That's the entire point of this indirection. Otherwise we could just do $default_theme = 'stark';

Powered by Dreditor.

@webchick - From a little bit of digging, it looks like, that even though the patch works and stark is the default theme, it never does get enabled. Certainly not on the appearance page and not in the db either. This patch enables stark and disables bartik. Whitespace also fixed.

@tstoeckler - Very good point, I hadn't really though of that. I would totally agree but when I do set the fallback value as bartik, this patch breaks, and still uses parts of bartik. I plan to do more digging but wanted to post the patch/issue.

I don't think we want to force everyone who wants to alter the theme in their profile to write that much code. We should fix the root of the problem, which seems to be both variable and theme system not really functioning at this point.

See also the interim solution for testing (use Stark for the Testing profile) http://drupal.org/node/719814#comment-5147204 and the duplicate issue #1181776: Change theme_default variable to Stark

Moving this to the install system queue since it involves the user experience of the installer (and we don't have issue queues for the profiles currently)... also, that's where #1181776: Change theme_default variable to Stark is (which had some arguments both for/against this change).

Yes, please. Bartik presets way too many visual defaults.

Attached patch removes the default theme configuration from Minimal profile.

It also removes the configuration for the system main content and help blocks, since those should be automatically placed correctly due to #1373312: Assign system_main block to 'content' region and help block to 'help' region by default (followup) already.

Are there any other follow ups that could remove more from the minimal profile?

1. Installed a minimal site
2. Saw Bartik was being used
3. Deleted site
4. Applied patch
5. Installed a new minimal site
6. Saw beautiful Stark was being used

BTW, Winter is Coming.

I've updated the issue summary.

#20: drupal8.minimal-stark.20.patch queued for re-testing.

#20: drupal8.minimal-stark.20.patch queued for re-testing.

One month of waiting and inactivity on an issue in the RTBC queue is way too much and unacceptable.

I'm hereby applying #1399824: [policy] Formalize min/max time thresholds for RTBC patches to this issue.

Therefore, I'm delegating this issue from @Dries to @webchick due to unresponsiveness. The delegation seems sensible to me, since @webchick and I happen to have very different visions on installation profiles in Drupal core, so this re-assignment is not in my and my patch's favor. ;)

On the actual change:

For one, please note the issue summary.

Second, we happened to discuss this already in IRC, and dissecting @Dries' response from that other issue basically means that "Minimal" + its description is a poor presentation of the Minimal profile's purpose and intentions. This totally can be improved, but also, that's totally out of scope for this issue. Hence, created a follow-up for that: #1664894: Clarify Minimal profile's use-case and description

Hold on. This is not "only nice to have". The issue summary states technical reasons for why it is bad to enable a theme that won't be used afterwards.

Contrary to that, the discussion on properly labeling/describing Minimal profile to end-users might possibly take weeks on its own to resolve. No need to tell me that UX and especially initial UX highly matters, but reality is that these are two completely detached and independent tasks and discussions.

But anyway - we sat together in IRC and came up with a very nice and concise new description for Minimal profile, which is already RTBC: #1664894: Clarify Minimal profile's use-case and description :)

Therefore, tentatively also moving this back to RTBC. Totally not meant to fight or overrule anyone, but instead solely on the grounds that we have a fantastic solution for the other issue already, and because that was the only concern raised against this patch.

Can we move forward here?

It seems clear by now that the main concern on this change will be addressed by #1664894: Clarify Minimal profile's use-case and description. That's a pure user interface text issue though, which does not change the scope, use-case, and target audience of the Minimal profile.

Less important, but still, relevant: I'm also very close to replace the default profile for running tests with the Minimal profile — so as to free up the Testing profile from its current constraints and make room for the Testing Framework Next™.

#20: drupal8.minimal-stark.20.patch queued for re-testing.

I spent the weekend to get us back below thresholds (again).

I also tried to address that concern about the plan of attack in the last comments here -- the user interface text improvement for the install profile's description will not change the fundamental use-case of Minimal profile.

It doesn't feel appropriate to me to hold off this change, just because the install profile is described/presented in a poor/misleading way; that's a separate issue, which apparently requires its own discussion and wordsmithing (which I pushed forward as much as possible, too).

#20: drupal8.minimal-stark.20.patch queued for re-testing.

Re-rolled against HEAD.

The situation with thresholds is a bit weird here. I invested a lot of time to get us below thresholds, so this patch can get in, but when we were below thresholds, the patch didn't see any attention, and meanwhile, we seem to be back over thresholds again (not verified whether that's still the case). So essentially, I could as well have not invested the time to get us below thresholds. Very weird, and a bit demotivating. The thresholds are working fine otherwise, but this seems to be a flaw in the system.

I thought about this some more and decided to commit this. Sorry it took this long.

Given the work you've been doing on D8, I've decided to commit both #1664894: Clarify Minimal profile's use-case and description and #632100: Use Stark as default theme for Minimal install profile regardless of the fact we are over threshold. It's an exception, but thanks for all your hard work.