Add an initial "welcome" node in default install profile
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | node system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | nedjo |
| Status: | postponed |
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 | None | None |
#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 default install profile