Remove body-trimming settings from content-type page and make it a field display handler
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | node system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | duplicate |
Jump to:
This is a proposal to remove auto post-trimming functionality from D7. (In D6 this was at admin/content/node-settings and in D7 it is at admin/structure/types/manage/ under the vertical tab "display settings.")
Automatic post trimming is duplicating maxlength field functionality. The maxlength field on the field creation page for the new "body" field is currently grayed out in order to accommodate incorporating the legacy post-trimming functionality. Grayed out fields are bad UI. Now that "Body" is a field like any other field, let's take advantage of that.
A huge advantage of this, if it happens, is that it will make the UI for the new "long text and summary" field much simpler. Get rid of that javascript, "edit summary", "hide summary". You have the "summary" and the "teaser" with full control for the user to create each one separately. And you can set maxlength on each one (they are separate fields in the db). Simple!
Shai
#1
In the last sentence, I meant... "You have the 'summary' and the 'full text' with full control for the user to create each one separately."
#2
First of all, this has nothing to do with smallcore? Secondly this is on the assumption, in really merely assumption that few people use the automatic post trimming functionality - to me that somewhat wierd. Although I agree we should research this more, since it creates a bad UI - I do not see this as a bug, nor as a critical feature to go into this last phase of Drupal 7.
#3
Different solution: the new longtext with teaser field, which the "body" field now employs should have two widgets instead of one. One widget would be the same as we have now, with the exception that the auto-trim controls would move from the content-type settings to this widget. The second widget would be as I had proposed. Seperate text areas for "summary" and "full text" with no JavaScript or automation, just the ability to set maxlength on both.
@bohjan, if Drupal is taking usability seriously, it would be crazy to rush things at this point. The developers have done an incredible job getting huge changes done under the hood, with fields probably being the biggest. Freeze is barely two weeks old. D.o reports that fewer than 500 installs of D7 are phoning home. Just six weeks ago D7 was pretty much unusable and isn't anything like it is now. This idea only came to me from actually interacting with a functioning D7. More people need to have really used D7 before we put this baby to bed.
What a waste to get fields in core but then not to bother leveraging it's elegance to solve a huge UI problem. The split summary at cursor nightmare, which Dries devoted like 10 minnutes to in Drupalcon Boston, is now only marginally better. Yet fields in core gives us the opportunity to actually fix it.
Dries specifically designed the process so that we could focus on UI stuff when there weren't going to be API changes. Now is not the time to drop big UI problems; it's the time to address them.
#4
Ok, so please provide a screenshot of your solution. Because I am puzzeld, what you want to solve now. Still don't see how this is a bug.
#5
I'll make the screenshot, tonight, EST
(GMT - 5:00).
The bug is the basic edit summary hide summary functionality on a standard node/add form. Pulling out the "cursor" from the equation and removing the "show summary in fulll view" are small improvements and in some ways make things worse. The assumption that auto-trimming was not negotiable and the fact that fields just got into core I think explains why movement on this problem has been so slow.
Now that fields are in core we can provide the legacy functionality via a field widget (maybe even restoring split-summary-at-cursor which is more robust than the current compromise) but also provide a JavaScript-less alternative where summary and full text map directly to separate non-dynamic text-areas which are not subject to auto-trimming.
In short, the bug is a UI bug relating to the teaser/full text relationship which has been vexing Drupal for a long time. Fields provide a way to solve the problem without losing anything.
Shai
#6
auto-trimming is done at display time, this has nothing to do with widgets (data input), but rather with formatters (data display).
There is a patch somewhere to remove the 'Length of trimmed posts' setting in the 'edit content type' form, and make this into a formatter setting instead.
But it is kind of blocked by the fact that field UI has no place for formatter settings right now.
+ I don't think this qualifies as a bug.
#7
@yched,
I'll look for that issue, thanks.
Wouldn't it be possible for the trimming possibilities to show up in the display fields section of the fields UI? Under "Teaser it would have choices like..., 'full text trimmed to 200 chars, full text trimmed to 400, etc. "Summary" would be another choice on that list.
Re: bug. Is there a definition somewhere of what constitutes a UI bug?
I'm curious to see that other issue, whether it is described as a bug. It's really confusing for the trimming settings to be on the content-type settings form when it applies to one field only, a field which can be deleted.
Shai
Shai
#8
I've changed the name a bit, set the category back to "bug" and marked it as a duplicate of:
http://drupal.org/node/504564
@yched, I presume that was the issue you are referring to, yes?
You wrote,
.
It seems like on the issue I referenced, people just ran out of steam... I didn't see any great barrier referenced there. But maybe I'm missing some other issues relevant to this.
Shai
#9
Yes, that's the issue.
Well, it currently uses a workaround for the fact that there's no UI for formatter settings...