Make 'node' empty text themable.

+ return($form); lose () and also lose drupal_get_form, just call the function and call drupal_render on it. This is not a form.

Agreed, this is a perfect use of the general Drupal Rendering API. I'd perfer that we use a properly nested structure, and a theme function, rather than the prefix and suffix elements. I'll roll a version of this later today if possible. As chx said, it's not really a form and there's no need to call it that.

Wouldn't a theme function be better than a form alter?

This can be really useful in install profiles.

Without actually using drupal_get_form (or the equivalent render function), form_alter can't be used hwich is the only reason to use the form system for this output.

I'm not sure the form system is necessary. Is there any reason not to just move the entire thing into the theme function?

I do realize that modules should be able to modify this, so perhaps we need to actually use drupal_get_form and use the form theme function instead, allowing the best of both worlds (modules adding information here; sites completely overriding it with whatever).

Or, alternately, we can use the drupal_alter() system proposed in http://drupal.org/node/110888 ... Unifying our structured rendering using FAPI-style arrays, and giving other modules ways to alter thee process, shouldn't force things into using forms when it doesn't make sense.

I'll reiterate, this isn't a form and I think treating it as such would be a mistake. I still think that a theming solution is a better approach, but a compromise would be to create the structure in a FAPI-style array, then call drupal_alter('welcome_page', $array). That allows modules to implement hook_welcome_page_alter().

The proposed implementation and code look good to me, but I would change 'node_page_default' to 'default_welcome_page' or something similar.

The name theme_node_page_default() is too ambiguous and it doesn't actually represent what this theme function does (at least not to a themer who might not be aware of why this page has anything to do with nodes).

No, the function name 'default_welcome_page' violates namespace rules.

Change it back to node_page_default or maybe node_welcome_page if you like, but it should be either node_* or drupal_* namespace.

@merlinofchaos, you're definitely right on the namespace rule, and I think that node_welcome_page gets us what we want both in terms of naming conventions and meaningfulness. Same patch as #14, but using "node_welcome_page".

Patch still applies, rerolled against head.

Sorry, I think this is a bug, not a feature. I just discovered this since someone asked in IRC how to customize this, and when I looked at the code, I was shocked to see raw HTML being generated in node.module. :( I searched and quickly found this issue. If the answer is "to customize, hack core", it's a bug, IMHO, and I'd support backporting to D6 and D5. "Just write your own module to occupy /node" is no excuse for node.module to be generating raw HTML itself...

theme_ function has no phpdoc comment.

IMO I'd rather have a template than a theme function here. But then, with a template I'd probably do away with the structure entirely.

But then again, we'd also like to change this to be a little more interactive at some point in the future, so maybe the structure is a good idea for that. This would be a nice place to pull up help documents and stuff in the future.

What if node_page_default() just does this? Change $_GET['q'] to the new page, loads the router item and executes the page callback? Maybe that's a little bit more complex than it ought to be. Maybe it could lead to a menu_execute_handler('path')...

does it really need all the +5 -5 #weights?

$message doesn't seem like the best name.. $content?

I think doing it as a template file would be best... the whole rendering via theme function seems really wonky.

Do we really want anonymous to be able to see anything at "admin/X/X"?

Also, I don't believe anonymous users need to see that information at all. We could set a simple redirect to "Getting started" page for the admins and devise something else for the anonymous or non-admins to see at the front page.

Marked #338772: Theme the Welcome Message as duplicate. This issue still exists.....

the whole welcome message should be outside of the node_page_default() function, and it needs to be accessible even after the site has a front page..

I would like to see this implemented as a Help page after issue #299050: Help System - Master Patch is fixed. I hope help pages can be accessed even the help module is disabled..

^^ then why would you need the help "module"? just for playing with toggle checkbox? probably not ;)

I don't understand your point. You can have a module and you can have an additional include file which works even the module is disabled. For example menus are still working after the menu module is disabled.

If you disable the help menu you can't search in the help or I don't know, you can have any functionality which is gone when the module is disabled and any functionality which works even the module is disabled..

So the welcome page should be a Help page and it should be accessible even the Help module is disabled as it needs to be displayed when.... Or maybe not, the front page could be empty when using the expert install profile. That also seems reasonable..

What's the usabilty side of this? Any specific changes you'd like comments on? This is a rather technical discussion, I can't really tell what this changes for the user? If someone could summarize what the actual change is here then yes please & thanks.

Ok, thanks. There are multiple ideas about how to improve the welcome page but indeed no consensus yet. Seems like this issue is not the place to start trying to do that.

@yoroy: Indeed. This issue is about making the code that generates the message a proper theme function so that sites can trivially change the text without hacking core. Changing the default text should definitely happen in a follow-up issue (patching core's default implementation of the new theme function), since it's very likely this issue will stall and die if a huge bikeshed argument breaks out in here. ;) Let's get the plumbing in place first, then we can worry about a new sink. ;) Thanks.

I have been working on #419950: Remove /node as default front page, which is related to this issue. It doesn't really modify the welcome message, but it removes the dependency on Node.module for the welcome page. Basically, it does the same as HEAD does now, but the welcome message is located in common.inc (it would be a shame to depend on the help system for this, especially since novices might log out, don't see the message anymore and wonder what to do next) and it is displayed if no front page has been set.

The attached patch merges this issue and #419950: Remove /node as default front page. It uses Drupal 7's page mechanism to display the page. Modules will be able to change the message using hook_page_alter(), removing the need for a custom hook. The only known problem is that blocks don't want to appear.

.

This patch needs to update Number of posts on main page at Administer > Content management > Post Settings.

subscribing

@mikey_p: Links?

Does this issue need to be renamed?

Because /node as the default front, and the behavior of the welcome info, are two different things to me...

This issue is indeed about something else than the welcome screen, although the patch updates the same functions. Also, here at drupal.org we never directly set issues to closed. We let the bot take care of that.

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

Wait a second, what's the scope of this issue? To just do some house cleaning in the default front page message?

Based on the description, this is a duplicate of #79582: Add example content to the experimental out-of-the-box demo install profile.

Based on the title, I would expect this to be about changing the default value for the front page that is set at admin/settings/site-information . I think that can already be done easily enough in a profile?

Should this now be titled "Display help landing page via Form API" or can we just modify that via hook_help now thanks to #475596: [meta-issue] Fix the unholy abomination that is the welcome screen?

This issue is about ripping the welcome screen out of Node.module. It doesn't care about what the welcome screen does, just about getting it our of a module it doesn't belong in, so that module can be made optional. Nothing more, nothing less.

The main point of this issue (now that the welcome text is in help where it belongs and not barfed out when no nodes exist) seems to be the ability to alter the content of the welcome message. If so, a theme function is completely the wrong approach. While you can (ab)use theme functions to add/remove content to a page:

a) A theme function's main purpose is to style content that already exists, not to fundamentally change said content.
b) It means that the helpful instructions you added are now tied to your theme. If someone switches to Garland for debugging, your wonderful help is now lost.

hook_page_alter() is the right tool for the job here. This issue looks like it predates the addition of this hook, so maybe that's where the ire is coming from.

Marking duplicate, unless someone has other things from this patch that need to be pulled out and worked on.

I agree with webchick on this one.

This is essentially the same patch as mikey_p's #43 but updated for the new strings.

graaar cross posted.

This looks good.

Should we use #access here rather than hard-code the permission check?

Could we focus on changing and theming the message elsewhere and just keep this issue for moving it out of Node.module?

Xano: The message is already out of node module. That's what #475596: [meta-issue] Fix the unholy abomination that is the welcome screen did. Please install HEAD and read the patch. :)

The current message that's being themed does belong in node.module because it needs to display something when the content list is empty.

*Oops* Thanks Angie!

Somebody should read from #69 down and asses if this still applies or close this again, I can't tell.

Is this issue here still relevant?

Is this issue here still relevant?

IMO, no. The new 'Node empty text' is a swappable views plugin, and a site builder can override it completely by customizing the front page View.

It didn't get fixed the way we expected, but it was fixed nevertheless!

Then this doesn't need to be fixed in 8.x and back-ported, it can just happen directly in D7. ;)

Here is a reroll of #71. When I tested it i realised that $message in the theme callback does not contain the 'message' part on the first level of the array, im not sure why. The way the $build array is compiled looks normal, so to work around this I had to add a dirty

$output = '<p>' . drupal_render($message['']['message']) . '</p>'; part into theme_node_page_default().