Clean up Minimal profile modules

Is there anything written anywhere for what the Minimal profile is intended for and what people actually use it for?

Updated the summary to indicate that we don't actually have to do anything.

The minimal profile's purpose as far as I understand is for experienced site builders who don't want to fuss around uninstall modules they don't need. From the .info:
description: 'Build a custom site without pre-configured functionality. Suitable for advanced users.'

IMHO this is a wontfix and yak-shaving. ;)

We don't have to do anything.

I think we should remove node. We don't provide any default content types, so node.module is pretty much unusable by default anyway. So the difference is negligible. You'll find yourself visiting the modules page anyway with minimal, so adding one more check shouldn't hurt.

Giving this a less dramatic title :)

So the root cause of the problem is that the Node module isn't really useful on its own right now (and related weirdness, e.g. #987242: The "Promoted to front page" checkbox doesn't do anything if the /node front page listing isn't used), but does make sense if you enable certain other modules. (Views is one of them, but Menu would work equally well too.)

That seems like a larger issue, but for the purposes of this issue, I think removing it from the Minimal profile would make sense.

:)

First of all, I'd recommend to leave this discussion to those that are actually using Minimal profile. So if you don't use Minimal profile, it's probably best to unfollow this issue.

(I'm still surprised that senior Drupal developers are using the Standard profile for building new sites... but well, after all, we have install profiles exactly to allow people to choose what they think works best for them.)

As someone who's using Minimal profile exclusively, its description summarizes its scope and target audience best:

Build a custom site without pre-configured functionality. Suitable for advanced users.

(which we've improved in #1664894: Clarify Minimal profile's use-case and description for D8 only recently)

Since D7, the Framework Initiative thankfully managed to decouple and remove a lot of baked-in assumptions.

Note that Minimal is the only profile in core that tries to serve a concrete use-case.

Given where we're heading with D8, the situation of what constitutes a "minimal" configuration for building out a new site from scratch has definitely changed:

1. Without Views, you can't do much.
2. Without Block, you can't see much.
3. Without Field UI and Entity displays, you can't build much. (cf. Minimal profile description)

4. Node content, OTOH, is just one of many possible entity types, and I can come up with a dozen of use-cases that don't need any nodes.

   Especially because you do not see any nodes by default anymore, that clearly puts Node module into the nice-to-have bag.

Consequently, attached patch is what I'd recommend in order to establish a minimal set of modules for the concrete use-case that the Minimal install profile targets.

Lastly, note that I've thought a couple of times already about introducing a new Zeroconf profile for D8 core, which would literally have no modules enabled and no configuration at all. That is, as a clear difference to Minimal, which serves a concrete use-case and thus needs to make assumptions.

(Also, we'd be able to use that Zeroconf profile as a drop-in replacement for Testing profile and temporary transition layer for tasks like #1541298: Remove Node module dependency from Testing profile.)

Dang. Obviously forgot Views UI. (Due to #1820414: CHANGE NOTICE: Move views_ui.module directly into /core/modules/)

@sun Does this add another profile to core, that users can select?

@Bojhan: Nope, not this issue. I'm sorry if my considerations for a new Zeroconf profile caused confusion. Moved into #1951526: Add a zero configuration installation profile

With #1851086: Replace admin/people with a View, #6 becomes even more true.

Attached patch should hopefully come back green.

Field UI not being enabled has always bugged me. I totally agree with the assessment here.

I still feel that there's nothing minimal about installing Views.

I know I'm just adding to the noise here, but I like the "minimal" profile (in Drupal 7) because I don't like overlay, shortcut, contextual, etc for most of the sites I build and it's annoying to always disable them. I'd rather enable them in the small number of situation where I think they'd be useful.

That said I always use node and views! So, for this humble minimal profile user, I'd personally be happy with both node and views being enabled.

In the future, there will probably be more and more cases where some other entities are used rather than nodes, but I have still to build a single site where I don't use nodes.

Anyway, if the minimal profile ends up not being useful for me anymore, I'll just build my own profile. ;-) So, it's not that big of a deal.

First off, I think the word Minimal is a confusing word to describe a profile that has any non-required modules enabled, since that makes it not the least in amount, number, or size possible. Unless the argument is that while the specific module is non-required, it only makes sense to disable it if you replace it with something else. For example:
- You can disable block.module if you instead enable some other module that lets you see stuff.
- You can disable dblog.module if you instead enable some other module that lets you log stuff.
- You can disable views.module if you instead enable some other module that lets you see critical listings, like /admin/people.

Note that the above examples aren't strictly true. You can perfectly well disable block, dblog, and views, and still see the primary content of pages, and get along fine without logs and user listings. So the argument becomes more like, well, yeah, you can, but we can't think of a single real site where that would actually be acceptable.

Once we start adding Views UI and Field UI though, as #10 does, then we're going further. We're making the assumption that there are reasons someone chose to use Drupal to begin with, and that at least one reason involves using a UI to build the site's data model and listings. Which I think is perfectly consistent with the Build a custom site description of the profile.

Node content, OTOH, is just one of many possible entity types, and I can come up with a dozen of use-cases that don't need any nodes.

Per #14, I question this. If we're serving the need of "build a custom site", isn't it very likely that that site will have some content? And nodes are the de-facto entity type for content. Sure, you can disable node.module and enable some other module instead, if you want to model your content as something other than nodes, but I think that's far less likely than wanting to disable dblog.module and enable some alternate logging module. So if it's ok to start people off with a not-always-ideal dblog.module and a not-always-ideal block.module, why is it not ok to start them off with a not-always-ideal node.module?

Er, as the author of #14, I think you misinterpretted what I was saying. I was placing my vote FOR including both node and views in the minimal profile because those are module that I always use when building all sites -- as I stated in #14, I have never built a site without the node module. So, I'm saying, that in my humble and highly-subjective opinion the node module should be included. :-)

That said, my opinion probably doesn't matter at all! But since there was sort of all call in comment #6 to hear opinions from users of the Minimal profile, I decided to add my voice.

To me, the most important part of Minimal is that it doesn't have configuration. No content types or vocabs or custom theme.
Leaving out the non-site-building modules like Overlay, Toobar, and Tour is good as well.

I'd like to see Views UI, Field UI, and Node all in there, since they are site building modules that don't overly complicate your site just by being installed.

I agree with @tim.plunkett - not having to delete Page and Article is another plus of Minimal and I'd personally be very happy to see Views UI and Field UI in there as well.

Maybe it'd be better to rename this profile to "Advanced user" rather than "Minimal"? Any advanced user will want Views UI and Field UI when starting out with a blank site....

I think you misinterpretted what I was saying

Nope. Perhaps I wasn't clear in #15, but what I was trying to say there is that if we want Minimal profile to be one targeted for "building [with a UI] custom sites [with content]", and that use case is our justification for enabling modules like dblog, block, views, field ui, and views ui, then I also believe node.module should be included too.

Note that Minimal is the only profile in core that tries to serve a concrete use-case.

This is basically saying that Standard does not serve a use case. Whether or not that's true is out of scope for this issue, so pardon the off-topic comment here, but I'd like to express disagreement with this.

I think our Standard profile is pretty decent (though could be better) at serving the use case of "build a simple, small, low traffic, information sharing website quickly". Where "information sharing" can encompass brochure sites, simple blogs, etc., but not ecommerce, political organizing, event coordination, etc. Everything in Standard profile, from the Article node type to Overlay and Toolbar are in service of that goal (especially the "quickly" part, where "quickly" is targeted to someone not already proficient with Drupal).

@effulgentsia: Ok, so, in other words we're in agreement. :-) Sorry for the confusion, I got thrown off by:

Per #14, I question this. (Emphasis added)

... because I thought it meant you were disagreeing with me.

Take care!
David.

So maybe we rename "minimal" to something else, to indicate it's for the "basic sitebuilder toolbox with no preinstalled config" usecase?

@xjm: that's sounds good to me! Maybe something like "Advanced user" or "Advanced site builder" or something. I think people are used to the idea that there's a standard and an advanced for experienced users, for example: standard search and advanced search. Just my 2 cents.

I would not go to renaming a profile so quickly, we have done quite some discussion and testing to arrive at this name. Its not perfect, but I dont get the goal here for changing it.

It looks like the majority of users is on board with the suggested changes in #10.

So let's get that patch green, please. :) Renaming Minimal to something else can be a separate issue — completely peripheral for the essential fix here.

+++ b/core/profiles/minimal/minimal.info.yml
@@ -3,6 +3,9 @@ description: 'Build a custom site without pre-configured functionality. Suitable
-  - node

I don't think there's agreement on that.

Oh. Sorry, I agree, minus that removal, of course. Any takers? :)

I still feel that there's nothing minimal about installing Views.

I agree; this confuses me too. If Views (UI) is being added because it's a useful tool for site builders, there are several other modules that would fall into the same category (Path, etc). Why not those too?

Meanwhile, there are plenty of legitimate reasons to build a site without using Views (see http://www.phase2technology.com/blog/building-energy-gov-without-views/, or http://drupal.org/project/totem, a Drupal distro that doesn't use Views for similar reasons). It's a completely valid use case.

The situations I've used the Minimal profile myself (as well as seen others use it) are ones where I have a list of modules + configuration I want to enable when starting a particular site. In that case, turning on everything in the list is simpler than also having to remember to turn other things off. Perhaps others have a different use case, but I think this is the one that is consistent with the name "Minimal".

Currently the Minimal profile installs three optional modules (node, dblog, and block) and three pieces of configuration (it puts the Administration, User Login and Tools menus in the left sidebar), so in that sense it doesn't live up to its name. The main reason it can't remove all of those is that you'd be left with a site that you can't log in to or administer without typing in URLs by hand. To me, however, that is just a sign that the core system is missing some sensible default functionality regarding these links; for example, see how drupal_render_page() forces the main page content to be present when no module adds it.

For the purposes of this issue, though, I'd still be happy to just see Node go away and that's it.

I think we can all agree our purpose of minimal profile is to simply not have Drupal make any assumptions about what to pre-install or pre-configure so that we, as seasoned developers, don't have to uninstall or unconfigure anything. It saves us time.

The discussion starting in #1806334-185: Replace the node listing at /node with a view that inspired this issue basically asked "why would the default front page be /node (or /user)?"

That said, any site we build, no matter how simple or complex requires that we apply some effort, including, setting what the default front page will be. So, given this, part of me wonders "Who cares that the default front page is when I install the minimal profile? I am just going to change it anyway, just as I am going to download and configure contrib modules, write custom modules, and develop a theme, etc."

With regard to the other comments in this thread that discuss "what is a useful tool for site builders," I don't feel that is really in-line with what was discussed in #1664894: Clarify Minimal profile's use-case and description. Minimal is for experts who know what they are doing; If you know what you are doing, you probably don't care too much what the default homepage is out of the box, IMHO.

So, I advise we let experts be experts, and remove everything except block, which is necessary to use Drupal via a browser. The attached patch does just that.

Tag got removed? Re-tagging.

+++ b/core/profiles/minimal/lib/Drupal/minimal/Tests/MinimalTest.php
@@ -33,12 +33,11 @@ function testMinimal() {
-    $this->assertText(t('Tools'));

In that case, let's also remove core/profiles/minimal/config/block.block.stark.tools.yml.

block, which is necessary to use Drupal via a browser

Not exactly. Or rather, it depends on your definition of "via a browser". For people who know all of Drupal's admin URLs by memory, they could type them in the address bar, and therefore not need the Administration menu block. But, if you define "via a browser" to mean that you can click your way to your admin pages, then yes.

+++ b/core/profiles/minimal/minimal.info.yml
@@ -3,6 +3,4 @@ description: 'Build a custom site without pre-configured functionality. Suitable
-  - dblog

So what this does is say that if some error occurs on your site before you've enabled dblog, then you're on your own for debugging it. Are we then saying that the target audience of the Minimal profile is someone who can debug without log messages?

But, if you define "via a browser" to mean that you can click your way to your admin pages, then yes.

Yeah, this is more what I meant. I was imagining someone who had never used Drupal before but wanted to dive into the minimal profile just for kicks -- they might want to click something. Also, URLs can change (admin/build vs admin/structure) so memorization isn't really a UI. :)

So what this does is say that if some error occurs on your site before you've enabled dblog, then you're on your own for debugging it. Are we then saying that the target audience of the Minimal profile is someone who can debug without log messages?

I see what you mean, I don't really have a horse in this race. There could be, however, errors that even prevent the db being written. What about replacing with syslog? Personally, I'm more prone to tweak my error_log and display_errors settings in php.ini if I'm debugging installation errors.

What about replacing with syslog?

Someone could be installing on a host that doesn't provide access to the syslog.

There could be, however, errors that even prevent the db being written.

That's true for Standard and all other profiles as well, so is out of scope for this issue.

URLs can change (admin/build vs admin/structure) so memorization isn't really a UI.

Well, once you can get to /admin, then you can navigate the rest from there. Which makes me wonder: why not make that the default front page?

So, this patch does that, removes block.module, but retains dblog.module.

Note that anonymous users get an access denied, but can still get to the login page via the primary links menu (which is not yet a block). That will change with #1869476: Convert global menus (primary links, secondary links) into blocks, but we can deal with that then; for example, we can make our 403 response include a Login link for anonymous users.

Minimal is for experts who know what they are doing; If you know what you are doing, you probably don't care too much what the default homepage is out of the box, IMHO.

Well, dsnopek gives some useful feedback in #14. I just want to point out that by making Minimal truly minimal as in #29 or #33, we make it slightly less useful to him and people like him. Experts know what they're doing, but it doesn't mean they enjoy doing extra menial work, like enabling the modules that every custom Drupal site ends up using anyway. But, I also think there was good feedback from people that Node and Views are not really in that category, even if they are highly popular.

.

blocks seems required now, but node could be removed from testing profile at least

Re rolled.

Hello!

Thank you for working on this issue!

We should all try and use the same sprint tag. According to https://groups.drupal.org/node/447258 it should be SprintWeekend2015 with no #.