Add a field label token so rewrites are easier

I am having this problem as well.

Regarding that related issue knalstaaf, I believe I have seen this bug before but it was previously fixed, so I wouldn't worry about a forum post that is 1 year old.

I have found the same behavior (labels missing when rewriting) in 7.x-3.1. How come?

Same issue here. I think that if "display label" is checked, the label should be included in the rewrite token also by design...

I see the same problem... There is also a translation problem if the label must be added in the output field..

@knalstaaf: yep I'm sure, I haven't View Translation installed.

Marking this as a bug. I agree with #4, the token should include whatever the field is configured to output in the first place when rewriting. This is very frustrating.

The labels are not part of the field and are not intended to be. The style renders the field and label separately. In the vast majority of use cases, you do not want the label. If you do, you can rewrite the original field to include the label, or include the label as you like.

Take, for example, the 'table' style, where the labels appear only in the table header. The field itself has no real notion of what the style itself will be up to, so now you'd have to add intelligence to the field to know whether or not the style intends for the label to be nearby.

This is not a bug; this is the intended behavior, and will not be changed.

Fine, I'll switch it to a feature request then. Category terminology is really just a matter of interpretation and since it's your module... I'll defer to your way of thinking. However, from a logistical standpoint it makes absolutely no sense:

You can configure whether the field's label is shown and then, in say a global text field, choose to use that field's token. The problem is, it doesn't output the label. Yes, you could put the labels in manually as you suggest, but for reasons mentioned above (mainly translation) that won't work. It's only a quick band-aid for a problem that needs a real solution. Please stop being so hasty with your tyrannical attitude towards people who are actually trying to help solve problems.

Now in regards to actually trying to come up with a real solution to this problem, might I suggest we use standard token methodology here? For instance:

[title] (this would be the fully rendered field, including a label if it's configured to do so)
[title-raw] (this would just be the field's raw data, no rendered output)

Now I am very well aware that this could essentially affect many sites, if this were a direct patch. So we'll obviously need to come up with a solution that either a) doesn't impact these sites or b) realize that this is just a necessary evolution in helping standardizing field tokens in views and slap a warning that some views might need to be reconfigured.

You seem to have not actually read what I said.

The style renders the field and the label separately. They are different data. What you're talking about is a fundamental architectural change that, as I said above, has implications to styles that render the labels differently.

The very fact of the matter that style A will render Label: Field but style B will render <tr><td>Label</td></tr><tr><td>Field</td></tr> makes what you ask nearly impossible.

In the vast majority of cases, when you are using token substitution, you do not want the field label.

Please stop being so hasty with your tyrannical attitude towards people who are actually trying to help solve problems.

Wow. The only responses I can come up to for this end up as personal attacks, so I will have to not comment. But seriously. This is unacceptable, and this conversation is officially over. I am locking this thread.

style settings ignored

I've decided to relent and have unlocked this thread. However, further personal attacks will not be tolerated.

Now, I want to explain a little more. To do so, I need to describe the order of responsibility, if you will. Your argument is based on the idea that the way the token system is set up "makes no sense". This is indicative of the fact that you have spent no time actually studying the way the Views rendering system actually works.

The way it works is that you've got two layers of 'style'. The outer style, which is just called style (internally; in D7 it has a different name in the UI now), and then there's a style per row, known as the 'row style'. That is, if the outer style supports it. I bring this up because it's especially relevant, because of the table style, which is the shining example of a place where labels are handled completely differently from how they're handled in the normal unformatted style.

But let's go ahead and take the unformatted row style. Here is the template for that style (called views-view-unformatted.tpl.php -- and yes this is poorly named, but names are hard to change after you realize you screwed them up):

<?php foreach ($fields as $id => $field): ?>
  <?php if (!empty($field->separator)): ?>
    <?php print $field->separator; ?>
  <?php endif; ?>

  <?php print $field->wrapper_prefix; ?>
    <?php print $field->label_html; ?>
    <?php print $field->content; ?>
  <?php print $field->wrapper_suffix; ?>
<?php endforeach; ?>

As you can see, this style simply goes through all of the fields, renders the labels and HTML (wrapper prefix and suffix are the chosen opening and closing tag).

Now, the field itself ($field->content) is just the 'rendered' data of the field. This is what you'll find in the token.

The problem here is, as mentioned earlier, the table style renders this completely differently. The label doesn't even exist with the field. Other styles, such as RSS, XML, and JSON render this even more differently still, since there is no HTML. For many, many reasons, when rendering the label and the field data need to be separated.

What you're proposing, then, is a fundamental change in the architecture, where the label and the field become merged (and, according to the original request, the HTML wrappers as well). This makes the table style simply impossible, along with the aforementioned RSS, XML, JSON, etc. In order to make them possible, we have to insert some kind of logic where the field goes and asks the master style how it should render itself, and may or may not give you back a field with a label and some HTML. Now your token replacement is inconsistent from style to style (something that matters greatly if you've got multiple displays on your view using the same data but different styles, as is incredibly common if you're using an RSS attachment) and for people who aren't intimately familiar with the system becomes seemingly unpredictable. Plus, the template above becomes wrong, and that will ripple downstream to the half a million installed users, at least SOME of whom are undoubtedly overriding this template.

There are also all the use-cases where people have a field such as nid, which is being displayed in one column but also being used to create a URL using rewrites in another column. You certainly wouldn't want the label in that field, but that is precisely how some people are using this feature.

Now then, there are workarounds for things not working the way you expect. Instead of excluding your fields and rewriting them all together, you can put those fields together, and rewrite them consecutively so that they contain the markup that you need. For example, if you want to group 3 fields together in a div or p tag or something else, you can do that by opening the div on field A, and closing the div on field C. Obviously there is some danger in this, since if you don't do it perfectly you can have unclosed or extra closing tags. But it can do the trick, and that's the only use case I can think of for rewriting fields in the way that you're asking where translation of the labels is still important.

Finally, I suppose that your insulting tone did cause me to spend more time than I normally would have to provide the full explanation of why this is simply not going to change (i.e, the short version: we are not going to have a major architectural revamp that will cause a lot of pain for existing users in order to make things work the way you expect when your expectations are incorrect). So congratulations, you got what you want. This time. But abusing people on the internet, while easy and fun, is poor practice in an open source community. And I get a lot of grief from people who think I am being rude simply because I am trying to get through issues quickly and my answers are shorter than you'd like, but unfortunately the alternative is to not answer at all. Which, by the way, is what is likely to happen in the future.

What you're talking about is a fundamental architectural change

NO! I'm proposing a change in an existing functionality that's flawed. You don't like people point things like that out. I would say that it's not my problem, but apparent it's mine and a few others as well.

The very fact of the matter that style A will render Label: Field but style B will render <tr><td>Label</td></tr><tr><td>Field</td></tr> makes what you ask nearly impossible.

So on the IF chance that a person is trying to configure a table, that also has re-write rules, they don't use the token that renders the label, they use the OTHER ONE...... how is that "fundamental architectural change"???

In the vast majority of cases, when you are using token substitution, you do not want the field label.

Um, yes I do. Who are you to tell me what I need or don't need? I need my labels to be translatable. I need them to be included in the rewrite section of a custom text field. Sites are configured differently for different reasons.

Wow. The only responses I can come up to for this end up as personal attacks, so I will have to not comment. But seriously. This is unacceptable, and this conversation is officially over. I am locking this thread.

It's your passive aggressive remarks, your quick closure of issues and the fact that you don't let anyone contact you on your user page that makes me resort to point it out here. What's unacceptable is that you don't allow anyone to even propose an idea and then allow them to come up with a solution. I haven't even filed a patch yet, but with your attitude I don't even know if I want to now. You're a very confrontational developer who muffles the voice of others if it differs from your point of view.

Now.... can we stop flipping going back and forth and actually leave this issue to come up with an acceptable solution all around? Compromise, respect and collaboration. I fully and personally take responsibility for the comment I made above, but I'm done having any issue in Views being rejected just because you don't "feel like it".

Just saw your post, please disregard my post above that have "personal attacks". I'm willing to work towards a positive solution and will temper my comments :)

Ok, I just read your response. So to avoid completely refactoring how the tokens work, can we just add an additional token that has a suffix, like: [title-rendered]? This would then specifically call the style's rendering to insert the token with all the desired markup? This would avoid disrupting backwards compatibility AND give those of us who actually need the label and field markup (which can be watered down in the style options) generated?

Finally, I suppose that your insulting tone did cause me to spend more time than I normally would

That's the point... I get that you're trying to get through the issues, but you're going warp speed sometimes and you completely dismiss real issues and frustrate those of us who are really are trying to ultimately help you come up with a solution. I'm not claiming to know the complete intricacies of Views, but I can certainly see some logistical issues from time to time. Just slow down, I get that we're all busy :)

So to avoid completely refactoring how the tokens work, can we just add an additional token that has a suffix, like: [title-rendered]? This would then specifically call the style's rendering to insert the token with all the desired markup? This would avoid disrupting backwards compatibility AND give those of us who actually need the label and field markup (which can be watered down in the style options) generated?

While this sounds like a good idea in theory, check out the template above. The style doesn't know how to render each individual field individually; it's doing them all as a group at final output. Token substitution happens long before the style ever gets to it.

For this to work, every style in Views would have to be updated with a new method, which replaces some of that data. So unfortunately, it's a major architectural change. Now, in theory, you could attempt to put in something that is kind of generic (i.e, what unformatted does) and then all the other styles will just use that...and it'd mostly work, except where it's totally wrong and the style needs to be updated. And since it's rendering HTML, you'd probably have to add new templates for the new single theme, which means one more layer.

That's the point... I get that you're trying to get through the issues, but you're going warp speed sometimes and you completely dismiss real issues and frustrate those of us who are really are trying to ultimately help you come up with a solution. I'm not claiming to know the complete intricacies of Views, but I can certainly see some logistical issues from time to time. Just slow down, I get that we're all busy

Please stop. You've already spent your karma. Saying respect is not the same as demonstrating respect.

Also, really, you should try my other suggestion -- I find it highly likely that you don't actually need to rewrite everything into a single field and try to twist and bend Views into doing something that it fundamentally doesn't want to do.

You can also use the 'custom text' field to create borders (i.e, open and close tags) and stuff as well. Between that and being able to add classes, I can't think of a single use case that can't be accomplished off the top of my head.

Example: Let's say I have the field 'title' and the field 'image' and the field 'description'. I want the title up above and I want image and description inside a DIV together.

I order the fields like this:

• Title
• Custom Text: <div class="someclass">
• Image
• Description>
• Custom Text: </div>

For bonus points, the administrative name (hidden in a fieldset at the bottom of the field somewhere, I think. Unfortunately.) can be changed to be more descriptive than just Custom Text, so you can name one 'Opening DIV.someclass' and the other one 'Closing DIV'. Doing that makes it less likely that later changes will cause HTML breaking mistakes.

I'm not even sure how the last half your post relates to the issue at hand. That's not what we're concerned about. All we really care about is getting the label into the rewrite area (which is pulled from the field settings). The other component I'll second from #5 is that it needs to be translatable.

Ok, so let's avoid the styling altogether since you're saying that the token replacements happen long before that anyway. If we can pull the raw value of the field when token replacements are happening, can we also pull the label value via the field settings? If so, couldn't we do something like [title-label] instead? This, in theory, should allow us to:

1. Have a translatable token for the field label
2. Append the colon based on the field settings
3. Avoid the style rendering altogether and force the user to wrap the tokens in whatever markup they need
4. Keeps backwards compatibility and upgrade integrity

You've already spent your karma. Saying respect is not the same as demonstrating respect.

Like how you demonstrated respect by trying to squash this issue before it even left the gate? Or demonstrating respect to others ideas that were willing to try and come up with a reasonable solution? I really don't care if you think if I was respectful or not. I can be extremely respectful and reserved, but that doesn't work with everyone now does it. Honestly, I only did it because the squeaky wheel tends to get the most oil.... and with you it always seems like it has to be a fog horn before you'll even give it a second thought. Sorry if that bothers you, nothing I can really do about that.

Have a translatable token for the field label
Append the colon based on the field settings
Avoid the style rendering altogether and force the user to wrap the tokens in whatever markup they need
Keeps backwards compatibility and upgrade integrity

You know there is the concept of stable software out there, which means that you don't switch APIs, the generated HTML and some more if possible. Just think of the amount of damage you would do if like just 1 percent of the installed drupal sites with views change their labels so that their css breaks. Just this small thing is already a nogo for me. You will have to accept that, even you probably still disagree.

Earl gave you a lot of help how to achieve this with the flexible mechanisms already.

This workaround:

You can also use the 'custom text' field to create borders (i.e, open and close tags) and stuff as well. Between that and being able to add classes, I can't think of a single use case that can't be accomplished off the top of my head.

Example: Let's say I have the field 'title' and the field 'image' and the field 'description'. I want the title up above and I want image and description inside a DIV together.

I order the fields like this:

Title
Custom Text: <div class="someclass">
Image
Description>
Custom Text: </div>

sounds good, thanks.

An interesting feature I thought about is a PHP field so that the t() function can be used to accomplish this task (and potentially other things). But I don't know all the internals of views and the implications of a PHP field (and I don't want to make merlinofchaos angry lol), so for me the above workaround is enough.

You know there is the concept of stable software out there

Indeed... which is the 4th point I was getting at. It wouldn't break the stability of the module.

Just think of the amount of damage you would do if like just 1 percent of the installed drupal sites with views change their labels so that their css breaks.

That's an invalid argument. Views doesn't currently include the label at all when using tokens, so how can this break a theme? Also, even if you weren't rewriting a field, label and wrapper can be completely customized via the style options to include different markup and/or classes. That is not what I'm getting at here. Render is not what I'm after (changing the title to make more sense... again).

The only thing I'm proposing is that additional token is generated. One that has a suffix of -label. This wouldn't affect anyone, at all, because it's a new feature. Only new views that manually put in that token would generate that label.

Earl gave you a lot of help how to achieve this with the flexible mechanisms already.

I would like to emphasize that I completely agree with both of you on this. I am certainly aware of alternative ways in getting around these issues. That isn't the point. I personally try to render the entity using a specific display (using display suite) as much as possible. However, there are rare occasions where I might need to alter an existing view and don't want to completely restructure it. Which is how I got involved in this issue, it happened to me.

The difference for me, is that I was able to able to do something very similar to what Earl suggested in #16. However, this technique is something I've learned from a completely unrelated issue I read a while back and is one of those things that you just keep tucked in your brain as a nifty little workaround. I still felt it deserved some attention in the issue queue though... I'm getting really tired of workarounds in views.

This is completely beside the whole point of this issue though:

People who do not understand views or even how to code and are just configuring a view from a UI/UX standpoint are expecting this to logically make sense. Case in point #0:

The rewriting of the field itself works fine, but the labels are missing, eventhough they're checked in the field settings (Create a label).

Emphasis on: eventhough they're checked in the field settings (Create a label).

From a UX standpoint, this makes complete sense. If you have "Create a label" checked, why wouldn't it show up in the token when you're rewriting a field. I'm well aware now, that logistically it's damn near impossible to do this given the existing architecture of the module.

I guess why I am so passionate about this issue is because I feel that less experienced users are often left to the dust because "that isn't how it works". Well why can't we all show them some compassion and fix these tiny things when we can. Yes, in hindsight, this issue is relatively small, but it turned into a huge debatable issue because I'm not willing to just roll over like some novice user. They don't have years of experience, understanding of the Drupalisms or Viewsisms, or even the intuition to sift through countless issues for a solution to their problem or the willingness to debate a solution. God forbid they have to apply a patch lol

My only goal here is to provide an amicable solution that will benefit the masses, without impacting existing sites. I believe I came up with a solution, am I really THAT wrong here??

@sardbaba: Yes, I've thought about using a PHP field, it works. However I really hate putting PHP in a view if possible.

Ps... I wasn't calling no one in particular a novice (just going to squash that before someone picks that to death). I'm just saying that they do exist... even if they're not on this issue.

Sorry again, the workaround that sounds good at #19 doesn't work because the opened div is automatically closed... so, you write something like that:

Title
Custom Text: <div class="someclass">
Image
Description
Custom Text: </div>

but result is:

Title
Custom Text: <div class="someclass"></div>
Image
Description
Custom Text: nothing

Maybe I'm doing something wrong, but, @merlinofchaos, did you tried it?

@Mark: yes, putting a PHP field might not be the best solution, but is a completly new feature that doesn't interacts in any way with the existing views, so, the backwards compatibility is safe and this problem can be solved. Also, allows to do new stuff, so... why not?

Edit:
Naturally, also the rewrite of the first field with:
<div class="someclass">[field_image]
becomes:
<div class="someclass">[field_image]</div>

sardbaba: Yes, there is a checkbox in the rewrite section that defaults to true to enable HTML correction. You have to tick it off.

A workaround that I used when bumping in to this:

Install views field view, and make a new view containing the fields you originally wanted to make a rewrite for, then use the views field view ability to include the (new) view in the original view as a field. Note that the developers warns that the module can be 'heavy' in use and therefore recommends to use caching with views.

sardbaba: Yes, there is a checkbox in the rewrite section that defaults to true to enable HTML correction. You have to tick it off.

Apologies if I'm missing something obvious, but for views 7.x-3.7, where exactly is that checkbox in the rewrite section?

Unfortunately, solution mentioned in #16 doesn't work with Views PDF module.

Also, I completely support request to add something as [title-label], proposed in #17. I didn't see any workaround (apart from using Views field view), which would allow us to use translated label as token.

This has been my workaround (although I still have white space when the field is empty)

1. Add all desired fields. Exclude from display all but the final field, or whatever field contains the main rewrite.
2. Hide if empty AND hide rewriting if empty on all fields.
3. For fields that need labels to display, rewrite the original field to include a manually-typed label. So if you're rewriting a field named Image, the rewrite would be Image: [field_image]
4. Rewrite the final or main field to include [field_image] and you'll get your "label"

Although it's extra work, this lets me display a label on a field I originally excluded, and it doesn't show my "label" if the field is empty. I still have whitespace in the output, but I can live with it.

Although I must admit, that I have not completely understood how the token replacement works in views and therefore I cant judge upon the feasibility, I agree with #17 that it would be a great feature to have extra tokens for all enabled labels. From a user perspective it would totally makes sense to name them like:

[title#label]

or something similar. Creating complex views on multilingual websites I end up many times having problems, that could be solved with this feature. Now I am often forced, to create custom fields as a work around.

#28 worked great for me - thank you kdomenick.

#28 worked for me as well. Surprisingly simple solution, thank you!

Just had a need to do this, and #28 worked out great. Thanks, kdomenick!