Better empty 'field' replacement

You could do this with theming of the fields. This might be a feature request, but i think its hard to develop a generic thing.

This feature already exists on most fields. Scroll down in the list of options when configuring a field. There should be an empty text.

The "Rewrite the output of this field" is an amazing option but could not be used with "Empty text".

This is the scenario: you have 2 field "summary" and "body" and you want to display the first one, if available, or a trimmed version of the body.

Yeap you can do this a theme level (just create an appropriate "Row style ouptut") but would be very nice if "empty text" could be managed as the "Rewrite" (i.e. tokens).

The idea would be:
* add the field "body", set as "Exclude from display" and "Format: trimmed";
* add the summary field, set "Empty text" to "[field_body_value]" (or what you have in the "Replacement patterns").

At this point the code should try to apply the same replacements as it was used in "Rewrite output".

How this would be possible?

Well, now we have (handlers/views_handler_field.inc line ):

    if (empty($this->last_render)) {
      if ($this->last_render !== 0 || !empty($this->options['empty_zero'])) {
        $this->last_render = $this->options['empty'];
      }

But we can change the code to:

    if (empty($this->last_render)) {
      if (($this->last_render !== 0 && $this->last_render !== '0') || !empty($this->options['empty_zero'])) {
        $this->options['alter']['alter_text'] = 1;
        $this->options['alter']['text'] = $this->options['empty'];
        $this->last_render = $this->render_text($this->options['alter']);
      }
    }

This change keep the previous behavior if you use plain text but give you the option to use your beloved tokens.

The attached patch apply to Views 6.x-2.10 ($Id: views_handler_field.inc,v 1.33.2.13 2010/04/08 21:38:46 merlinofchaos Exp $).

Update status.

This looks really useful, and I don't see a way to do this without this patch (due to inheritance), if you wanted this behavior on a number of different types of fields. It needs to be solved at the root level handler, and this is it.

However, two issues:

1) Seems awkward to put tokenized text into the empty textfield here. It's a nice answer, though, to avoid adding interface issues... we don't want to add a new checkbox. Ideally, nothing we do should have any potential to break any existing views.

2) Rather than add that at the advanced render, why not solve it at render? Seems cleaner since we already check for empty at the top, and then do token substitution next...

What about this instead?

  function render_text($alter) {
    $value = trim($this->last_render);

    if (!(empty($value) && $this->options['empty'] == '[rewrite]' )) {      
      if ($this->options['hide_empty'] && empty($value) && ($value !== 0 || $this->options['empty_zero'])) {
        return '';
      }
    }

    if (!(!empty($value) && $this->options['empty'] == '[rewrite]' )) {          
      if (!empty($alter['alter_text']) && $alter['text'] !== '' ) {
        $tokens = $this->get_render_tokens($alter);
        $value = $this->render_altered($alter, $tokens);
      }
    }

// continue as before

The code needs some cleanup (I dislike the extreme !() usage but it was much cleaner to understand the logic that way, since really it shows how simple the change is: 2 extra ifs, wrapping the first 2 existing ifs).

This works simply by putting '[rewrite]' into the Empty Text field, and making sure you have clicked Rewrite and put into something into the rewrite area. If the field has content, then no substitution is done; if empty, then rewriting via tokens happens.

Among other extra goodness, you can now rewrite a empty field with a full html response if you wish, as a side benefit of this.

The net effect is the same, but this seems cleaner...

From your scenario: If you want the summary, and only if no summary exists, use the trimmed body, this works well, breaks no current functionality, and merely requires us adding some help text to the Empty Text description
"If the field is empty, display this text instead. Enter [rewrite] to use Rewrite only if the field is empty"

Patch attached - as I said, could be cleaner logic-wise, but shows how simple the patch really is.

I don't like [rewrite] as a special token. The original patch is much cleaner in that regard in that it Just Works.

If I read it right, the original patch will also handle stripping and shortening and other processing elegantly; thus handling the concept of "if teaser is empty, show shortened body; otherwise show teaser". Sure it means that the teaser and body have to follow the exact same rules, which may not be ideal, but at that point you're complex enough to need to move ot theming.

+++ /contrib/views/handlers/views_handler_field.inc	Sun May 23 19:41:54 2010
@@ -488,13 +488,17 @@
+    if (!($this->options['empty'] == '[rewrite]' && empty($value))) {      ¶

Space at the end :)

+++ /contrib/views/handlers/views_handler_field.inc	Sun May 23 19:41:54 2010
@@ -488,13 +488,17 @@
+    if (!(!empty($value) && $this->options['empty'] == '[rewrite]' )) {          ¶
...
+      }

Could we try to have the same order of parameters as above?

Powered by Dreditor.

I try to keep things simple in the patch #5 reusing the same code of alter text

  $this->options['alter']['alter_text'] = 1;
  $this->options['alter']['text'] = $this->options['empty'];
  $this->last_render = $this->render_text($this->options['alter']);

About UI I guess using another token as [rewrite] could be an issue: what happens if there is a field with the same name?

Moreover, using the area for "Rewrite the output of this field" could be not so clear to the user: you have to enter the code there AND add [rewrite] in the textfield for "Empty text:". I mean if you enter some code in the "Rewrite the output..." the field itself doesn't evaluate empty and you break the logic.

If you need a more complex rewrite, my personal taste suggests to add a field (before the field you need to handle) with appropriate "Rewrite the output..." and "Exclude from display" option set and use it in the "Empty text": this keeps the interface simpler. The alternative would be adding a thickbox and replicate the "Rewrite the output..." entirely, but this would requires more than 3 lines.

@merlinofchaos:
My patch does the same extended processing correctly (try it out). The [rewrite] isn't a real token, feel free to replace it with any text/flag you wish. Or add a checkbox? Since Empty Text doesn't process tokens now, the only potential breakage would be a view where the user explicitly wanted to use the text "[rewrite]" (Emanuel is incorrect here, a field named 'rewrite' yielding a [rewrite] token would still function fine in the alter text: this isn't a real 'token', only a usage flag. You could use *rewrite* or anything else)

Also, the original patch is slightly less useful: if I want a multiple line replacement, I can't due to the use of the textfield instead of the alter's textarea. My patch says "if field is empty and _only_ if it's empty, go _use_ the rewrite alter settings", which right now, views doesn't do, so it's adding a feature, and won't break any existing views. That's another problem with the other patch; you'll break any existing views that have any token-y field at all in Empty Text now. Without some new way to flag/control this, you'll introduce problems if preexisting views starts behaving differently for those people.

Moreover, using the area for "Rewrite the output of this field" could be not so clear to the user: you have to enter the code there AND add [rewrite] in the textfield for "Empty text:". I mean if you enter some code in the "Rewrite the output..." the field itself doesn't evaluate empty and you break the logic.

@Emanuel:
1) Yes, that is what help text is for, especially since you are adding a new feature. What if the user doesn't want this turned on? New users may find [rewrite] clearer because they can ignore it if they don't understand it. Your method requires help text too: "You may add any tokens here." but then lacks a way to disable this feature if they want any text that is also validly token-y (ie [title] or [url])

2) If the field is empty, Rewrite isn't invoked at all in the first place. That's the whole point of our patches.
Yours 'just happens' but if empty, uses a _different_ rewrite string, mine requires turning on a flag in the Empty Text, but uses the original rewrite's textarea. The big difference with mine is when the field is NOT empty: My patch _disables_ the rewriting if the field is nonempty, and makes that rewrite happen only on empty values _instead_. It cleanly reroutes rewriting for empty usage rather than the normal behavior of nonempty usage.

Honestly, neither patch is a perfect answer. Either adding a new textarea/checkbox Rewrite if Empty, or smarter token code (something along the lines of [token1|token2] where it falls back on a empty value token1 to use token2), would be a far better answer, but both are much more complex and add interface changes too.

Honestly, I'll use whichever patch goes in, but let's get one of these (or some improved variant) in. It would be nice to not have to handle this outside the view in preprocess or theme. Views handling empty values with a substitution of another field is a huge bonus making many rethemes unnecessary.

I'm not really fussed about the actual naming of the [rewrite] token, but rather it existing at all. It's going to be difficult to explain how that works in the UI. Whereas, if you just put in tokens, I think that's exactly what users will expect to happen, I think.

I'm having trouble seeing the downside of the original patch. Can you explain it to me more clearly?

The more I look, the less downside I see. (grin)

My original objection was if a token existed and the view author had really _wanted_ to use plain text that matches a valid tokenname, they wouldn't be able to. For example, with his patch, [url] or [type] or [nid] cannot be left as plaintext... but first, that's an odd piece of plaintext to want to use, and secondly, it must be in the limited group of existing field tokens (not sitewide tokens), so the potential breakage is likely very small if any, for preexisting views that might be affected.

My second objection was the use of the existing textfield (a single line for Empty Text) versus the textarea (multiline already in use in Rewrite). But that's such a minor point (and I suspect workaround-able using views in code even if the UI isn't changed to support it), that I'll waive the objection.

My solution creates a Either answer: either Rewriting happens only when not empty (by default, as it functions now), or (new with my patch) Rewrite is applied only when the field is empty.
The original patch allows Both to occur: Rewrite as normal if not empty, and Rewrite using the Empty Text token(s), if empty.

I withdraw my patch in favor of +1 to @EmanueleQuinto's patch, as the Both is likely more useful than the Either. Neither the textfield vs textarea differences, nor the awkward use of the pseudo token/trigger is worthwhile when his patch is the more common use (rewriting either way) that people will want and expect.

If you don't see any downsides, sounds RTBC to me...

Sounds like a plan. Committed.

I may have some information on this. I don't code much, but I came today to report a bug and I think this thread is where it should go.

I have a view that adds a limiter on the end of the taxonomy/term/%1 core view. If the url has lds_clipart appended, it displays items of only two content types: image and a custom type called documents. I am trying to use the empty field block to display a place holder image when an image is not displayed (only applies to the document content type in my case). I have put the following code in the Empty Text area for the Images field:

<img align="left" src="http://www.jennysmith.net/sites/all/themes/newswire/images/lds-printable.png">

The following link shows the problem clearly:
http://www.mormonshare.com/taxonomy/term/2393/lds_clipart

The first item in this list happens to be a document. The empty field image shows up perfectly as expected.

Next are some images -- just right.

Next follows a couple more documents. Now the empty text field image data is not displaying.

I think there might be a problem with a flag or something that is supposed to tell whether the empty field applies or not. It *could* explain why oxford-dev can't show images either, if the first item in those lists does not call for the "empty" field to be called.

Hope I'm doing this right and not making a fool of myself :)

Jenny, looking at the source of your example, I see non-empty content...
for example:

<div class="views-field-image-image">
   <span class="field-content"><a href="/lds-clipart/yw-opening-exercises-agenda-half-sheet"></a></span>
</div>

So of course, that's not going to trigger the empty text: it's NOT empty, is it?

Please open a fresh issue, as this still isn't the right place to discuss this though.

Thanks for your help, Seth. The images field IS empty for the document content type. See how it works properly the first time a document is included on the list?

I have started a new issue for this here: http://drupal.org/node/873750

Tracking so I remember to apply this patch on a few sites. Looks extremely useful.

Sorry to bother everyone but the patch is not working as expected. I have taken the liberty of change the priority because it is an actual bug.

The problem is that in the first occurrence of an empty field the options['alter'] array is changed for all the following values: this means that following values are replaced with the empty value even if they are not empty.

The solution is to avoid any change in the handler object and to use a copy instead; the options['alter'] array is copied to a local array and this value is then passed to the render_text method.

     if (empty($this->last_render)) {
       if (($this->last_render !== 0 && $this->last_render !== '0') || !empty($this->options['empty_zero'])) {
         $alter = $this->options['alter'];
         $alter['alter_text'] = 1;
         $alter['text'] = $this->options['empty'];
         $this->last_render = $this->render_text($alter);
       }
     }

It's worth noting that the render_text apply all other settings ('strip_tags', 'trim', 'make_link', 'path') to the value set in the "Empty text".

Moreover I'm wondering if we need to add some help about "Replacement patterns" available.

The patch apply to views_handler_field.inc,v 1.33.2.14 2010/06/16 19:15:53 merlinofchaos.

Critical = "OH CRAP THE ENTIRE MODULE IS BROKEN." Views is not broken.

Patch in #22 applies fine and seems to resolve the issue for me.

+1, good eye for the catch.

The patch worked fine for me.

Just a notice, this patch does not apply on d7.

I'm totally confused because this kind of code is already there in d7.

7.x-3.x patch.

Patch does not seem to apply. Hopefully just needs a reroll.

Re: #30 -- Which patch did not apply, the 6.x in #22 or the 7.x in #29?

#22. I was only working 6.x at the time, sorry to not be clear about that.

@merlinofchaos

http://drupal.org/node/768060#comment-3392554 is for 6.x-*
http://drupal.org/files/issues/768060-d7.patch is for 7.x-*

I don't see how telling me which patch it is will make it apply now. =)

Reroll for 6.x-2.x-dev attached.

Yet another reroll for 6.x-2.x-dev is attached - this one applies with "patch -p0" as it should. Patch looks good to me so RTBC:ing for the 6.x-2.x patch,

+1 (Subscribe) Has this been committed?

Committed to all branches.

I'm not seeing this code in the latest 6.x-2.12 release... where was it committed?

Thanks

Why does no one ever read release notes before re-opening issues?

I thought "Committed to all branches" meant all branches. Thanks for clarifying.

It was committed to all branches.

However, the 2.12 release was a security-only release, and so does not represent the -dev branch at the time of its release. And I'm getting very frustrated by the sheer volume of people re-opening old issues because it's apparently easier to assume I fucked up the commit than it is to go see if there's something special about the release.

Sorry Merlin, I didn't mean to imply that you fucked up the commit, I simply asked where it was committed. If it was in another release/branch, it was not clear where that would be found. (It's still not clear; I re-applied the patch manually.) The release system on d.o (and related CVS branching system) is not the most intuitive in the world.
Thanks for all your work, see you at Drupalcon.

It's in the 2.x-dev release.

On 6.x-2.12, if "Count the number 0 as empty" and "Hide if empty" are used together for node comment count field, field is hidden correctly for the nodes which has no comment, but not on 6.x-2.x-dev.

I'm using the rewrite the output option BTW to put a small icon near the comment count. Dev version gives empty icons, but stable version correctly hides the whole field.

I'm not sure if this is related to this commit, thus not activating the issue, but reporting anyway. Tx.

#46: see #941114: "Hide if empty" not hiding items and #936828: [token] empty text replacement does not work with values of zero that are formatted. Probably related to that.