Default install profile: Community in a Box

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

This wiki page evolved from the expanded default install profile page. If you have your own description of what Drupal should be out of the box, please add a link to that wiki page. Please also use a format similar to the one described here, it will make it easier for us to translate directly into an install profile. Please DO make edits / updates directly to this profile if you feel that community in a box is what Drupal should do out of the box.

Community in a Box

A community site with front page articles, a community blogging section, discussion forums, and shared image galleries.

Anyone is welcome to sign up for an account and participate in the forums. After some time in the forums, users are invited to become contributors, and can post blog posts and photos, as well as submit unpublished articles.

The blogging functionality is a community multi user blog. It is not meant as one users blog, but rather a large community that can post quick thoughts responding to each other and sharing their ideas. (Note: this is in here because people get confused about "blog" functionality -- this is meant to highlight that having a community blog is not the same as a single user blog, so don't expect to be able to change titles and designs etc. -- your blog posts are in a shared, community space)

Editors are around and police the forums, as well as reviewing and publishing articles and other material for the front page.

The photo galleries are shared galleries: like the forum and the community blogs, users upload them to share, rather than in their own space. There are weekly suggestions for new gallery categories, and users can also tag photos with whatever they like to mix and match how the photos are grouped.

Wizard Options

  • Do you want forums? yes/no
  • Do you want a community blog for contributors? yes/no
  • Do you want a community photo gallery? yes/no

Content Types


  • comments: enabled
  • published: yes
  • promoted: no
  • uploads: yes
  • revisions: no


  • comments: enabled
  • published: yes
  • promoted: no
  • uploads: yes
  • revisions: no


  • comments: enabled
  • published: no
  • promoted: yes
  • uploads: yes
  • revisions: yes

extra field: image

extra field: subtitle


  • comments: disabled
  • published: yes
  • promoted: no
  • uploads: yes
  • revisions: yes


  • comments: enabled
  • published: yes
  • promoted: no
  • uploads: no
  • revisions: no

extra field: image

Roles & Permissions


  • post comments


  • post forum posts


  • post blogs
  • post photos
  • posts unpublished articles


  • reviews / edits / publishes articles
  • posts pages (rarely)


Assumes use of Path module and/or enabled modules.


  • Home - /node: promoted content, which is mainly articles out of the box; displays ~5 articles on the front page
  • Blogs - /blog: home page of blog module, all community blog posts in reverse chronological
  • Forums - /forum: landing page of forums
  • Photos - /photos: latest photos (NEW - needs issue filed)
  • Archive - /archive: all posted articles (NEW - needs issue filed) (BM: not sure about this -- maybe ALL content ever posted?)


  • About - /about
  • Contact - /contact

Enabled Modules

All enabled modules, with notes on config not covered above.

  • Blog
  • Blog API: enabled for "blog" content type
  • Color
  • Comment
  • Contact
  • Database logging
  • Forum
  • Help
  • Menu
  • OpenID
  • Path
  • Ping
  • Profile: hopefully an evolved fields-attached-to-user-object rather than current profile. Needs notes on default user info.
  • Search
  • Statistics
  • Taxonomy
  • Tracker
  • Update status: check box on final install review screen, prompts to specifically disable


Looks good!

rickvug's picture

This profile would be an excellent running start that also demonstrates of Drupal's capabilities. It is also realistic as it uses Drupal core only. Two nitpicks:

  • /Archive and /photos look like they both depend on Views. If Views or something similar ships with D7, I'd be in favor of both, along with various other listings (recent comments, popular content etc.)
  • In my experience, Blog API is not frequently used. I'd prefer to leave is disabled as the default.


Boris Mann's picture

/archive and /photo could be Views ... which likely won't be included with D7. I somehow doubt I'll be able to get /photos in, but /archive is identical to /node except that it is all content, rather than just stuff with the promoted flag. Why have this? Well, it solves the "I posted content, but it disappeared" problem. "If it's not promoted, it's in the archive".

There is no harm in enabling Blog API, and it immediately allows use of offline editors (and auto discovery of the proper paths, too) plus cross posting from Flickr. It also requires no configuration. Extra functionality, no configuration, win-win :P

(have you used / trained users in posting static pages using an external editor? thing of beauty, try it out some time...)

Approach this step by step

rickvug's picture

I think the first step would be to get the profile in without /archive or /photos. An interesting core patch that relates to this is "Allow more users to see the node admin page". If this gets in, there will be a way for users to see and edit all content that they have access to. It wouldn't look like /node, but it is an option.

There isn't any actual harm in enabling Blog API, but I generally don't like enabling something that a very high percentage of users will not use. I have tried Ecto and Mars Edit in the past but have never trained users to do so. My main Blog API usage has been posting photos from Flickr.

Views in Core

eigentor's picture

Hmm, I am also not sure about Views. But given priorization of goals and somebody has any energy left after the d.o. design upgrade, it is definitely #1. Last time I doubted this aloud on #drupal I had quite some people object. As far as I understood, there are quite some more people than Merlin deeply enough inside the topic to pull that off.
(Psst: I quietly doubt the code freeze will be point September first, but don't tell Dries :) )

Given the feedback from the D.O. D6 upgrade everybody was so glad to have gotten Views into Project Module no one could understand why it wasn't in earlier. Nothing against applications like Photos, but a Views alternative in being much more generic would always get my vote.

Life is a process

Life is a journey, not a destination


Boris Mann's picture

I fully believe that code freeze will be September 1st. It just means that D8 won't take as long as D7 has.

Photos, by the way, is just imagefield plus a content type defined.

And @rickvug -- yes, all of these things will be separate patches, and will be debated on their own merits. I don't think admin/content is a suitable alternative for a /archive. Robert Douglass' last post on Acquia about the recipe about per user content dashboards could be really slick.

To stress: all of this stuff doesn't depend on a Views implementation in core. These are core items that we are suggesting to include.

In any case, I've got Richard Eriksson who has agreed to put some time into working on this with me, so my next step is going to be actually building this thing. Once I have a good public space, I'll post directions on how to work on it more directly. Or y'all could start on wireframes / designs for a new core design that specifically support this use case.


eigentor's picture

Ah sorry, misunderstanding - I thought by Photos you meant album photos project hehe. This is quite a bit different.

Life is a process

Life is a journey, not a destination

What about basic/advanced?

Kevin Hankens's picture

One thing I like about a lot of desktop software is that you have the option of a basic vs advanced installation where you can pick individual packages.

How about having a button at the top saying "Install Drupal" and beneath that have a collapsed fieldset called "Advanced Install" with checkboxes for each package like forums, etc.

It would be a good way for a first timer to just let 'er rip and see what comes out of the box. It would also allow people to get a sense of what was going to be installed so that they know what to look for (non-rtfm-ers). Also, if you wanted to do a basic core installation, it would be easy enough to uncheck the options.

I know this is similar to the current d7 install page, but rather than just having a binary option, I think the fieldset might help.

Sorry if this is off-topic :)


Boris Mann's picture

Exactly. Those are the wizard options. When you picked default, the first screen would be an extended description of Community in a Box, and then the choice to either do an "express install" (all default options by default) or to follow the install wizard, which would walk you through several choices.

So, are photos and archive going to be removed?

jackbravo's picture

If Community in a Box is to rely only on core, then I guess those can't be implemented.

Maybe, but likely not

rickvug's picture

Install profiles are technically now special modules so perhaps the install profile itself would provide the photo gallery and archive (without using Views unfortunately). Imagefield is a code freeze exception so there is a strong chance of it being available to use with a core community profile. While the building blocks are there I do not see this happening. There are no patches being championed and we are now in "code slush" so new features now need to target Drupal 8.

Great idea

Boris Mann's picture

Rick, great idea, but I'm not sure if an install profile can also provide functions? Since it's a module, I guess it can -- that's a great idea for /photos and /archive. Who knows, /archive could even go in core (/photos definitely won't).

Re: code slush. In the past, install profile work has been allowed in post freeze -- you usually can't work on them until most of the rest of the new version is frozen. Still, it definitely needs (as always!) people to step up and code this. That's my downfall, unfortunately - I can architect and come up with ideas, but I'm not a great coder.

Still think this is a good

yoroy's picture

Still think this is a good starting point fro Couple of thoughts:

  • Don't enable forums immediately. They don't make sense out-of-the-box because you'll likely be the only user on this new installation for some time. Core forums are usable but not exactly a shiny bright example of where Drupal is at right now. A forums-only site is very specific. A site with also a forum in it somewhere, well, again, you'd need quite a user base before forums are a viable option.
  • Definately want to have a content type with an image field now that this really has landed in core.
  • Would love to see at least one of the proposed extra roles. something between authenticated and admin just makes sense. editor?

Not sure how to best take this further. Maybe incremental steps, starting with the no-brainers for enabled modules?

@yoroy see - Create a default

heather's picture

@yoroy see
- Create a default image field in the article content type upon install

  • can you review this patch, and maybe bump it along?

I agree with not including forums. Besides just enabling the forum module and creating the content type- there seem to be a few more considerations to setting a forum up: container, taxonomy, naming the forum, etc.
While there seem to be some things that can be fixed in forums, i think there are some obvious flaws we're not going to be able to handle in this wizard. Actually a wizard just for configuring a forum, alone, would be nice. - Forums not useable out-of-the-box: disabled comments, no forum - Don't show Create Forum topic (node/add/forum) when there isn't a forum

That is in addition to the reservations yoroy already has about no clear use for a forum in most sites.