Problem/Motivation

Issue #2847582 ‘Out of The Box experience initiative’ proposes the creation of a demo to provide a valuable showcase experience of Drupal ‘in action’. Something that is offered by most other CMS platforms but currently missing from the Drupal project.

The intended audience for this demo is broad and target user types include those evaluating Drupal at the initial ‘just-looking’ stage and users who want to know more about Drupal’s capabilities and how it works ‘out-of-the-box’.

We want this out-of-the-box experience to highlight the incredible features, architecture and possibilities that Drupal provides. To do that, it has been agreed to create a demo experience around the scenario of a publisher’s website for a food magazine.

This issue defines the goals and requirements for the production of a finite set of content that will be included in the demo install and around which design and theming can take place for the proposed publisher scenario.

Proposed resolution

Create customised content for the new demo theme

Given the scenario of a publisher's website that promotes a food magazine, we will define and create professional example content that can be bundled with the installation profile and populate the demo theme when installed.

Since the purpose of the demo is to introduce key features and capabilities of Drupal core, we can create a content brief that is structured around and restricted to the requirements of a project MVP. As such, it is the features of the demo that can lead the content brief.

To ensure we get the best quality example content and assets, we can create an accompanying brand to guide the image, style and tone of the example food magazine.

Remaining Tasks

Phase A

  1. Agree on a content model for MVP
    1. Planning already happening here: https://docs.google.com/document/d/1WdVkScJGs-wHKujvNvwKba_sSuHiHmL69EOa...
    2. Define the review process and any sign-off requirements for the content creation
  2. Define a brand, style, tone and content brief for the food magazine
    1. Discuss what we have already created and how it stands up, either as a direction or potentially ‘good to go with’
    2. Scrap-booking of the sorts of features that similar magazines provide in order to create a convincing pastiche
    3. Ideas for articles, need to be easy to create so general ideas likely to work better eg: Cooking for health and fitness
  3. Define what guidelines and requirements for copyright and licensing that we must follow
    1. Fonts
    2. Images
    3. Recipes (can we use pre-made ones?)
    4. Who can give advice?
  4. Create architecture plan for the implementation of importing default content
    1. Should we use migrate?

Phase B

  1. Define how much content is required for MVP
  2. Define when content is required by
  3. Copywriting assignment
    1. Who?
    2. How?
    3. Recipes - brief the requirements and how we source enough
      1. Crowd sourcing - community submissions? Donated?
      2. The wireframe for the Farmers market is a good starting point
  4. Define what supporting content assets are required eg: media
    1. Images
      1. Recipes - someone with a good camera is going to be busy cooking! Or what easier options are available without copyright/licensing issues
    2. Illustrations
    3. Limitations eg: file size
    4. Who and how?
  5. Is there to be accompanying demo features such as tour?
    1. Does this need to be a separate issue for when everything is coming together?

Phase C

  1. Produce professionally written content including media assets
    1. Who and how?
    2. How will the content be collaboratively created and reviewed

Comments

nedjo’s picture

FileSize
2.32 KB

And the new file for inclusion as profiles/default/welcome.inc (I haven't figured out how to get the diff -N option working....)

Stefan Nagtegaal’s picture

Nice small patch!
Works as expected IMO..
Let's have someone else review/test this and get it in... :-)

kkaefer’s picture

Why do we need an additional file (welcome.inc) that uniquely holds the welcome message? I think the profile files are not that big and could hold the hook_(profile_)?welcome as well.

nedjo’s picture

Why do we need an additional file (welcome.inc) that uniquely holds the welcome message?

Good question, and I could go either way. I've been thinking:

* Maybe we want to keep the .profile file for install-related tasks.
* The welcome message is something people might want to customize for a particular profile, so its own file is handy to avoid having to patch the .profile file.

But I could easily be convinced that this isn't needed, at least not yet, and we should stick with simply adding to the .profile file as suggested. Any other opinions?

kkaefer’s picture

Maybe we want to keep the .profile file for install-related tasks.

Well, the welcome message is actually install-related because the message is just displayed if you didn't set a front page or if there are no items on the front page (node.module does that, for example).

If people are deploying their own install profiles, they won't have to "patch" their own file. It's something they just insert in that file.

nedjo’s picture

Here's a new patch implementing timcn's suggested change. The function profilename_profile_welcome() is put in the .install file. We follow closely what's done for module hooks (code adapted from module_invoke()). If a particular profile doesn't implement a hook, we look for an implementation in the default profile.

I agree that this is simpler and probably better at this point than using separate files.

eaton’s picture

Why not provide a simple 'what to show if no nodes are present' setting for node.module? Profiles could simply variable_set() that on installation, and the user would be able to alter it as well.

webchick’s picture

@Eaton: That's a good suggestion, although I can't picture what the UI would look like for that.

What about just sticking the welcome message in a theme function? Then you could do:

function yourtheme_welcome_page() {
  return t('Welcome to our spiffy distro...');
}

or

function yourtheme_welcome_page() {
  return t('No promoted content was found.');
}

or even

function yourtheme_welcome_page() {
  drupal_goto('node/23');
}

(ok that one is a bit of a hack :P)

nedjo’s picture

Why not provide a simple 'what to show if no nodes are present' setting for node.module? Profiles could simply variable_set() that on installation, and the user would be able to alter it as well.

Well, good question. This would be like e.g. the current user_mail_welcome_body setting in user.module.

I see the point, but I don't see that this makes sense as a setting. It's not something the user will need to alter--it's for her/his initial orientation and not intended for public viewing. (Unless we reconceive what welcome messages are for.)

(Do we currently have a way to call e.g. variable_set() from a profile? I thought not.)

IMO this initial-use text fits better in the profile as in the patch rather than in a variable.

eaton’s picture

We do have a place to call variable_set() from a profile. And the problem right now isn't that it's a 'welcome' message, it's a "no nodes are promoted or visible" message. Users often encounter it when, for whatever reason, they have no promoted nodes. Suddenly, their site has a 'welcome to drupal!' message.

nedjo’s picture

@webchick: Hmm, that would make messages theme-specific rather than profile-specific (keeping in mind that several profiles could share the same theme and be packaged in the same distribution). It would also keep the issue of this single-use code sticking around with every page load.

%Eaton: Nice, I'd missed the profile's install function getting in. I agree that it's an issue that the welcome message shows up unexpectedly, but it feels like a separate one. To change that, we would change the conditions under which the message appeared. This issue, so far at least, is just to make the message, when it appears, specific to the install profile.

I'm hearing implicit agreement that pulling the hard-coded welcome message out of node.module and letting profiles set their own message is a good aim. Part of what makes this issue complicated is that we're just figuring out how we best put things into profiles. Hooks, variables, themes? It does feel worthwhile to take a bit of time to get it right.

The variable_set() approach would work. It would have the potential disadvantage of requiring all profiles to include an _install hook that, at a minimum, sets a welcome message. Or else we keep the hard-coded text in node.module, changing it to the default for variable_get('welcome_message', $default).

One potential issue with the patch is that it assumes the existance of a 'default' profile. Is this valid? Should we be instead testing if it exists?

webchick’s picture

How about this approach?

1. Chuck all the hard-coded stuff in node.module into node_empty_message(); // or welcome_message, if you're so inclined... I personally believe that calling it a "welcome" message is horribly deceiving, but that's a topic for another rant. ;)

2. When there are no promoted nodes, do an:

$output = variable_get('node_empty_message', node_empty_message());

3. In your profile's custom _install hook, variable_set this to be something sane.

4. We could also provide a UI for changing this under site configuration settings.

webchick’s picture

One potential issue with the patch is that it assumes the existance of a 'default' profile. Is this valid? Should we be instead testing if it exists?

Yes, I think so.

nedjo’s picture

@webchick: That sounds basically fine. I personally want to get away from the node tie here. If what we have isn't a welcome message, we should make it one. Our current approach seems like a leftover from a time when (a) drupal was primarily a bulletin board, and (b) we knew that /node was the home page on initial install.

I've been thinking narrowly of the 'profile-specific-welcome-message' issue, but it does seem like we should take a step back.

Maybe:


function theme_node_welcome() {
  return variable_get('node_welcome');
}

Then profiles can set the variable, other modules can invoke it, and themes can override it.

Beyond that, we have the problem that showing a welcome message at /node when there are no promoted nodes is a bit of a hack. What should show at /node post-setup if there are no promoted nodes? What should be the trigger for displaying the welcome message?

nedjo’s picture

In IRC webchick and I came up with the following possible approach:

1. Welcome message is the first node created, with nid = 1.
2. As long as it exists, this node is displayed as an override of whatever is set as site_frontpage. The home page is node/1.
3. When user is ready, she/he follows a link to delete the welcome page. Then site_frontpage works as normal (there is no longer a node/1).

We would remove the special welcome page case altogether from node.module. We'd need a fallback when there are no promoted nodes to display. Maybe a message, 'no promoted posts'. Maybe a list of most-recent posts.

Some advantages:
* Works whatever is set by the profile as the site_frontpage. No need for special handling in each different module.
* No chance of message reappearing unexpectedly.

Eaton, others, what do you think of this approach?

nedjo’s picture

FileSize
11.54 KB

The idea of creating a first node had the problem of needing to test for it every time we generate a link to the home page.

Here's a new patch that uses a variable, 'welcome_message'. If this is set - e.g., in a profilename_install() function - the home page displays that welcome message. The user can, when ready, click a link that deletes the welcome message, so the home page reverts to whatever is given in site_frontpage.

For /node, I've sketched in a message that there are no promoted posts, with links (for admins) to posting or administering content or setting a different front page.

I've not yet tested the default.profile _install part, but the rest of it seems to work.

killes@www.drop.org’s picture

Status: Needs review » Needs work

fails in node.module

sanketmedhi’s picture

Title: Make welcome message install-profile-specific » node.module fixed
FileSize
118.12 KB

I have updated this patch and the changes needed in node.module have been made.

I have tested it with a couple of different profiles and it works perfectly. Reviews are welcome.

I am just afraid we will have to patch it every time changes are made, in HEAD, to those files that need to be patched for this patch to work successfully.

sanketmedhi’s picture

Title: node.module fixed » Make welcome message install-profile-specific

This is just to change the issue topic back to what it was. Sorry! :P

sanketmedhi’s picture

Hello, please ignore my earlier patch. I goofed up somewhere. Thanks nedjo for pointing it out to me. Pardon this n00b. :-)

I am posting an updated version of the patch. It seems to be perfect, still I would request reviews from other developers.

Thanks.

webchick’s picture

Status: Needs work » Needs review

Marking back for review, based on sanket's comments. Will try and review myself too, soon. :)

kazim59’s picture

Sanket's patch had some problem with the block.module and node.module. This may be due to a reason that HEAD has changed these files. I'm posting the patch for latest HEAD revision.
I've reviewed the patch and its working just as it is expected.

sanketmedhi’s picture

Status: Needs review » Reviewed & tested by the community

I have reviewed Kazim's revision and think it is ready to be committed.

Ofcourse, it has to be checked just before its committed, as we can't say when something changes in HEAD and when we need to fix it again.

webchick’s picture

kazim, is there anyway you could roll your patch as:

cvs diff -up > welcome.patch

from the root directory? when I try to apply it, it can't find the files.

kazim59’s picture

Really don't know how to do this... I just edited Sanket's patch and changed parts that patch node.module & block.module...
One way is to apply the patches to my system... then run the diff commands again that compare the .orig files with the patched ones... will do when I find time..

For you the workaround is to run: patch < welcome_profiles_node_fix.patch.txt and then manually tell patch the location of the files. It gives an idea of the file to be patched when it asks 'File to patch:'.
I know this is bad but you can review the patch.

kazim59’s picture

Run patch < welcome_profile_node_fix.patch.txt, and manually tell the files' locations. patch gives you the name of the file it wants before asking "File to patch:".
I know its bad but you can review the patch atm.

kazim59’s picture

Run patch without using p option and tell the program location of the files manually. It gives the filename before it asks File to patch. I know its bad but at least you can review the patch for now.

Is there anyway to edit/delete the comment i made earlier? The comment text stopped where i had added a <

drumm’s picture

Status: Reviewed & tested by the community » Needs work

The set of links will probably be different for different welcome messages, so

+  $content = t(variable_get('welcome_message', ''), array('@drupal' => 'http://drupal.org/', '@register' => url('user/register'), '@admin' => url('admin'), '@config' => url('admin/settings'), '@modules' => url('admin/settings/modules'), '@download_modules' => 'http://drupal.org/project/modules', '@themes' => url('admin/build/themes'), '@download_themes' => 'http://drupal.org/project/themes', '@content' => url('node/add'), '@help' => url('admin/help'), '@handbook' => 'http://drupal.org/handbooks', '@forum' => 'http://drupal.org/forum', '@support' => 'http://drupal.org/support'));

should be next to where the message is actually set.

Since deleting the welcome message affects the site it needs to require POSTing, so must be a small form and button.

kazim59’s picture

Status: Needs work » Needs review
FileSize
11.61 KB

I am submitting a patch with this strategy.

The array of links that follows is generic. All profiles can use these variables in their welcome_message

array('@drupal' => 'http://drupal.org/', '@register' => url('user/register'), '@admin' => url('admin'), '@config' => url('admin/settings'), 
'@modules' => url('admin/settings/modules'), '@download_modules' => 'http://drupal.org/project/modules', '@themes' => 
url('admin/build/themes'), '@download_themes' => 'http://drupal.org/project/themes', '@content' => url('node/add'), '@help' => 
url('admin/help'), '@handbook' => 'http://drupal.org/handbooks', '@forum' => 'http://drupal.org/forum', '@support' => 
'http://drupal.org/support')

These links may change with Drupal versions, so defining this array in system.module is a good thing. A profile won't become outdated if default drupal links changed.

Optionally, the profile can set a variable called welcome_message_links to include any extra links (not availible above). This array will be merged to the array mentioned above.

variable_set('welcome_message_links', array('@morethemes' => 'http://www.mythemes.com');

Tell me if my approach is right (this is one of my first patches!). I've updated the patch for the latest checkout.

kazim59’s picture

FileSize
11.51 KB

Since we missed the code freeze deadline, patch couldn't be fixed. I've updated the patch. Its working perfectly

Sanket, if you are not able to apply the patch, use the strip option (-p1 p2 etc.)

webchick’s picture

Version: x.y.z » 6.x-dev
Status: Needs review » Needs work

Patch no longer applies. Would be a great feature to get in, though...

Gábor Hojtsy’s picture

I think a lot simpler patch would be, what chx suggested (here: http://groups.drupal.org/node/7043 (?)) that we basically move the welcome text to node/1 with a break tag at the end, so the full node is displayed on the default /node homepage. This is basically removable, it solves people seeing the welcome message if there are no nodes promoted. If the node is created from the default profile, any profile can create different "welcome nodes" (AKA sample content) just as well (not that they cannot do it now :).

nedjo’s picture

Likely we could make this proposed node/1 approach work, but it would need some thought and work. New users generally take awhile to get used to the ideas of promoting, demoting, and deleting content. The current behavior - that the welcome message disappears when a first node is promoted - at least has the feature of not requiring further user intervention to e.g. demote or delete the first node.

kkaefer’s picture

I am absolutely in favor of chx/Gábor's suggestion. This also solves the problem of seeing the welcome message when there is no visible content by chance. @nedjo: We can explain that this help text is a node in the node itself, for example: "If you want to remove this welcome message, <a href=".../delete">delete</a> or <a href=".../edit">edit</a> this post."

JirkaRybka’s picture

How would this play together with localization? For example the current Czech 5.x install already sets custom bits to the message just through it's translation as UI string.

Once the message become a node (which I think is a good idea), this would be no more possible. The install profile will probably then need to save the node translated (unless the whole content translation stuff is also there), based on the language selection. That might be a bit more code, especially if there are more languages in the profile.

Just wanted to draw attention to this part.

Gábor Hojtsy’s picture

The install profile already saves the default content types in the localization used for installation. This would be just the same. It does not require any more code, as it can be st()-ed nicely. Those, who localize can add / modify it through localization still.

JirkaRybka’s picture

Ah, yes... Now I see. Thanks for the additional info.

Pancho’s picture

Version: 6.x-dev » 7.x-dev

Moving feature requests to D7 queue.

Boris Mann’s picture

I agree that making this node/1 by default out of the box is the right way to do this. It immediately gives a "real" piece of content for users to experiment with - editing, deleting, adding menu items for, aliasing -- whatever.

Making it a "real" node / content type also gives us a ton of hooks to do interesting things with, as well as provides a template for other install profiles to add more "Default content".

Linking back to the issue that got me here:

#475596: [meta-issue] Fix the unholy abomination that is the welcome screen

webchick’s picture

Hm. I kind of disagree. node/1 is:

a) Visible to anonymous users. Anonymous users should not see instructions intended for administrators, and should not get 403 errors when they try and click links.

b) On the "your site" side not on the "your admin area" side. This repeatedly causes confusion during testing, since people don't understand what they're looking at.

Boris Mann’s picture

Webchick -- I hate to pull the "this is how WordPress does it" card, but .... this is how WordPress does it :P

Agree on anonymous -- so make it unpublished by default. It will display to UID 1, but not to anyone else.

And, again, where to put it is separate from the whole install profile thing. Some install profiles could make it public, and make half a dozen pieces of "default" content. Our thinking here is what will the D7 default install profile show.

Basically, I'd hate to special case this. The only other idea I have is that this is part of an upgraded help system, and the only special case is displaying it on the front page.

I'd actually still like to ship with "real" default content - an initial node of each content type that we ship with in default.

yoroy’s picture

Putting an actual node in there is a good idea, it challenges you to learn how to edit, delete it. Not sure if we improve the welcome page / getting started experience if we make it deletable though :-)

(subscribe!)

webchick’s picture

Now that #475596: [meta-issue] Fix the unholy abomination that is the welcome screen is in, the default front page is just a line that basically says "There isn't content yet. Add some." I think this is fine for the minimal install profile.

However, for the default install profile I agree that it'd be nice to have a node/1 to get people oriented.

webchick’s picture

Title: Make welcome message install-profile-specific » Add an initial "welcome" node in default install profile

Changing title to make it more appropriate.

As far as the content goes, the reason I didn't just move the old existing welcome message over is because that text is clearly admin-facing, and it clearly is in the domain of the help system: it's step by step instructions on how to build your Drupal website.

What we should do with this welcome text is make it user-facing, because everyone, including anonymous users, will see it.

We could make this some marketing spiel talking a bit about Drupal and what it can do. I dislike this for two reasons:

a) When Leisa installed Joomla! she was appalled by how the website made itself into a marketing platform for their software; she just wanted to get started, and was bombarded by advertising. I don't want that to be Drupal's default user experience.
b) It requires basically 100% of users who download and install Drupal to have to do the irritating step of deleting this default content which has no relevancy to their site.

Something that might be a bit more practical (and something that can be mirrored in contrib profiles as well), is some content that explains the features of the install profile and what a user can do to get started. There's a better chance that this would be useful content that could just be lightly edited for simple sites, rather than being an annoyance.

Of course, this requires us to figure out what's in the default install profile. Is there an issue for that yet?

Thoughts?

Boris Mann’s picture

Interesting concept, making it user facing help. We could walk admins through the steps of editing it and moving it to /help and in the Secondary links -- might be an interesting mini-tutorial to include in the help system.

Now, as to what the content actually is ... yep, relies on defining what is in the install profile. My outline for this is here: Community in a Box default install profile outline.

webchick’s picture

Status: Needs work » Postponed

Wow, "Community in a Box" is really great. We should really push #391330: File Field for Core so that we can do "photo gallery" as one of our things. That would be tremendous.

I think this issue is pretty clearly postponed for now on getting the default profile in order. Boris, how about start an issue so we can start getting some code around this?

Boris Mann’s picture

yoroy’s picture

Status: Postponed » Active
Issue tags: +Usability

Can we still consider just the inital welcome node without opening up the whole productoutofbox debate? Would be great to have something show up in the 'recent content' block on the dashboard.

It's a common pattern, there's always 1 new unread message in the inbox of your latest favorite web service (gmail, linkedin, fb, whatever).

webchick’s picture

Hm. If this is done by the end of this week (12/12), I think we can make a small exception. That doesn't allow a lot of time for bike-shedding at all though (by design), so let's get on this fast. I also will not be real available this week at all for helping, as I'll be at Do It With Drupal. I defer to the UX and documentation teams for the contents of this page.

About the contents: one of the problems with the previous "welcome" screen was that it contained instructions only intended for site administrators, yet showed up for all site visitors, and the same is true of this node. However, you could argue that the previous situation was especially problematic because it was "hard-coded" and didn't go away until you posted your first piece of promoted-to-front-page content, where this one people could delete after they were done with it.

The alternative is making it a billboard for Drupal kinda like Joomla! does, but I prefer substance over flash. Wouldn't hurt though to canvas some of our "competitors" and see what they do, so we can try and gauge what our users would expect.

And while this probably goes without saying, this would only be done in default.profile, not expert.

amc’s picture

Version: 7.x-dev » 8.x-dev

Per #49.

mcrittenden’s picture

Sub.

yoroy’s picture

This is what joomla and wp do:

Joomla

Welcome to Joomla!

Written by Administrator
Thursday, 12 October 2006 10:00
Joomla! is a free open source framework and content publishing system designed for quickly creating highly interactive multi-language Web sites, online communities, media portals, blogs and eCommerce applications.

Joomla! LogoJoomla! provides an easy-to-use graphical user interface that simplifies the management and publishing of large volumes of content including HTML, documents, and rich media. Joomla! is used by organisations of all sizes for Public Web sites, Intranets, and Extranets and is supported by a community of thousands of users.
With a fully documented library of developer resources, Joomla! allows the customisation of every aspect of a Web site including presentation, layout, administration, and the rapid integration with third-party applications.

Joomla! has a rich heritage and has been crowned CMS king many times over. Now with more power under the hood, Joomla! is shifting gear and provides developer power while making the user experience all the more friendly. For those who always wanted increased extensibility, Joomla! 1.5 can make this happen.

A new framework, ground-up refactoring, and a highly-active development team brings the excitement of 'the next generation CMS' to your fingertips. Whether you are a systems architect or a complete 'noob' Joomla! can take you to the next level of content delivery. 'More than a CMS' is something we have been playing with as a catchcry because the new Joomla! API has such incredible power and flexibility, you are free to take whatever direction your creative mind takes you and Joomla! can help you get there so much more easily than ever before.

Thinking Web publishing? Think Joomla!

================

Wordpress.com

__
1 Post:

Hello world!
Welcome to Wordpress.com. This is your first post. Edit or delete it and start blogging!

__
1 Page:

About

This is an example of a WordPress page, you could edit this to put information about yourself or your site so readers know where you are coming from. You can create as many pages like this one or sub-pages as you like and manage all of your content inside of WordPress.

__
1 Comment:

Mr WordPress Says:
December 9, 2009 at 1:47 pm | Reply edit

Hi, this is a comment.
To delete a comment, just log in, and view the posts’ comments, there you will have the option to edit or delete them.

JohnAlbin’s picture

Title: Add an initial "welcome" node in default install profile » Add a "sample content" install profile
Version: 8.x-dev » 7.x-dev
Assigned: nedjo » Unassigned
FileSize
15.4 KB

I hope people don't mind me slightly hijacking this issue. I was going to create a new issue, but thought this was sufficiently similar.

Also, I know this is way, way, waygoogolplex late, but I'm going to temporarily bump down to 7.x.

Looking at Bartik's spartan appearance on initial install. And at the problems with new users not understanding how things work when given a completely blank slate. Why not do something similar to what Joomla has with its "install with sample content" option?

Underneath our current "Standard" profile, add a "Standard with Sample Content" profile, like this:

A couple notes:

sample nodes
We should definitely avoid the "wall of text" in our sample content. Brief descriptions with optional links to handbook pages are the way to go. Perhaps only the most recent 3-5 nodes should be helpful text with the rest being lorem ipsum placement copy.
sample blocks
We should fill out the regions in Bartik to show off its typography, Triptych and footer region styling. We could even have an aggregator link that pulls in something like Planet Drupal.
more samples
sample taxonomy, sample comments, sample menu items. But let's not go overboard, we haven't much any time.
configuration
IMO, the new install profile should have the exact same configuration as the Standard profile. Can we inherit from it? We don't want users to re-install using the Standard profile and wonder why the config has changed on them. This new profile should only differ from the Standard profile by the content it adds.
yoroy’s picture

Thanks John. I think I'd prefer the wordpress approach of adding an item for each content type and a comment. Focus on the content creator, get people to their own first 'Hello world' post. Adding blocks? Not sure. Jen had a theme setting sometime which showed sample content in the footer/tryptich regions, that got removed. There already is a 'tags' vocabulary for Articles.

I would suggest:
1 page with a primary menu item
1 article with 1 comment

Does it need it's own install profile then? Adding another choice in the installer just for this bit is overkill imo.

JohnAlbin’s picture

Adding blocks? Not sure. Jen had a theme setting sometime which showed sample content in the footer/tryptich regions, that got removed.

Yeah, I wrote that bit. It got removed because it was a Bartik-only theme setting and webchick said it was confusing that not all themes had this option. We do need to have Drupal's default theme look good when its installed for the first time by a new user and adding blocks to Bartik is essential to meet that goal.

Does it need it's own install profile then? Adding another choice in the installer just for this bit is overkill imo.

Yes, it does need to be a separate install profile. If we simply add sample content (even just a couple nodes) to our Standard profile, people will get tired of deleting (or forget to delete) that content every time they install Drupal. And using the Minimal profile is not an option because you are missing all configuration that is in Standard that is not in Minimal. We want to avoid the problem described in this Joomla article: “To install Joomla sample content or not to install sample content. That is the question.

Here's a screenshot of what happens when you go to "add new content" after installing with the Minimal profile:

That's a no-go for anybody except for very advanced Drupal site builders.

eaton’s picture

I spent some time thinking about this, and I believe the "clear distinction in purpose" is really important. We've managed to carve out a meaningful distinction between the 'Minimal' and 'Standard' profile, but that's only because 'Standard' means 'What we're used to.' I'd like to propose the following:

  • Standard: Drupal as we're used to it. A reasonable subset of modules enabled, Article and Static Page content types created, image fields attached, Bartik theme enabled, and so on. I wouldn't mind seeing a single node of each content type, with a single comment on the Article, be part of this standard install profile; Wordpress has demonstrated that people "get" editing a single piece of content that is obviously intended as a placeholder.
  • Minimal: No optional modules enabled, just Drupal and what it absolutely requires to run. I'd like to see the Stark theme used as the default theme, but that's probably overkill.
  • Demo site: A reasonable quantity of demo content, including articles with and without images, enough nodes on the front page to trigger the pager, blocks, poll module activated with a semi-populated sample poll, forums activated, and a number of pages with explicit path aliases mapped to the main menu. In a nutshell? An actual demo site that someone new to Drupal can look at.

I'm not sure whether this will get buy-in, but I think that it would help quite a bit. in the future, I'd like to see actual purpose-specific install profiles (Community collaboration, multi-user blog, etc.), with the option to generate sample content that is profile-appropriate. But if we do create a Demo profile, I think distinguishing it from our Standard profile is important. If it feels like the 'Demo' is designed to give people a jump start on building their sites rather than showing what an actual configured site COULD be like, I fear that Demo and Standard will simply battle it out for the "What to use when installing a new site" position.

webchick’s picture

One way that I've seen this handled in other projects is a checkbox during the installation process that says "Populate with sample content." I know we've been trying to get rid of checkboxes during installation, but this seems an alternative to making this its own entire install profile, whose changes need to get synchronized whenever we make changes to Standard. Bleh.

I'm nervous about "Demo site" because of where we're at in the release cycle. Boris Mann tried for the better part of the past 3+ years, as far as I know, to define what "Demo site" should look like, and we've never managed to figure it out. It sounds like a great goal for D8 though.

Bojhan’s picture

Aren't we only adding 1 page with 1 menu link? Why do we need a whole separate profile for that? I feel we might be over thinking this and creating expectations that are misguided for both us and the actual users, since you won't get a lot of demo configured stuff - no you get 1 page, a test page even.

eaton’s picture

I'm nervous about "Demo site" because of where we're at in the release cycle. Boris Mann tried for the better part of the past 3+ years, as far as I know, to define what "Demo site" should look like, and we've never managed to figure it out. It sounds like a great goal for D8 though.

Agreed. The idea of the 'demo site' is out of scope for D7, and to some extent I regret muddying the waters, but I think it could help clarify where the boundaries are.

Although we ARE trying to get away from too many options, 'populate with demo content' feels like a good way to differentiate between the configuration work that an install profile does, like installing modules and changing themes, from the example work that a profile might do.

Boris Mann’s picture

Title: Add a "sample content" install profile » Add sample content to standard install profile

@webchick: technically, rather than never figuring it out, next to no one engaged with me in trying to figure it out. Also, I definitely was never trying to make "demo" content, rather a Standard that does something, which would include one content type of each type.

@eaton: as always, +1 million to "actual purpose-specific install profiles", but we're reading from the same song book here.

I actually think that Standard with one piece of each type of content does make sense -- one of each content type, one with a comment. We have some blocks turned on already.

@John Albin: aggregator is not turned on by default. Pulling in Drupal Planet and having it show just on admin pages would be amazing. Don't think the CRUD functions are there to add feeds programmatically.

Changing title: Standard with demo content doesn't make sense.

And, honestly, all this needs is a patch to default.profile to get something that can actually be discussed. See Scott Hadfield's post about how he does default content for Wedful.com »

jensimmons’s picture

sub

dodorama’s picture

It'd be great to see a patch. And let's not forget that sample content must be localized somehow ...

yoroy’s picture

Version: 7.x-dev » 8.x-dev

"Hello world!

This is a test article, especially for you. It even has a link in the main navigation there. Amazing."

Something like this? :)

yoroy’s picture

Where do I find instructions for adding this to the install profile?

yoroy’s picture

Priority: Normal » Major

Ba-dump

yoroy’s picture

I'm not smart enough to deduce from other distributions' .make, .profile, .info files how it's done.

How is it done?

bojanz’s picture

In Kickstart v2, the custom Kickstart modules (Product, Blog, Slideshow) each have an import directory that contains a CSV file, a Migrate class, and any images used.
During installation, based on the user's selections (demo content: yes / no, blog: yes / no, etc), the appropriate modules are enabled (which makes their migrations available), and then a batch process runs all available migrations 1 by 1 which does the actually import.

yoroy’s picture

Thanks. Next question would be what's feasible for core. [#701974 ] maybe?

nedjo’s picture

@Yoroy, Re "how is it done", there's no standard here. The Apps module includes a generic concept of "default content" that apps can provide.

Some of the options people seem to be trying or using:

  • Manually create nodes, taxonomy, menus, etc and track their individual ids to that they can be removed later.
  • Use Feeds to import/export content from included data files (see: Ideation app).
  • Use Default Content to give nodes machine names and export them with Features. This is used I think in a number of distros.
  • Use UUID Features to export content into Features for inclusion.
  • Use Node export to export content into Features for inclusion.
  • Use Migrate to import content from e.g. CSV files, as is done in Commerce Kickstart.
yoroy’s picture

Excellent, thanks for that breakdown.

mitchell’s picture

Component: node system » entity system
Issue tags: +snowman, +, +Platform Initiative

Building on #69:

  • Add entities as plugins functionality (discussed in #drupal-scotch)
  • Use actions api to bulk create entities from config data
  • Add an entity/field storage driver for yaml, xml, csv, or any structured document type (partially mentioned in #1833872: Allow ConfigEntity types to be fieldable)

The field storage driver method is nice because content stays in the appropriate data format, and works natively with Drupal. It also doesn't require an import job over the entire data set.

An example of this this document oriented field storage driver is in Salsa Entity. Also related are: http://thinkshout.com/blog/2012/11/lev/salesforce-rest-oauth (I think) and another article on the planet ~Oct 27, 2012.

Berdir’s picture

Version: 8.x-dev » 9.x-dev

I don't think this is 8.x material anymore. I also don't think this issue is about the entity system, there might be entity system issues/changes to make it possible but the issue as a whole isn't. But not sure where to move it instead, so leaving for now.

eaton’s picture

Version: 9.x-dev » 8.x-dev

I don't think this is 8.x material anymore. I also don't think this issue is about the entity system, there might be entity system issues/changes to make it possible but the issue as a whole isn't. But not sure where to move it instead, so leaving for now.

I think moving it out of 8.x is premature, given how much is still in flux. The proposed inclusion of Migrate in core, for example, would pull the lion's share of this work along for the ride. Perhaps we can keep an eye on it and see how it shapes up as the other late-cycle initiatives approach completion?

Gábor Hojtsy’s picture

Component: entity system » install system
Xano’s picture

larowlan’s picture

fwiw I'd been working on this as part of a snowman install profile and had something working with json+hal files and the REST serializers, which I was planning on porting to use YML once I had a working concept. But haven't looked at it for a couple of weeks.

larowlan’s picture

Note https://github.com/larowlan/default_content is what I've done so far

mitokens’s picture

mitokens’s picture

jhedstrom’s picture

Version: 8.0.x-dev » 8.1.x-dev

Feature request => 8.1.x.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

yoroy’s picture

Issue tags: +ux-workflow

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

webchick’s picture

Just a note here that we discussed this general problem space in last week's UX meeting and are aiming to dust this initiative off again for 8.3. http://yoroy.com/pieces/getting-something-box

larowlan’s picture

FWIW drupal.org/project/default_content is powering this nicely in profiles like agov and others. I have some further ideas about how we should tackle this, I'll write them up and share here.

YesCT’s picture

the d8mi demo also has content.

https://www.drupal.org/project/multilingual_demo

jibran’s picture

> the d8mi demo also has content.
Yeah, it is using direct csv imports to create content and not the D8 serializer and deserializer.

eojthebrave’s picture

For the Drupal 8 User Guide* (https://www.drupal.org/project/user_guide) we decided to have some sample content, and provide a scenario that people could follow throughout the guide. We ended up deciding to go the route of a website for a farmer's market. You can read a bit more about it here https://userguide_new-drupal.dev.devdrupal.org/d8guide/en/preface-scenar... (drupal/drupal).

It has ended up working out really well in allowing us to write about, and demonstrate much of the functionality of Drupal core. Including; Views, data modeling with fields and relationships, using image styles, workflows, roles and permissions.

Might be pretty cool if the example provided with core mirrors the documentation that many people are going to be reading when first starting out with Drupal 8.

* The user guide is still a work-in-progress but it's nearing completion and will likely be included on Drupal.org in the very near future.

yoroy’s picture

This is the sample scenario from the user guide (https://www.drupal.org/project/user_guide)

You are making a website for a farmers market. The site needs to display information about the location and hours of the market, and an About page with the history of the market. It also needs to list the vendors. Vendors should be able to edit their listings (including a logo or photo), and post recipes. Site visitors should be able to browse recipes, or locate recipes using ingredients that they purchased at the market. Some visitors to your site speak another language, so the main pages and vendor pages need to be translated.

sylus’s picture

Migrate is in core and is has worked for both D7 + D8 as a way to get sample content / media etc into Drupal. Is there an added benefit of converting this to a json file and leveraging that system instead to get default content in? Would also provide another example of a best practice. I have used it to great success for an distribution leveraging json as a rest resource that is then parsed by migrate. This would scale should more content be needed to be added down the line.

yoroy’s picture

Category: Feature request » Plan
Issue tags: +Drupal core ideas
yoroy’s picture

We discussed this during today's UX meeting: https://youtu.be/vRNPFs9fISk?t=23m18s

@larowlan posted https://www.previousnext.com.au/blog/we-could-add-default-content-drupal.... There's an important distinction to make between 'adding sample content to core' and 'adding a tool that allows you to add your sample content to your install profile'.

The ux job here is to figure out how and which sample content can help smoothen the D8 onboarding process. To that end, I called out @eojthebrave's suggestion above to work with the Farmer's market model that's used in the user guide. And…

We think that's a great idea! :-)

Lets flesh out some more what it would mean to add sample content that matches the scenarios in the user guide.

Are any user guide authors coming to Dublin per chance?

larowlan’s picture

+1000 for the farmers market model - an actual product

ressa’s picture

I agree with @sylus' suggestion of using Migrate to import the default content from json-files - as he says, also to serve as an example of best practice in terms of migrating content.

dsnopek’s picture

Panopoly 2.0 in D8 is still -alpha, but it's using Migrate to import the default content. It's not using JSON, though, just the 'embedded_data' plugin so it's all in the YAML definition of the migration.

Here's an example:

http://cgit.drupalcode.org/panopoly_demo/tree/migrations/panopoly_demo_n...

Personally, I like using YAML better than JSON because then it's all baked into a single file, rather than having YAML to define the migration and JSON for the data.

dawehner’s picture

default_content serves the usecase of supporting any kind of content, which includes files, any kind of entity references etc. For some example content IMHO its enough to just have some specific subset supported, but I think migrate is totally a valid solution, sadly migrate is experimental by default. We could though maybe leverage it by installing it during the install profile and uninstall afterwards.

webchick’s picture

Project: Drupal core » Drupal core ideas
Version: 8.3.x-dev »
Component: install system » Idea

Moving this to the new Drupal core Ideas queue while we get this into shape.

eojthebrave’s picture

@yoroy, I'll be in Dublin, and would be happy to chat about/help with this in any way that I can. FWIW, the farmers market idea was also inspired by one of the early Snowman R&D suggestions. https://groups.drupal.org/node/134059

yoroy’s picture

@eojthebrave: great! Best would be to join the sample content meeting: https://groups.drupal.org/node/514005 contact @tkoleary for an invite, 'm sure you're most welcome :-)

ressa’s picture

Thanks for the link @dsnopek! It is a very elegant way of importing default content. I have attached my rewrite, into a more generic example.

rachel_norfolk’s picture

I ended up in a three way conversation with Ifrik and Realityloop during the Mentor thank you dinner at DrupalCon in Dublin on this and a number of other potentially related subjects.

Whilst I want to work on more detail around this, out conversation largely resolved around the idea of a “Learn Drupal” profile that didn’t include content per se but used migrate to pull down content that would form an “example module for the site builder”. This would include up to date copies of some/much/all of the new core Drupal documentation pages, event information for things like DrupalCon and other camps from Drupical, etc.

By migrating on the fly during install, we get the advantages of..

  1. Being able to update the content on d.o without needing to wait for core releases
  2. Introducing people to the community aspects of Drupal - the thing we know to be so special
  3. Providing example migrate scripts, event layouts, documentation pages etc to be styled by a new fancy theme.

We already have precedent for downloading on the fly during install through pulling down languages and that has proven to be effective.

Gábor Hojtsy’s picture

Component: Idea » Plan

This is being planned although the plan is not posted above.

andypost’s picture

I see no reason to involve migrate for default content

- migrate is experimental beta https://groups.drupal.org/node/515916
- default content is fixtures and not the real content, so no reason to maintain/track its changes
- YAML has not clear issue with binary data #2829919: Either avoid or explicitly test binary encoding in default configuration

andypost’s picture

kjay’s picture

Title: Add sample content to standard install profile » Add example content to the experimental out-of-the-box demo install profile
Issue summary: View changes
yoroy’s picture

Component: Plan » Proposed Plan

Status update from yesterday's UX meeting: https://youtu.be/PAvTyNPkw7k?t=38m49s All looking good!

Would be good to break up the content production tasks. We'll need to produce quite a bit of it so looks like a good place to open this up for others to contribute.

yoroy’s picture

Issue summary: View changes
FileSize
199.4 KB

Adding the (minimal) sitemap to the issue summary.