| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | node system |
| Category: | feature request |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | productdesign, Usability |
Issue Summary
As we get more install profiles, we'll want them to have customized welcome messages. This patch suggests an approach. We:
* Move the existing welcome text from node.module to an include file, welcome.inc, in the default install profile's directory.
* Introduce a new method in install.inc, install_profile_invoke(), that allows us to load an include file in the installed profile's directory and call methods in that file. This way we can reuse the code for invoking install profile extras and avoid putting new, seldom-used code into node.module.
Future install profiles can customize their display by adding a welcome.inc file to their directories. If none is present for the installed profile, the default one will be used.
As an advantage, the welcome message could be called by modules other than node, in the case that an install profile sets a module other than node as the front page.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| install-profile-welcome.patch | 4.44 KB | Ignored: Check issue status. | None | None |
Comments
#1
And the new file for inclusion as profiles/default/welcome.inc (I haven't figured out how to get the diff -N option working....)
#2
Nice small patch!
Works as expected IMO..
Let's have someone else review/test this and get it in... :-)
#3
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.
#4
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?
#5
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.
#6
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 frommodule_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.
#7
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.
#8
@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:
<?phpfunction yourtheme_welcome_page() {
return t('Welcome to our spiffy distro...');
}
?>
or
<?phpfunction yourtheme_welcome_page() {
return t('No promoted content was found.');
}
?>
or even
<?phpfunction yourtheme_welcome_page() {
drupal_goto('node/23');
}
?>
(ok that one is a bit of a hack :P)
#9
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.
#10
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.
#11
@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?
#12
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:
<?php$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.
#13
Yes, I think so.
#14
@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:
<?phpfunction 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?
#15
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?
#16
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.
#17
fails in node.module
#18
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.
#19
This is just to change the issue topic back to what it was. Sorry! :P
#20
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.
#21
Marking back for review, based on sanket's comments. Will try and review myself too, soon. :)
#22
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.
#23
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.
#24
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.
#25
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.
#26
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.
#27
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 <
#28
The set of links will probably be different for different welcome messages, so
<?php+ $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.
#29
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
<?phparray('@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.
<?phpvariable_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.
#30
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.)
#31
Patch no longer applies. Would be a great feature to get in, though...
#32
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 :).
#33
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.
#34
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."#35
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.
#36
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.
#37
Ah, yes... Now I see. Thanks for the additional info.
#38
Moving feature requests to D7 queue.
#39
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
#40
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.
#41
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.
#42
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!)
#43
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.
#44
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?
#45
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.
#46
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?
#47
Done at #483987: Decide on direction for standard install profile
#48
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).
#49
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.
#50
Per #49.
#51
Sub.
#52
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.
#53
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:
muchany time.#54
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.
#55
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.
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.
#56
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:
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.
#57
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.
#58
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.
#59
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.
#60
@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 »
#61
sub
#62
It'd be great to see a patch. And let's not forget that sample content must be localized somehow ...
#63
"Hello world!
This is a test article, especially for you. It even has a link in the main navigation there. Amazing."
Something like this? :)
#64
Where do I find instructions for adding this to the install profile?
#65
Ba-dump