Using Latest PHP 5.4 with MySQL 5.5.22 + D6: Illegal string offset 'min' *Resolved*

The rest of the code:

/**
 * Turn a range field into a select dropdown. This assumes that the $options array
 * is going to be something like: array('5,9' => '5 to 9 lbs') where the index is
 * a comma delimited string of the min/max values.
 * Pass in $optional = TRUE if you want there to be an <any> value at the top of
 * the select dropdown. Defaults to TRUE.
 */
function ubercart_prod_search_range_to_select($field, $options, &$form, &$form_state, $optional = TRUE) {
    $form[$field]['#type'] = 'select';
    if ($optional) {
        $options = array_merge(array('All' => '<Any>'), $options);
    }
    $form[$field]['#options'] = $options;
    unset($form[$field]['min']);
    unset($form[$field]['max']);
    $f = $form_state['input'][$field];
    $f ? $form[$field]['#value'] = $f : true;
    $form[$field]['#element_validate'] = array('ubercart_prod_search_range_validate');
}

/**
 * Turn values created by range_to_select back into ranges so that Views can process
 * the request. This assumes that if the value passed in is 'All' the min/max array
 * should be set to array('min' => '', 'max' => '')
 */
function ubercart_prod_search_range_validate($element, &$form_state) {
  if (($v = $element['#post'][$element['#name']])) {
    if ($v == 'All') {
      $min = '';
      $max = '';
    }
    else {
      list($min, $max) = explode(',', $v);
    }
    $form_state['input'][$element['#name']] = array(
      'min' => $min,
      'max' => $max,
    );
    $form_state['values'][$element['#name']] = array(
      'min' => $min,
      'max' => $max,
    );
  }
}

This is how the Query looks:

# User@Host: al_admin[al_admin] @ localhost []
# Query_time: 0.001329  Lock_time: 0.000095 Rows_sent: 0  Rows_examined: 1107
SET timestamp=1334679442;
SELECT node.nid AS nid,
   node.type AS node_type,
   node.vid AS node_vid,
   node.title AS node_title,
   uc_products.sell_price AS uc_products_sell_price,
   uc_products.height AS uc_products_height,
   uc_products.length_units AS uc_products_length_units,
   uc_products.width AS uc_products_width,
   uc_products.ordering AS uc_products_ordering,
   'searchproducts:default' AS view_name
 FROM node node
 LEFT JOIN uc_products uc_products ON node.vid = uc_products.vid
 WHERE (node.type IN ('product')) AND (node.type in ('product')) AND (uc_products.height >= 0) AND (uc_products.height <= 0) AND (uc_products.width >= 0) AND (uc_products.width <= 0) AND (uc_products.sell_price >= 0) AND (uc_products.sell_price <= 0)
   ORDER BY uc_products_ordering ASC
 LIMIT 0, 12;

Manually running the above Query in MySQL also returns no results!

However, this modified MySQL Query works:

SELECT node.nid AS nid,
node.type AS node_type,
node.vid AS node_vid,
node.title AS node_title,
uc_products.sell_price AS uc_products_sell_price,
uc_products.height AS uc_products_height,
uc_products.length_units AS uc_products_length_units,
uc_products.width AS uc_products_width,
uc_products.ordering AS uc_products_ordering,
'searchproducts:default' AS view_name
FROM node node
LEFT JOIN uc_products uc_products ON node.vid = uc_products.vid
WHERE (node.type IN ('product')) AND (node.type in ('product')) AND (uc_products.height >= 0) AND (uc_products.height <= 10000) AND (uc_products.width >=0) AND (uc_products.width <= 100000) AND (uc_products.sell_price >= 0) AND (uc_products.sell_price <=10000)
ORDER BY uc_products_ordering ASC
LIMIT 0, 12;

So what do do to get Views to do that [range]?

Peter

The above code worked fine with older MySQL + PHP

History / Background:

New Server: PHP 5.4.0 + MySQL 5.5.12 @ InnoDB
Old Server: PHP 5.2.17 +MySQL 5.0.51a @ MyISAM

Drupal [Pressflow] 6.25 + MySQL Database was migrated from an older Server -
with PHP 5.2.17 +MySQL 5.0.51a to New Server with PHP 5.4.0 + MySQL 5.5.12.

Notes: Prior to this all current D6 module updates applied.

The custom Views search_form_alter() Hook run correctly
on the old server; but on the new server the default <All>
returned no query results for numeric ranges . Works
fine on selected values [numeric].

With the Views search_form_alter(), Text ranges <All> is fine!

So I can debug this issue, in what part of 'Views' is the
page URL/searchproducts?sell_price=All translated to:

LEFT JOIN uc_products uc_products ON node.vid = uc_products.vid
WHERE (node.type IN ('product')) AND (node.type in ('product')) AND (uc_products.height >= 0) AND (uc_products.height <= 0) AND (uc_products.width >= 0) AND (uc_products.width <= 0) AND (uc_products.sell_price >= 0) AND (uc_products.sell_price <= 0)

Using grep, I suspect I need to start debug in one of the following Views files:

modules/taxonomy/views_handler_filter_term_node_tid_depth.inc
modules/taxonomy/views_plugin_argument_validate_taxonomy_term.inc

After a lot of debugging, I have determined that the issue lies with the
#element_validate which run's a function before the submission.

At this point, using the D6 views 'between' filter, the very first value [character]
of the ['max'] value is inserted - and over writes the first value [character]
of the ['min'] value. Effectively 'corrupting' the intended 'min' value of the 'between'
Views filter. Only the very first character value of 'min' is effected - and it always uses
the very first character of the 'max' value - submitted.

At the moment, I cannot back-trace enough code to see what is causing this.

** Issue Resolved **

This is a Views 6.x-2.x-dev PHP 5.4.x Bug.
Tested, back-traced, and proven!

Fix / Patch: [crude-but it works]
--------------------------------------

In the Views Tree: file => /handlers/views_handler_filter_numeric.inc

Change these lines:

      if ($which == 'all') {
        $dependency = array(
          '#process' => array('views_process_dependency'),
          '#dependency' => array($source => $this->operator_values(2)),
        );
        $form['value']['min'] += $dependency;
        $form['value']['max'] += $dependency;
      }
      if (!empty($form_state['exposed']) && !isset($form_state['input'][$identifier]['min'])) {
        $form_state['input'][$identifier]['min'] = $this->value['min'];
      }
      if (!empty($form_state['exposed']) && !isset($form_state['input'][$identifier]['max'])) {
        $form_state['input'][$identifier]['max'] = $this->value['max'];
      }

To this:

(basically, this 'change' checks that the item is an array - first).

      if ($which == 'all') {
        $dependency = array(
          '#process' => array('views_process_dependency'),
          '#dependency' => array($source => $this->operator_values(2)),
        );
        $form['value']['min'] += $dependency;
        $form['value']['max'] += $dependency;
      }
      if (!empty($form_state['exposed']) && !isset($form_state['input'][$identifier]['min'])) {
+        if(is_array($this->value['max'])) {
            $form_state['input'][$identifier]['min'] = $this->value['min'];
+        }
      }
      if (!empty($form_state['exposed']) && !isset($form_state['input'][$identifier]['max'])) {
+          if(is_array($this->value['max'])) {
          $form_state['input'][$identifier]['max'] = $this->value['max'];
+        }
      }

The actual PHP5.4.x warning:

Illegal string offset 'min' in views_handler_filter_numeric->value_form() (line 193 + 196 of /var/www/virtual/artlogic.com.au/sites/all/modules/views/handlers/views_handler_filter_numeric.inc).

I originally ignored this simply because it only maked as a PHP 'warning', but it turns out that while PHP 5.3.x would overlook if an item was not an array, PHP 5.4.x it now throws this warning [which becomes an code error] when it’s expecting an array (for 'min' in this case).

This is the patch that got things working for me. I know the developers will improve it.

Moving this thread to a Views 'Bug' status! Then possibly a patch (or a series of for PHP 5.4.x)

Well, PHP 5.4.1 is to be released on the 26th of April 2012.

Some Drupal users /innovators may already be moving to PHP 5.4.0.
(I have -though there are not many - yet)

Was marked as 'Critical' because Views will 'break code' under PHP 5.4.x (read 'error').

See http://drupal.org/node/1543434 for a full update

Refer #15

Quote: "Does it whitescreen?"

Answer:
Before the patch, no results are returned - on the above 'Views query'.
Not it does not 'whitescreen' in that sense, just no data on the return()