In Views versions prior to 6.x-2.13, it was possible to hide an empty field by checking the "hide when empty" checkbox. This worked as well when the field content was rewritten. Very intuitive, and simply an incredible powerful feature. I have spent the past thee weeks to develop a large number of Views which make heavy use of this feature. Since this worked even recursively (rewrite a rewritten field into another one, hide/replace segments if empty), it was to some degree even possible to write some kind of natural language sentences from database tokens.

In 6.x-2.14 this does not work anymore. If a field is empty and has been rewritten, the only the field content is "hidden" (which is anyway empty), but not the rewritten stuff around it. The new behaviour changes significantly how this feature works, and I consider this as a major regression since a previously existing functionality has been removed without warning (or understandable reason). Probably a lot of existing Views will break in nasty ways when the 6.x-2.14 release is being deployed.

For 6.x-3.x-dev there has been a lenghty request to add #1020540: Add a "Hide Rewriting if field is empty" option. I assume that the changes in 2.x came from the 3.x branch, and the (existing) fixes for the 3.x branch accidentally haven't made it into the 2.x branch.

However, please give us back the possibility to hide rewritten fields when they're empty!

Thank you!

Comments

Status:Active» Fixed

Yeah this is quite a major bug so it should be fixed in the next views version. Just commited the patch from 6.x-3.x but this will be an exception, because 6.x-2.x is in a really stable status.

I'm sorry but I am having difficulty understanding what is meant by comment #1.
Is this fix now also committed to the 6.x-2.x branch?
Thanks.

@dereine: Yes, was rock solid, until yesterday ;) Since the next Views release might take a while, could you maybe roll a patch against 6.x-2.14, or should it be safe to update to 6.x-2.x-dev for production?

@izmeez: I understand that a) the bug is being confirmed, and b) already has been fixed in 6.x-3.x. That's the really important part. We "just" have to wait until a new stable release - probably something like 6.x-2.15 - is being published, or we need to update to 6.x-2.x-dev.

Status:Fixed» Needs work

this bug has hit me too (I relied heavily on the 'hiding')- and I did go directly from 2.12 to 2.14

this means I have to go back to 2.12 (or 2.13) for all my sites until a 6.x-2.15 is ready,
or is there a patch I can apply to 2.14 (I did not see it)?

Edit:
Ok, #10 on parallel issue "Views doesn't respect hide field ..." indeed seems to help, does that count as fixed?

StatusFileSize
new42.08 KB
new105.35 KB

This also hit me hard on one of our sites, b/c we just need to know if the field is there and put a DIV there so we can do a background image (indicating that the story is a video). But now, all of our stories are marked as videos b/c the DIV isn't being removed.

Will this be folded into the 6.x-2.X branch? I haven't investigated the 3 branch yet...

Thanks!

Disregard my question ... I see you answered it & it's in the -dev branch.

http://drupal.org/node/1330148#comment-5202684

But I don't see where I can download a 6.x-2.x-dev ?

Thanks, reswild & dereine! Works great! I just had to check the new "Do not rewrite if empty" checkbox.

Version:6.x-2.14» 6.x-2.x-dev
Status:Fixed» Needs work

(1) The patch from #6 does not apply against 6.x-2.x14:

# git apply 6-x-3-x-hide_rewriting_if_empty-1020540-24.patch
error: patch failed: handlers/views_handler_field.inc:728
error: handlers/views_handler_field.inc: patch does not apply
...
patch < 6-x-3-x-hide_rewriting_if_empty-1020540-24.patch
patching file views_handler_field.inc
Hunk #1 FAILED at 348.
Hunk #2 FAILED at 728.
Hunk #3 FAILED at 833.
3 out of 3 hunks FAILED -- saving rejects to file views_handler_field.inc.rej

Maybe it is rolled against views-6.x-2.x-dev or whatever. We need a patch against the stable and recommended release 6.x-2.x14 that can be used on production sites.

(2) Upgraded one of my production sites to views-6.x-2.x-dev, cleared caches (drush cc all), issue still existed. Edited one of the affected Views, checked the new "Do not rewrite if empty" setting, saved the View and cleared the Views cache, issue still existed, mybe because I missed some "Do not rewrite if empty" checkboxes, or just clearing the Views cache does not suffice. This is not good.

  • Even in today's views-6.x-2.x-dev all Views that rewrite empty fields are still broken by default
  • As is, the issue can only be fixed by
    1. moving production sites to an unsupported development release (views-6.x-2.x-dev)
    2. plus manually editing every field in every View that might rewrite or hide anything
    3. plus clearing "all" system caches (drush cc 1) because just clearing the Views cache (drush cc 9) does not suffice. This might have have an serious impact on production sites with Boost (6.x-1.x-dev), if the "Views to run when looking for content relationships" settings are active (Boost might dump lots of pages when they have attached views or Views blocks with arguments on the nid, etc.). On large sites this might cause severe extra load on the server, so be extra careful if you are running complex Views with Boost! (on the one production site where I deployed views-6.x-2.x-dev and started to modify the broken Views, the server load simply doubled on a Xeon with 8 cores)

I am not very happy with this as a new functionality is introduced in a stable branch, and the old functionality is changed; imho things like this should only happen between major version updates (like 1.x -> 2.x, or 2.x -> 3.x). Things like this make the whole versioning with point releases pretty obsolete; what we are experiencing feels more like a rolling release (even more so if we are actually forced to deploy views-6.x-2.x-dev on production sites).

As it seems, it'd be possible to mimic the old functionality if the new "Do not rewrite if empty" setting would be checked by default in Views fields that have the "Hide if empty" setting checked. However I don't know if the update scripts would be able to handle this or if there could be side effects in other use cases.

StatusFileSize
new600 bytes

@asb
You should better try to learn how to use patches :) Since git you should use patch -p1 < filename.patch instead of patch < which does patch -p0 < .

I'm sorry that some kind of bug came up, but you have to know that this new bug got introduced by fixing another bug.
So we provided a 2.13 version which just has the security patch applied, so people can update safe.

moving production sites to an unsupported development release (views-6.x-2.x-dev)

I'm thinking of adding the dev release again to the project page, because this seems to be a wrong sign, if people
think that the dev version is totally unsupported. Just the fact that i answer here shows the difference :)

plus manually editing every field in every View that might rewrite or hide anything

I agree, we have to change the default behavior, so here is a patch to do it. Please test with your new patch skills
the patch. Thanks!

I am not very happy with this as a new functionality is introduced in a stable branch, and the old functionality is changed; imho things like this should only happen between major version updates (like 1.x -> 2.x, or 2.x -> 3.x).

Personally i already apologized for the bug, but well you know it's not that you can't test the update, make backups etc.
Additional people shout for new features also on non-major updates, and you also don't want to disappoint them.

In general update scripts doesn't help here, because views aren't stored in the database all the times.

Status:Needs work» Needs review

Update status.

Status:Needs review» Reviewed & tested by the community

@dereine: Thanks for the new patch. It applies cleanly with git apply against 6.x-2.x-dev which includes the patch from #6. As far as I have seen it sets the checkbox "Do not rewrite if empty" by default in all fields of existing Views, and I couldn't make out any negative side effects in my use case. Changing status based on the positive user experience, but I am not able to review the code itself.

My message is not intended as flak, I'm fully aware that maintaining a software with 350k users can be a heavy burden, and with Views the maintainers definitely do an incredible job. I am simply surprised that this issue went unnoticed through the dev cycle and survived regression testing.

According to drush rl views the releases of Views are currently tagged as follows:

  • 6.x-3.x-dev - 2011-Nov-05 - Development
  • 6.x-3.0-rc2 - 2011-Nov-02 - Supported, Security
  • 6.x-2.x-dev - 2011-Nov-05 - Development
  • 6.x-2.13 - 2011-Nov-02 - Security
  • 6.x-2.14 - 2011-Nov-02 - Supported, Recommended

If dev releases are fit for productive use greatly varies between projects; some maintainers try to keep the dev releases functional at all times, others strongly discourage the use outside development sandboxes. Any advice on this in regard to views-6.x-2.x-dev is greatly welcome! Btw, when updating through Drush, views-6.x-2.13 is skipped by default. So probably it's good advice to think twice when simultaneously a security and yet another release is published. There might be a reason for this ;)

Again, thank you for the quick response and fast fixes!

Unfortunately the system is linear. It's pretty tough to have both releases available. Views 2.x-dev has been pretty stable for a long time. You're right, I'm very surprised that this bug has been in -dev for a long time. I think we are running into the fact that the people who work on Views now consider the 2.x branch a bit of a red-headed step child and don't actually use it anywhere; the people who actually *use* the branch aren't really developing on it, so there's a mismatch.

...so it might help if we (users) would actively deploy views-6.x-2.x-dev at least, or better if you (developers) would convince us to use views-6.x-3.x-dev/views-6.x-3.0-rc1 (even with the risk of making the Views issue queue even more unmanageable)?

(Totally off-topic: Maybe rolling releases are an option to consider? I'm impressed for years how well this seems to work for MediaWiki, released on a rolling quarterly release schedule).

To boldly go where only devs have gone before ... shudder ;) I deployed views-6.x-2.x-dev plus the patch from #13 on two additional production sites with excellent results. I believe this combination restores the behaviour of views-6.x-2.12 in regard to empty rewritten fields completely without having to manually touch all relevant Views. #13 probably can be committed since the patch is really small, seems not to affect other Views handlers, and keeps views-6.x-2.x-dev in sync with this issue.

@dereine: This is very good work, thank you again!

Well you know it's not that easy as you think.

This changes the default behavior which means that views which have the default value, are changed.
If you export a view you certainly saw that no every setting is exported, but settings which were changed. If you change now the default value, the behavior of this views might change.

Okay for views2 in d6 it's sure okay to change the default value, as this wasn't it for a long time, but for views3 on d6/d7 this will change the behavior of the the views of many people, but i guess that's what people want most of the time.

Thanks a lot for this fix ! It works now for me.
I describe here what I did to fix this bug from views 2.14 to be sure it is what to do.

I followed these steps :

  1. download and install 2.x-dev in place of the 2.14 version : drush dl views-6.x-2.x-dev
  2. patch views-6.x-2.x-dev with patch in #13 : patch -p1 < 1331032-default-hide_alter_empty.patch
  3. clear all caches : drush cc all

Yesterday, 6.x-2.x-dev was updated, it seems not to include the patch from #13. The patch is still applicable, but now outputs a notice:

# patch -p1 < 1331032-default-hide_alter_empty.patch
patching file handlers/views_handler_field.inc
Hunk #1 succeeded at 170 (offset -189 lines).

What's the point? The status of this issue is still RTBC and not "fixed".

The patch work for me but I have "Global: Custom text" fields in my views and if "Do not rewrite if empty" is checked (by default with patch #13) these fields are hidden.

I don't know if it is a bug ?

StatusFileSize
new4.74 KB

Commited to 7.x-3.x but converted because the post from nikosnikos is sadly true.

maybe change the default for this field, but couldn't this cause other problems as well?

Status:Reviewed & tested by the community» Needs review
StatusFileSize
new1.08 KB

Okay the global custom field is special because render() returns nothing here.
Adapted it, so it always returns something, so it's never empty.

Status:Needs review» Fixed

Okay after some more manuall testing commited it to all three versions.

Thanks dereine. Yesterday, I installed the dev version (views-6.x-2.x-dev.tar.gz) dated 14 November and this resolved the issue for me on a multi-site install of Drupal 6.22 running on an IIS server. Like others in the thread, I had upgraded from Views 6.x-2.12 to 6.x-2.14. Latest dev has fixed it for me in all cases.

Status:Fixed» Active

Having problems with this still using the latest version 6.x-2.16

I have added a url field to user profiles

When I go to include this field in a view (list of users) there seems to be no way of hiding either the label or rewritten content when the field is empty. No combination of ticking boxes seems to work.

I have checked in the style settings also.

Thanks

@benced: Export of the View, please.

codeblock removed attachment instead in comment #32

@benced: Thanks for the export; however please edit your posting, add the export as attachment, and remove the huge codeblock from the posting.

With a display style like "Unformatted" I can reproduce the issue to some degree; as long as "display as link" is checked, the field title indeed isn't hidden if the field is empty. However, If you uncheck "display as link", it works as it should and hides the field, influding the field title.

This workaround should work: Rewrite the "profile-url" field like so:

<a href="http://[value]">[value]</a>

(You need to replace [value] with the proper token for your "profile-url" field).

Then check "Hide if empty", "Do not rewrite if empty", and uncheck "Display as link".

However, I don't know if this qualifies as a bug.

StatusFileSize
new10.07 KB

Thanks asb, that did the trick, don't know why I didn't think of trying that.

Added attachment of view to this comment.

There is obviously a conflict here, with the "Display as link" option, but there is a workaround, as you point out.