I just opened up two issues:
The idea is to get more dummy content into the default profile, whilst at the same time provide a stripped down profile for people who don't need it. The question is, what else could we put in the default profile if we're able to bloat it a little?
Enable more modules? Which ones?
Dummy content in page nodes and dummy primary links pointing to them?
Dummy article posted to the front page?
Dummy 'categories' vocabulary with a select list?
I'll admit to knowing very little about the install profile system, and it might get overhauled itself during D7. But it'd be good to get a list of things that might be helpful to have examples of when you first install Drupal, and see which of those we can squeeze in to the default profile without making it too annoying.
Comments
Everything in system.install
Pretty much everything in system.install is a candidate for moving to default.profile. The challenge is that it is currently a mess of db query's, because we don't have install_profile_api - like wrapper functions / data API system calls to set those settings.
We need to separate code (modules, etc.) from config (e.g. RSS feeds are set to summary by default out of the box).
And, of course, this opens up the "what should Drupal do out of the box?". Thanks for taking up this charge -- I'd love to see a default.profile, a forum.profile, and a multiblog.profile.
task-oriented profiles
I'm all in favour of task oriented profiles (and single/multi-user blog and forum are good candidates) - however IMO those profiles would need to have some contrib modules packaged with them, which opens a big can of worms. Moving stuff out of system.install is a good idea - we might want to see how dmitrig01's ideas about refactoring install profiles progress for that one: http://groups.drupal.org/node/11548
Contrib and "real" profiles
If we don't ship with at least two "core" profiles, we will hinder growth of install profiles in general.
I don't want to open the can of worms of adding additional contrib modules. I do want to show people what's possible.
Why do we ship with the defaults we do? We have a task oriented profile in default.install ... it just doesn't do anything without "some contrib modules packaged with [it]". Can you describe what kind of system default.profile installs? What its goals are? I can't...
So...hence my example of multi user blog and forum as two examples that CAN be built out of the box, to some degree without extra contrib. They play to Drupal's strengths (multi user, different permissions), and showcase different features in core.
And I've spoken with dmitri at length about this, and yes, install profiles need refactoring, and I agree with the direction.
The default install profile
The default install profile certainly doesn't set anyone up for any kind of site - part of the reason I want to make it an 'introductory' profile and have the empty advanced one that does almost nothing.
I'd be very concerned about a multi-user blog install profile that doesn't ship with some kind of editor. Or a forum profile without bbcode, or pms. A blog profile is going to be immediately compared to wordpress, an install profile to phpbb et al - if it falls significantly short of those then you're looking at an explosion of "drupal's forum sucks" threads again.
vocabularies
Answering greggles and macgirvin from http://drupal.org/node/261869.
I'm not sure about default terms in a freetagging vocabulary - because by definition these are normally created to tag existing content. If we have existing content (say three news articles), then I'd be happy to see those articles tagged with c. 15 tags.
I'd be in favour of an additional 'categories' vocabulary using a select list - and this would need to have terms in it. Could maybe have some basic hierarchy even to show how that's done.
Freetag
I'm not sure that freetagging requires any default terms. That kind of goes against the principle of freetagging.
My comments on the issue were mostly about a default category set. I'd love to see it, but seeing the level of disagreement over ridding one page of the words 'blue smurf' I'm skeptical anything ambitious can ever happen.
So I'm in favor of something existing in taxonomy on a newbie installation. A few words is something we actually might be able to get committed one day. My default 150 categories is something I'd like to see in a taxonomy 'library' for lack of a better term, but not as a default for everybody. A lot of sites have invested a lot of time into creating meaningful taxonomies and some of us would love to share and improve the better ones without typing every term in by hand. That's completely different from having a taxonomy with something in it so new folks can see how it all works.
Thinking on the Fly here...
After examining the discussion about default taxonomies, and considering discussions about including contributed modules on installation, I agree that task-oriented profiles and selectable taxonomies would be an installer improvement. It would greatly help to give the user some means of selecting additional modules to download and install, and it would also help to have some means of selecting special taxonomies to download and install.
I fully acknowledge that there are MANY issues that such an approach would raise*, but it seems to me that it would greatly help end users to have choices that they could make from some list of options—both for modules and taxonomies. I know it would have helped me!
David
I'm a bit concerned by this
I'm a bit concerned by this direction. Have we fully considered what effect having more defaults enabled will have on new users? I'm aware people ask for it and believe it will have made things more obvious for them, but it's generally not a good idea to just run with an idea because people ask for it or we end up with The Homer car.
So my questions are:
This strikes me as a rather big change in what we present to new users, and so should go through some usability testing (if only informal) before it is made default. No reason not to continue building the profile (in fact we need to if we are going to test it), but I think before we ship Drupal 7 with more defaults we need to do more research on the impact.
-
www.alanpritt.com
Definitely it's the sort of
Definitely it's the sort of thing that should be tested.
Maybe the same task with and without defaults - and try to choose tasks which the defaults might make easier or go against. Note the only current patch to actually add defaults is for an empty tags vocabulary attached to articles: http://drupal.org/node/261869
I also think any defaults have to be extremely generic - so it's clear they can be altered/removed rather than giving the impressing that people are logged in. Although having a minimum profile might help to make that distinction as well.
I'm setting up a multiuser
I'm setting up a multiuser blogging profile now and the contributed modules are all downloaded from ftp.drupal at install time.
Given the power and flexibility of the core modules I'd suggest putting out a few different profiles with D7 and, among other things, see if users select a specialised use case or go for the default minimal system.
Just like every other developer I think I've got a killer app - kidding. But downloading at install time is a nice bit of polish for those new to website / remote management. Many users simply can't see that they have to download something just so that they can upload it again (contributed modules).
The headache with that is that the modules have anomalous versioning numbers/syntax.
I've got the download / install script working to the point that it gets the most recent stable modules, unpacks and installs them - finally.
If I had more time I'd be adding a configuration step (or two) for the user - so that things like an 'About Us' page is automatically generated by the installer.