The body field on the Basic Page content type should not allow a summary to be input

@Shai
I'm not understanding this part

On the support side of things, when people are confused with the full text with summary UI we could point them to the Page content type and easily show them an example of a different solution that might get them what they want with a simpler UI. It's a lot easier to tell people, "Go to node/add/page" then it is to give them instructions on adding a new content-type and adding a field.

This would be if it's left as it is? Or you saying when they ask about the Article content type and are confused?

I do however agree that the Page content type should just include the long text. As the use case (hope I'm using this term properly) is as a "static page" versus a content type where the summary is necessary.

Sorry,but this seems by design? A page has no need for a summary.

Makes sense to me.

I was going to write that since these are actually two separate field types, and the node module still has some special handling for the body field (which is the "long text with summary" type), this might actually get a bit tricky, since essentially Basic Page wouldn't even have a "real" body anymore.

However, I also just noticed that within "long text with summary", there is a widget option to hide display of the summary textarea. So that might be another possibility - to use the same underlying field type for both, but do not configure pages to show that the summary on the node edit form.

I'm not sure where it is in the code (probably in a few places), but see the attached screenshot.

That "body field label" section is a carryover from Drupal 6, and it still works as described - just now, it is hardcoded to work with that particular field, at least as far as I remember.

I don't remember the exact history, but I think it may have just been an attempt to keep the "convert body to a field" patch down to a minimum size without ripping apart the UI as well - it was kind of a monster patch :)

No, I don't think it would be hard at all - I was just wondering about the user experience of shipping with a content type that had something kind of like the body field, but wasn't actually the same field that is special-cased in the UI, so the controls wouldn't work for it.

However, I just found out that there is ongoing work at #553306: Make nodes have no body field by default. Remove deprecated APIs for body field to get rid of the node body special case altogether, in which case that problem would go away completely!

marking as duplicate of http://drupal.org/node/553306

Nothing is actually broken here so it is a task

#1378350: Clean up the "Long text and summary" field will work nicely with this.

I started a duplicate #1396170: Change the default body formatter for Page content type from 'long text and summary to 'long text' which should be handled here:

From http://drupal.org/node/1378350#comment-5436402

Providing long text and summary as the default is very much forcing things upon people, especially in the initial evaluation phase. 'You can delete it if you don't need it' is not a viable answer if most of the times that's what people should be doing anyway.

From http://drupal.org/node/1378350#comment-5436484

More specifically, the Standard profile sets up the Article and Basic page content types. Both get a Body field of type text_with_summary.

Now, for the Basic page content type, the summary is pretty much pointless, since the use-case of a Basic page content is to only appear on a page on its own (commonly accessed through an associated menu link), but not in node listings.

Thus, it would make sense to change the field type on the Basic page content type.

Kick-starting this.

Not particularly pretty, but getting the job done.

Apparently, Node module (or rather the entire system) still has a pretty hard dependency on a 'body' field on nodes. Therefore, the actual field type has to remain the same, and we only adjust the widget + formatter.

err, what? The last thing I expected was #17 to pass tests. ;)

The patch in #17 implements what @yoroy quoted in #16; i.e.:

It removes the summary [widget] for the Basic page content type. (but also for book pages and forum posts)

Oke, sounds good.

Also fixed the weird upper-casing of everything in the title.

The patch in #17 looks good to me.

@@ -589,7 +592,7 @@ function node_add_body_field($type, $label = 'Body') {
         ),
         'teaser' => array(
           'label' => 'hidden',
-          'type' => 'text_summary_or_trimmed',
+          'type' => $widget == 'text_textarea_with_summary' ? 'text_summary_or_trimmed' : 'text_trimmed',

This is the only part that seems like it may be a bit confusing. I see what is happening here, but think that it could use a comment to explain the conditional statement.

Regarding @Everett Zufelt's example in #21, I think the code would be a little more clear if we wrapped the condition
($widget == 'text_textarea_with_summary') in parens.

> Apparently, Node module (or rather the entire system) still has a pretty hard dependency on a 'body' field on nodes.
We might want to revise this. However, even w/o teaser it still is a 'body' field, so it's rather a good thing to treat it 1:1 the same way.

> Therefore, the actual field type has to remain the same, and we only adjust the widget + formatter.
Even this is a good thing, cause it should easily allow change widget and formatter if folks do want the teaser vice versa. Regarding the user experience, that's exactly the behaviour escoles and yoroy called for in #1378350: Clean up the "Long text and summary" field.

Plus:
- a bit more of obvious differentiation between 'article' and 'page' helps explaining the existence of these different node types to new users.
- it is a built-in nice simple demonstration about field types, widgets and formatters, flattening the learning curve.

'Should' in issue titles is not productive :)

Needs work as per #21 and #22, adding Novice tag for that

Wrapped the ternary statement with parens per #22, re-rolled patch

#25: long_text_for_page_ct-626546-5447656.patch queued for re-testing.

re-roll based on recent Drupal8 changes

I think this makes sense. My only question is why we're not making the default widget text_textarea and special-casing article, rather than (right now) special-casing everything else. I guess it comes down to whether a new custom node type should provide a summary or not by default.

In either case, let's have someone test the patch manually and confirm the results for page, article, book, and forum nodes.

We also should add to the node.module tests covering this functionality. As sun alludes, the fact that the patch didn't fail any tests implies some missing coverage. At the least we want a unit test for node_add_body_field(), but it might also be good to add some functional test coverage as well. Do we want to codify the kind of body found on the node types that ship with core?

Also, let's find or file a followup for:

Apparently, Node module (or rather the entire system) still has a pretty hard dependency on a 'body' field on nodes. Therefore, the actual field type has to remain the same, and we only adjust the widget + formatter.

#28: 626546.patch queued for re-testing.

http://core.drupalofficehours.org/task/1036
After seeing this, I felt that this "task" still needs work. Anyways, i will test it manually myself once again and report the results here.

#28: 626546.patch queued for re-testing.

And the patch #28 needs to be re-rolled as well.

Before applying the re-rolled patch:
This is what we had(screenshots attached). The "Field Type" was "Long text and summary" by default for Basic Page. And the "Widget" was "Text area with summary".
After applying the rerolled patch:
This is what we have(screenshots attached). The "Field Type" is "long text and summary" and "Widget" has now changed to Text area(multiple rows) for Basic Page.
Is this what we want? Or, are we looking to change default value for "Field Type" as well?
"Create Basic Page" is still the way it looked earlier(screenshots attached).

Patch re-rolled in view of current changes in Drupal 8 core.

+++ b/core/modules/book/book.installundefined
@@ -40,7 +40,7 @@ function _book_install_type_create() {
-  node_type_save($book_node_type);

Why is this removed? I think you meant to remove the node_add_body_field call instead

+++ b/core/modules/node/node.moduleundefined
@@ -578,7 +581,7 @@ function node_add_body_field($type, $label = 'Body') {
+        'type' => ($widget == 'text_textarea_with_summary') ? 'text_summary_or_trimmed' : 'text_trimmed',

So this sets the correct formatter but I can't see anywhere that the widget type is set in this diff.

Regarding #35, there might be a bug in the server-side PHP or perhaps also client-side JS code for the summary handling. If the widget isn't "_with_summary", then the summary thingie shouldn't appear in the UI.

That said, did you re-install before testing?

Speaking of tests, we're still missing a test assertion for this. Should be dead simple to do:

// Verify that the Body field widget of the Basic page content type
// does not use a summary widget.
$this->drupalLogin($this->root_user);
$this->drupalGet('node/add/page');
$this->assertNoText(t('Edit summary'));

These lines should be added to core/profiles/standard/lib/Drupal/standard/Tests/StandardTest.php

Just a general little cheer in support of working on this issue: "Yay, thanks for working on this issue rkjha!".

@sun: yeah, i did a fresh installation before testing. i do that every time.
Rerolled patch attached. Hope I have not done something wrong again.

@sun: even after applying the patch, the summary thing still appears in the UI. And this is not only with me. Have a look at this http://core.drupalofficehours.org/task/1036.

Added the tests as suggested by @sun
Lets see if this patch passes tests

+++ b/core/profiles/standard/lib/Drupal/standard/Tests/StandardTest.php
@@ -32,6 +32,11 @@ function testStandard() {
+    $this->assertNoText(t('Edit summary'));

Ouch, I'm sorry... this text doesn't actually appear in the markup that is generated on the server-side — it's injected via JS only, and the automated tests do not execute JS.

Can you replace this line with this one?

$this->assertNoRaw('text-summary');

Changes made to test as suggested in #45.

According to what I have observed on testing it manually, it should not pass the test. Lets wait and see.

The problem is that node_add_body_field uses the 'text_with_summary' field type for the Body field. This should be simply 'text_long' in the case of the page node type. So you either need to add an additional parameter for the field type, or you simply add a single $summary parameter which controls both the field type and the widget. What currently happens with the patch is that because the 'text_textarea' widget is not applicable to fields of field type 'text_with_summary' it is dismissed upon saving and the default ('text_textarea_with_summary') gets taken over. It is strange that there is no notice/exception when doing that, but that's not for this issue.

1) At least we have working test coverage now :)

2) We cannot use a different field type, because the $node->body field can only have one field type, and there can only be one field with the name "body".

So... essentially, we need to make that widget work with the existing text_with_summary field type. I'd say, just ignore the summary value in the widget?

I.e.: Let's see what happens if we change the "field_types" definition in the annotation of Drupal\text\Plugin\field\widget\TextareaWidget to additionally list text_with_summary? @rkjha, can you try that?

@tstoeckler: i tried changing that, but only to get strange results.
@sun: sure, i will. i think i need some more clarification, i'll ask for the same as soon as i am back to this work(maybe tomorrow).

Helping you out until then :)

@sun: I am unable to figure out what difference would the addition of "text_with_summary" in "field_types" make?

Instead of using the widget name as the second argument, can we instead use a '$summary' boolean flag as eluded by @tstoeckler at #48
If $summary = TRUE, set the widget and field type accordingly, if $summary = FALSE, use the text_long, text_textarea type/widget.

@rjkha, something like https://gist.github.com/4589799 is what I'm taking about

As explained above that seems to cause additional problems. I assume there is lots of code around that assumes that $node->body is the 'text_with_summary' field type, so that I can do $node->body['und'][0]['summary'] and it works. In the long run, we should fix that in the one or the other way, but for now I think we have to stick with the existing field type.

#51: drupal8.node-page-body.51.patch queued for re-testing.

When node moves to EntityNG $node->body['und'][0]['summary'] will be gone and I don't think we should baby-sit anything that does that at the moment. What happens if $node->body doesn't exist? Surely code like that is only in tests.

Code-wise, #51 looks good to me.

Whether it goes against some unknown Do's and Don'ts of Field API, or whether it is horribly broken in the UI, because this edge-case isn't covered by the field widget's existing tests, I don't know. :)

Let's see what @yched has to say. :) In case he doesn't respond soon-ish, we can ask @swentel, too.

Also, some manual testing of the Basic page content type would be nice; i.e., creating, editing, deleting content, managing fields and displays, as well as deleting the content type.

Oh, and let's also test what happens if you change the widget to the summary widget, and you enter some nodes with a summary filled in, and then change it back to the widget without a summary, and see what happens — i.e., the previously entered summary value will most probably simply not appear in the edit form anymore. But it will be displayed when viewing the node. We should also test if the not-exposed summary value gets lost when submitting the edit form, or whether it is magically retained under the hood. :)

The patch has been tested manually. It is working fine, as expcted. There is no "Edit Summary" on the Basic Page content type.
Furtermore, on changing the widget to the summary widget, and entering some nodes with a summary filled in, and then changing it back to the widget without a summary, the previously entered summary value didn't appear in the edit form anymore. Also, the not-exposed summary value was retained.

Tentatively marking RTBC based on #59.

Agreed this could use review from yched or swentel. I can see the use case but I'm ambivalent on fixing it like this. Bumping back to CNR for a bit.

Showing the summary or not rather looks like a 'display_summary' widget setting for the 'textarea_with_summary' widget to me. As noted by @David_Rothstein a long time ago (#7), such a settings currently exists at the instance level, but it's only used by the 'textarea_with_summary' widget.

So ultimately I think the cleanest plan would be to simply merge both 'textarea' and 'texterea_with_summary' widget into a single one, that works on both 'text_long' and 'text_long_with_summary' field types, and with a 'display_summary' setting (hidden when it's used on a 'text_long' field).

Then, the extra param in node_add_body_field() becomes a boolean for the value of the 'display_summary' widget setting.

Thoughts ?

I agree and this is very similar to #1704864: Add a "Required" and "Show by default" option for "Text area with a summary" field/widget.

Re-rolled the latest patch.

The original patch is using the function st() which is no longer available in Drupal 8. So are we able to use t() at the point of install or would it still not be available?

If not, then what is the best solution now that st() has been removed?

Changed calls to st() function to the t() function.

The last patch is failing on undefined function node_type_set_defaults()

Looking into it.

I was going to rework the last patch, but the content type api has moved way past what is in that last patch.
Probably need some work by an experienced developer, so I would remove the Novice issue tag.

I believe this is all that's needed now? Just a change in the yml.

from the test results, looks like that display_summary has to be there.

re @skh and patches #72 / #75: this cannot work.

The "field_type" entry field.field.*.yml is only denormalized from field.storage.*.yml, for convenience and performance reasons.
It's the field_storage that defines the field type. Fields using that storage *have to* repeat the same 'field_type', or things will just break.

If we want "article Body" and "page Body" to be of different field types, then they can't be the same storage,and they need to have different field names, they can't be both 'body'. The "main content / body" field used for page would have to be its own separate, one-off field + storage, used by page only.

Not that it wouldn't make any sense at all, but that would be a non-minor change.
Which IIRC is why ealier discussions in this issue were focusing on just allowing an option in the widget to simply not show the "summary input UI".

Going all the way back to #7 we still don't need separate field types to accomplish the goal here...

Here's a reroll that just configures Basic pages to not use the summary field. I pulled in the test from #68 also, since that seemed useful (but modified it a bit to make it more robust). I did not pull in the other changes from that patch (in particular those which change the configuration for Book and Forum nodes); that may be a good idea also but it's out of scope for this issue, and this is an issue that has already gone way longer than it ever should have :) Followup issues would be good for those.

I applied Patch it work fine; added a option for Summary as "Summary or Trimmed" in admin/structure/types/manage/page/display , but there is no option in node/add/page for Summary.
Screenshot After Applied Patch ( admin/structure/types/manage/page/display ) :

Screenshot of Missing Field for Summary inbasic Page:

#78 makes sense to me. And thanks for the screenshots!

Tagging for a summary update and a beta evaluation since the current summary is very old. Since it's a normal task we should evaluate how it fits in the beta. I think it's potentially a usability improvement. (Also it seems like standard profile should be the component but I guess that's not in the component list. It's certainly not a change to the installer.)

Finally, this has some implications for Drupal-the-product since this affects a very end-user-facing, out-of-the-box interaction, so assigning to @webchick for product maintainer signoff.

Also, tagging for followup per #78.

Happy to take a look at this once the issue summary's updated and I know what I'm making a call on. :)

I am removing the Novice tag from this issue because this issue has become rather complicated and long for new contributors, as #70 pointed out. It took a while for myself to just read through and mostly understand.

If someone else wants to go through it and update the issue summary and do a beta evaluation feel free too, if not I'm making a note to come back and read through it carefully and get that done so @webchick can do what she does.

I’m using this documentation as a source: https://www.drupal.org/core-mentoring/novice-tasks#avoid

Here is my beta of the issue summary. I didn't review the patch.

+1, would love to see page summary go away.

I updated the issue summary as per #82.

This issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge require as a guide.

This was tagged for a followup per #81

Also tagging for framework review (not sure if that's the right one)

But the comment

Finally, this has some implications for Drupal-the-product since this affects a very end-user-facing, out-of-the-box interaction, so assigning to @webchick for product maintainer signoff.

Makes me think this need some kind of sign off approval after 8 years.

Yeah this is a product manager review issue, in so far as Standard is a product, which it is not