After upgrading to Drupal 6.19, I started getting some non-fatal PHP warnings in cases where variables were not defined. I've attached a patchfile with the changes I made to make the warnings go away.

CommentFileSizeAuthor
#2 views-2.patch750 bytessheldon rampton
php_notices.patch951 bytessheldon rampton

Comments

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Needs work

they will not apply on views 6.x-3.x Could you also try to make a patch for them? Thanks!

sheldon rampton’s picture

sheldon rampton commented
StatusFileSize
new views-2.patch750 bytes

OK, try this.

dawehner’s picture

dawehner
Primary language German
commented

And what about the change in includes/query.inc?

sheldon rampton’s picture

sheldon rampton commented

File "includes/query.inc" no longer exists in views 6.x-3.x, so there's nothing to patch there. The second patch I supplied was for 6.x-3.x.

dawehner’s picture

dawehner
Primary language German
commented

Well this kind of code could be in plugins/views_plugin_query_default.inc in views3

sheldon rampton’s picture

sheldon rampton commented

dereine, I looked in plugins/views_plugin_query_default.inc. The code that's in there has been significanly altered from the code that used to be in includes/query.inc. In particular, the places where a PHP warning message might occur have been wrapped in "if (isset()" statements similar to the code that I added in my patch. So, if that's where the code from includes/query.inc has landed, it has already been fixed. The only thing that still needs to be patched in 6.x-3.x, therefore, is the code that's in the "views-2.patch" file that I uploaded above.

dawehner’s picture

dawehner
Primary language German
commented

So next step.
I'm wondering whether it makes sense to automatically generate a widget->id if there is none.

sheldon rampton’s picture

sheldon rampton commented

I can't speak to that. I don't know the Views code well enough. I just wrote a patch to stop PHP from kicking out the warning message.

dawehner’s picture

dawehner
Primary language German
commented

I'm pretty sure the second part is already part of another issue.

The first patch might hide a bug. Which kind of fields doesn't have #id set?

john franklin’s picture

john franklin commented
Issue summary: View changes

I see it with some date_popup exposed filters. The date_popup widgets themselves have an '#id' value, but they live in a sub-array named after their filter identifier. That is, I see this an array structure like this, transcoded by hand from a dpm() output to php:

$form[$field_identifier] = array(
  '#tree' => TRUE,
  'value' => array(
    '#type' => 'date_popup',
    '#id' => 'edit-' . $field_identifier . '-value',
    /* ... other stuff ... */
  ),
  'default_date' => array(
    '#type' => 'value',
    /* ... other stuff ... */
  ),
  default_to_date => array(
    '#type' => 'value',
    /* ... other stuff ... */
  ),
  /* other stuff, but no #id entry */
);
chris matthews’s picture

chris matthews commented
Status: Needs work » Closed (outdated)

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue

chris matthews’s picture

chris matthews commented

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue