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
Forum
- comments: enabled
- published: yes
- promoted: no
- uploads: yes
- revisions: no
Blog
- comments: enabled
- published: yes
- promoted: no
- uploads: yes
- revisions: no
Article
- comments: enabled
- published: no
- promoted: yes
- uploads: yes
- revisions: yes
extra field: image
extra field: subtitle
Page
- comments: disabled
- published: yes
- promoted: no
- uploads: yes
- revisions: yes
Photo
- comments: enabled
- published: yes
- promoted: no
- uploads: no
- revisions: no
extra field: image
Roles & Permissions
anonymous
- post comments
authenticated
- post forum posts
contributor
- post blogs
- post photos
- posts unpublished articles
editor
- reviews / edits / publishes articles
- posts pages (rarely)
Menu
Assumes use of Path module and/or enabled modules.
Primary
- 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?)
Secondary
- 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
Comments
Looks good!
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:
Thanks
/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
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
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
Actually
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.
photos
Ah sorry, misunderstanding - I thought by Photos you meant album photos project http://drupalmodules.com/module/album-photos hehe. This is quite a bit different.
Life is a process
Life is a journey, not a destination
What about basic/advanced?
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 :)
Wizard
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?
If Community in a Box is to rely only on core, then I guess those can't be implemented.
Maybe, but likely not
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
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
Still think this is a good starting point fro http://drupal.org/node/483987. Couple of thoughts:
Not sure how to best take this further. Maybe incremental steps, starting with the no-brainers for enabled modules?
@yoroy see - Create a default
@yoroy see
- Create a default image field in the article content type upon install
http://drupal.org/node/613794
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.
http://drupal.org/node/613272 - Forums not useable out-of-the-box: disabled comments, no forum
http://drupal.org/node/221527 - 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.