I would have made an issue on the offending module, but I'm not sure if the problem is on the CCK or VIEWS end of things.
I have been running Drupal for a bit and recently decided to catch up on some maint. Almost everything seems to have worked except for one of the views that I had previously created. I am now current on all modules according to the update report and Yes I did run the update after each upgrade
This view is creating a block that was displaying a list of node type=projects(one of my new CCK types). Any time I try to dislay a page that contains this generated block. I get the following error msg in my apache log. All I get in my browser is a blank page.
[Sun Nov 18 00:27:56 2007] [error] [client 99.99.99.99] PHP Fatal error: Call to undefined function: () in /removed for security/httpdocs/sites/default/modules/views/views.module on line 1581
I did a google search and only found one mention of this msg. Unfortuneately that peron solved their problem b y deleting all their views, and it somehow related to usernode.
I've tried clearing all the cache I could find, but it didn't help. If I deactivate the block the previously failing pages display OK. If I duplicate the block-VIEW that is causing the problem and delete what is the offending Argument, block can be displayed but will of course not give me the formatting I want. I found that the Argument was the problem by sequentially removing options till the page displayed, and then cloning the VIEW again and then deleted the offending Argument option.
I then cloned it again and started looking closer at the Argument option. I then noticed that part of the option (the Argument type) was missing. I then tried to add a new Argument to recreate what used to be there. When I did this and looked at the list of fields that could be used. The list presented was not as complete as it should be, many valid CCK fields were missing
any clues as to why not all the defined CCK fields are being displayed? If I display one of the nodes of nodetype projects the fields do display correctly, so they do still exist
When I go into VIEWS and export the VIEW-block they are no longer the same. Here they both are. First the original
Original VIEWs-block
$view = new stdClass();
$view->name = 'project_grouping_block';
$view->description = 'Projects grouped by region then country.';
$view->access = array (
);
$view->block = TRUE;
$view->block_title = 'Projects by Region then Country';
$view->block_header = '';
$view->block_header_format = '1';
$view->block_footer = '';
$view->block_footer_format = '1';
$view->block_empty = '';
$view->block_empty_format = '1';
$view->block_type = 'list';
$view->nodes_per_block = '20';
$view->block_more = TRUE;
$view->block_use_page_header = FALSE;
$view->block_use_page_footer = FALSE;
$view->block_use_page_empty = FALSE;
$view->sort = array (
array (
'tablename' => 'node_data_field_project_continent',
'field' => 'field_project_continent_value',
'sortorder' => 'ASC',
'options' => '',
),
array (
'tablename' => 'node_data_field_project_country',
'field' => 'field_project_country_value',
'sortorder' => 'ASC',
'options' => '',
),
array (
'tablename' => 'node_data_field_project_county',
'field' => 'field_project_county_value',
'sortorder' => 'ASC',
'options' => '',
),
array (
'tablename' => 'node_data_field_project_city',
'field' => 'field_project_city_value',
'sortorder' => 'ASC',
'options' => '',
),
array (
'tablename' => 'node_data_field_project_name',
'field' => 'field_project_name_value',
'sortorder' => 'ASC',
'options' => '',
),
);
$view->argument = array (
array (
'type' => 'content: field_project_continent',
'argdefault' => '4',
'title' => '',
'options' => '',
'wildcard' => '*',
'wildcard_substitution' => '',
),
);
$view->field = array (
array (
'tablename' => 'node_data_field_project_country',
'field' => 'field_project_country_value',
'label' => '',
'handler' => 'content_views_field_handler_group',
'sortable' => '1',
'defaultsort' => 'ASC',
'options' => 'default',
),
array (
'tablename' => 'node',
'field' => 'title',
'label' => '',
'handler' => 'views_handler_field_nodelink',
'options' => 'link',
),
);
$view->filter = array (
array (
'tablename' => 'node',
'field' => 'status',
'operator' => '=',
'options' => '',
'value' => '1',
),
array (
'tablename' => 'node',
'field' => 'type',
'operator' => 'OR',
'options' => '',
'value' => array (
0 => 'projects',
),
),
);
$view->exposed_filter = array (
);
$view->requires = array(node_data_field_project_continent, node_data_field_project_country, node_data_field_project_county, node_data_field_project_city, node_data_field_project_name, node);
$views[$view->name] = $view;
======
New VIEWs-block
$view = new stdClass();
$view->name = 'project_grouping_block';
$view->description = 'Projects grouped by region then country.';
$view->access = array (
);
$view->view_args_php = '';
$view->page = FALSE;
$view->page_title = 'List of projects grouped by region.';
$view->page_header = '';
$view->page_header_format = '1';
$view->page_footer = '';
$view->page_footer_format = '1';
$view->page_empty = 'There are currently no projects in this region or our database is under going maintenance.';
$view->page_empty_format = '1';
$view->page_type = 'list';
$view->url = 'view/projects';
$view->use_pager = TRUE;
$view->nodes_per_page = '10';
$view->block = TRUE;
$view->block_title = 'Projects by Region then Country';
$view->block_header = '';
$view->block_header_format = '1';
$view->block_footer = '';
$view->block_footer_format = '1';
$view->block_empty = '';
$view->block_empty_format = '1';
$view->block_type = 'list';
$view->nodes_per_block = '20';
$view->block_more = TRUE;
$view->block_use_page_header = FALSE;
$view->block_use_page_footer = FALSE;
$view->block_use_page_empty = FALSE;
$view->sort = array (
array (
'tablename' => 'node_data_field_project_continent',
'field' => 'field_project_continent_value',
'sortorder' => 'ASC',
'options' => '',
),
array (
'tablename' => 'node_data_field_project_country',
'field' => 'field_project_country_value',
'sortorder' => 'ASC',
'options' => '',
),
array (
'tablename' => 'node_data_field_project_county',
'field' => 'field_project_county_value',
'sortorder' => 'ASC',
'options' => '',
),
array (
'tablename' => 'node_data_field_project_city',
'field' => 'field_project_city_value',
'sortorder' => 'ASC',
'options' => '',
),
array (
'tablename' => 'node_data_field_project_name',
'field' => 'field_project_name_value',
'sortorder' => 'ASC',
'options' => '',
),
);
$view->argument = array (
array (
'type' => 'content: field_project_continent',
'argdefault' => '4',
'title' => '',
'options' => '',
'wildcard' => '*',
'wildcard_substitution' => '',
),
);
$view->field = array (
array (
'tablename' => 'node_data_field_project_country',
'field' => 'field_project_country_value',
'label' => '',
'handler' => 'content_views_field_handler_group',
'sortable' => '1',
'defaultsort' => 'ASC',
'options' => 'default',
),
array (
'tablename' => 'node',
'field' => 'title',
'label' => '',
'handler' => 'views_handler_field_nodelink',
'options' => 'link',
),
);
$view->filter = array (
array (
'tablename' => 'node',
'field' => 'status',
'operator' => '=',
'options' => '',
'value' => '1',
),
array (
'tablename' => 'node',
'field' => 'type',
'operator' => 'OR',
'options' => '',
'value' => array (
0 => 'projects',
),
),
);
$view->exposed_filter = array (
);
$view->requires = array(node_data_field_project_continent, node_data_field_project_country, node_data_field_project_county, node_data_field_project_city, node_data_field_project_name, node);
$views[$view->name] = $view;
===============
I am running drupal 5.3(just upgraded from 5.1) Mysql-4.1.15 php-4.4.2 CCK 5.x-1.6-1 VIEWS 5.x-1.6 all on linux and apache2
Any and all clues, things to check, etc appreciated.
Comments
this is line 1581
Just to keep folks from having to dig. The RETURN statement is line 1581
-------------------
http://www.PrivacyDigest.com/ News from the Privacy Front (Drupal)
http://www.SunflowerChildren.org/ Helping children around the world ( soon to be Drupal)
opened issue & included screen grab
OK I have opened a support issue on the VIEWS queue for this and also included some before and after screen grabs to make it easier to visualize what I am talking about
http://drupal.org/node/193324
-------------------
http://www.PrivacyDigest.com/ News from the Privacy Front (Drupal)
http://www.SunflowerChildren.org/ Helping children around the world ( soon to be Drupal)
Still digging but found potentail match in DATE
I'm still digging but I have found an issue in the DATE 1.7 queue (which I also upgraded) which might be a potential match. That issue is http://drupal.org/node/189093
-------------------
http://www.PrivacyDigest.com/ News from the Privacy Front (Drupal)
http://www.SunflowerChildren.org/ Helping children around the world ( soon to be Drupal)
I had a problem with not all
I had a problem with not all CCK fields showing up in the Views argument field list, as well. After some testing, I found that if I changed line 188 of content_views.inc in the CCK module from
to
For whatever reason, not all of the fields were returned if the content_fields() was called in the foreach statement, but they are if first assigned to a variable.
I don't know if this will solve your problem or not, but it worked for me.
Hmmm
Thanks for the additional data point.
It looks like while I updated my issue I forgot to update this thread. I hadn't actually found the bug that caused the problem. But downgrading the DATE module from 1.7 to 1.6 did get me my fields back. Of course that doesn't answer the question of where the actual error was. It could just be that DATE 1.7 used a feature that something else didn't handle correctly, which might be the code twist you found.
When I get a chance I'll have to recreate my environment and see if your code update also solves my original problem
I am running Mysql-4.1.15 php-4.4.2 CCK 5.x-1.6-1 VIEWS 5.x-1.6 all on linux and apache2 Is that similar to your config?
-------------------
http://www.PrivacyDigest.com/ News from the Privacy Front (Drupal)
http://www.SunflowerChildren.org/ Helping children around the world ( Drupal)
This has been reported in
This has been reported in several places but I can't replicate it on my own installation. At any rate, we don't need lots of reports of the same problem in different places, we'll use the Date module issue as the place to work on this, http://drupal.org/node/189093.
Just posting this for anyone
Just posting this for anyone who was tracking this issue. I finally found the problem and a fix, which was just committed to the Date module dev version for all branches (4.7, 5.x, and HEAD). It will be available immediately if you get it from cvs, otherwise should show up in the dev tarball tomorrow. If I get reports back on http://drupal.org/node/189093 that the fix is working right, I'll create a new official Date module release with the fix.