empty columns in table design after update

A quick test on my system doesn't reproduce this problem. You are going to have to provide specifics.

I got the same problem after update 2.2-->2.3.
It´s no CSS-Problem. The field values aren´t shown in html source code. If i change the view-layout from "table" to "undefined" all fields are available.
My config:
- drupal 6.9
- views 2.3
- cck 2.1
interesting detail: date-field from the date-module works.

i had the problem too,
but fixed for now.

drupal 6.9
views 2.3

reproduce
for me the problem appeared in following situation:
* installed cck date module (date-6.x-2.0-rc6)
* created content type with date-s
* created view that includes some date field(s).

result
for each row from first date cell to right all cells appear empty.
if date col would be first col, then all the table would appear empty except first one (the date).
if date col would be last col, then everything seems normal.

trackdown
i started to track the problem and i was able to spot bug in views/theme/theme.inc, line 303.
here is a loop that goes through all the fields and does theme() callback,
but somehow it distorts (breaks) the loop.
probably callbacks needs fixing too.

diff
diff -r views.orig/theme/theme.inc views.fixed/theme/theme.inc
302c302,307
< foreach ($view->field as $id => $field) {
---
> // makes fields backup for foreach loop
> // because theme() somehow breaks the loop
> // if field is of cck date type
> // probably needs fixing too
> $fields_tmp = $view->field;
> foreach ($fields_tmp as $id => $field) {

What version of PHP are you all using?

PHP Version 5.2.0-8+etch13

I had a similar problem when I upgraded to 2.3.
I didn't use a table design and also didn't use any inherited arguments, but my unformatted attachment also did only show up as an empty div.
Since I've then replaced it with 2.2, everyhting works fine again.

I got the exact same problem.
Upgraded from 2.2 -> 2.3 and suddenly the view has some empty columns in the table. Only the columns that are bound to the node_title and a field_date show the values.
Switching to any other display style shows all the data again.
If I make the table sortable, I can still correctly sort by all columns, even the ones that don't display anything. I've also overriden some of the fields output with template files and those template files are not even opened for the empty fields.

I'm using Apache/2.2.3 (Debian); PHP/5.2.0-8+etch13; mod_ssl/2.2.3; OpenSSL/0.9.8c

I would also like to add my hat into the ring, although I have to admit that I think I had the problem before updating to 2.3 as well. Anyway, it's only one CCK field out of three that isn't displaying, a simple text field. The other two fields are simple as well, and display consistently. But I think I am seeing the same bug as in the above reports because switching to other types than "table" displays the field again (for some reason that escapes me, I still get the table output when I use "Unformatted", at least under the Twilight theme -- completely identical to "Table" but with working CCK fields).

PHP 5.2.0-8+etch13

Any news on a fix for this issue? Do you need more information?
It's easy to reproduce, just include a Date field in your table, and any columns after the date column will be empty.

#3 works fine for me. Thank you!

This is still a problem! News? Any one? I'm trying to display a teaser view and a file field.

As mentioned above, it works correctly with list / unformatted views.

I'm trying to debug this and the issue appears to come in views/theme/theme.inc at line 302 where this block:
foreach ($view->field as $id => $field) {
$renders[$count][$id] = $view->field[$id]->theme($row);
}

doesn't add all the columns to the renders table.

For no reason I can discern, the foreach I mentioned above completely fails, but is fine when you only iterate over items in the $columns array.

The patch in #14 worked for me. Thank you!

#14 worked for me, didn't break non-table views either

Patch on #14 worked for me as well.

Strange thing is that my table worked fine under PHP 5.2.5 but did not under PHP 5.1.6. The patch fixed it so that it now works on both.

Patch #14 worked for me.

Also I noticed a similar PHP version dependency. The problem is present on 5.2.0-8+etch13, but not on 5.2.5 on OS X.

I tested this one line patch and say its okay and my before faulty view now runs as expected.

//line 287
  $fields   = &$view->field;
  $columns  = $handler->sanitize_columns($options['columns'], $fields);
  //line 302
-    foreach ($view->field as $id => $field) {
+    foreach ($columns as $id => $field) {

Seems more like a typo to me.

Patch #14 also worked for me, thank you!
As said by grendzy (#21), the problem seems to be present on PHP/5.2.0-8+etch13.

The patch in #14 doesn't apply cleanly, but the code in it fixes the same problem for me, too. Here's a reroll. No need to credit me for it.

I admit I don't understand this patch. The list of columns is not the same as the list of fields. I do not understand why this works, and I am pretty sure this will actually cause problems with 'excluded' fields not being available for use by the output rewriting.

Something does not add up, but I do not believe that this is the proper fix.

This issue blocks a 2.4 release, unfortunately, and I can't duplicate it. The fix cannot possibly be right, but I don't understand why the existing code is having problems. And only on some PHP versions. :/

Maybe the reference is messing up? Especially between PHP 4 and 5?

//line 287
$fields   = &$view->field;

http://de2.php.net/manual/en/language.references.return.php

@merlin: Here's an exported view; does that help at all? I could probably get you a full site backup if you're interested.

guys... could anyone make this patch into a release? i'm not into patching modules at all.
thank you very much!!!!!

drupalok: No, because as I said, this patch will break other functionality. In fact, because I love hearing myself talk so much:

The fix cannot possibly be right, but I don't understand why the existing code is having problems.

This needs a proper fix, and this patch isn't it.

Ok, rereading #3, I think I may have something. Here is a patch to try.

Please let me know if this fixes the problem.

@ merlinofchaos
i tried to apply your patch but it did not work ("assertion failed") --- but i am not really good in patching. could you please upload the patched file for me? i know it's not "programmer-like" ... but it would make my life so much easier!

thank you very much!

Ok, I went ahead and committed this, I'm pretty sure it will do the job. Also I care a bit less about it realizing that it is purely a PHP bug that affects only Debian etch.