Undefined index in line 132 visualization_plugin_style

I got the same problem for this.
have you used views's math in your views?

Hi
I spend some time to make a patch for this.
this patch is works well for me, And I hope it can solve the problem.

where i write it ?

Have installed the combo Commerce Reports and Visualisation, but instead of the required reports I get a white screen of death as well as the message below. Cannot tell for sure, but it looks related to what this thread is about, otherwise let me know.

Notice: Undefined index: order_id in visualization_plugin_style->build_sort() (regel 130 van /storage/web/public/sites/www.slapeninyerseke.nl/sites/all/modules/visualization/includes/views/visualization_plugin_style.inc).

Patch #2 solved the issue mentioned.

Patch from #2 works fine. Is there any chance it will be committed?

Hello,

Got similar issue with Rules module when i add an action "Load a list of entity objects from a VBO View.". It-s a simple VBO view with only node nid.

Notice : Undefined index: field_custom dans visualization_plugin_style->build_sort() (line 150 in /var/www/mysite/sites/all/modules/visualization/includes/views/visualization_plugin_style.inc).

But errors are caused because the variable $field don't exist in the VBO views
$handler = $this->display->handler->handlers['field'][$field];

Added this condition below in the public function buid_sort() resolved this warnings

if (!isset($this->display->handler->handlers['field'][$field])) {
  return FALSE;
}

The complete function become

/**
   * Adds sorting to the individual fields.
   */
  public function build_sort() {
    foreach ($this->options['fields'] as $field => $option) {

      if (!isset($this->display->handler->handlers['field'][$field])) {
        return FALSE;
      }

      $handler = $this->display->handler->handlers['field'][$field];

      if ($option['sort'] && $handler->click_sortable()) {
        $handler->click_sort($option['sort']);
      }
    }

    return FALSE;
  }

Hello all,

For those who don't know me, checkout #2042155-9: Looking for new co-maintainers ... Not sure (yet) if I should add "... and maybe wish me good luck?".

This issue is a perfect example for me regarding the current status of this module: a bug, with a patch to solve it, hanging in the issue queue for way too long time. Of course I understand things evolve over time, so all respect for @cvangysel for what he achieved so far with this module ('Dank U wel' Christophe ... aka 'thank you' for those who are not good in the language from the land/region where Drupal was born ... aka Flemish/Dutch).

OK, time to move on: thank you Zhang for your patch in #2. By just looking at it, it appears to me that it prevents the original problem from happening, i.e. in line 132 (which I'm adding to the title here). I do not agree however that an "undefined index" is only a minor bug (as the update in #6 suggests). The contributed fix is a 'minor' change in the code (but the challenge that Zhang addressed was to pinpoint the exact line to at least prevent the error in 132). To be honest I'm not convinced that this is going to turn out the best fix, because it doesn't answer my current question like "Can we prevent the need to add such isset test?". But it IS a fix, and therefor for me "way better then nothing".

Also, I'm not convinced (actually rather doubt) that the error in #4 is going to be solved by this patch, mainly because it is line 130, not 132. Hallo Theo van in de buurt van Yerseke! (Oeps ... back to English ... Just saying hello to Theo who seems to be from somewhere close to where I live).

Similar reply for Flocon regarding #7. Bonjour Flocon, comment vas-tu? (similar oeps ...). That appears to me like ANOTHER issue, though fairly similar. I need more time to digest what exactly the proposed fix for that was. But it would help me speed up things if (a) anybody could confirm that issue (in line 150 this time) also and (b) submit the proposed fix in patch format. Sure 'I' can some day massage what I see as proposed fix in a patch, but anybody looking for ways to help get an official release out of the door, these kind of tiny things help.

So I'm updating the status for this issue (= answer to Dmitriy in #6), but I'm going to concentrate in "this" issue on line 132. If that patch does not fix the issue about 130 and 150, and no other patch is added to this issue, then I'll expect a new issue to be created for each of those 2 related issues (just pointing to the appropriate comment in this issue here is fine for me). That way we tackle 1 problem in 1 issue, makes things more manageable. If in the meantime RTBC-patches for either line 130 and/or 150 get added to this issue, then I'd be happy to process them also as part of this issue (while we're working on it).

1 more request to anybody following this issue: where is the docu about this module? I've found 1 youtube video, but not any community docu so far. And also: what are the modules (project URLs please) that use this module as a "Native Charting Module"? Note: some day I want this module to be added as a next column there, right now it doesn't meet the criteria because of its alfa status ... Help to achieve that goal soon is welcome!

OK, enough as a first intro to "my style" of getting issues like this one solved? If you like my style, please add some type of feedback (like only a +1 ?) to #2042155-9: Looking for new co-maintainers. If you do not like my style, please let me know also, OK?

Pierre

PS1 to Zhang: I'm sorry I even don't know 1 word in your language, how do I say "hi" or "hello" in yours (with "my" keyboard)?

PS2: anybody knows how to launch another wakeup call to @cvangysel? To tell him about the other issue waiting for his feedback / approval. I'm really trying to prevent the "default" action being applied (about pursuing the abandoned project process further with the goal to make Pierre.Vriens the project owner), which is planned in about 5 days from now, as mentioned in #2445395-3: Offering to maintain module Vizualisation API. I'd hate that transition for this project, but I will go ahead as instructed #2445395-6: Offering to maintain module Vizualisation API as a last resort. Anybody against that approach: please speak 'now' ...

Extra question: this project uses simple test, great! I'm not familiar with it yet and would like to learn about it. Any link suggestions about docu (on D.O ?) to get started with it?

Does Visualization API - Views style plugin really needs this sort options?
We could easily use standart Views sorting options, and so this 'bugs' would dissapear as I understand.

visualization_plugin_style::build_sort() method was removed as redundant. Now to sort data you can use default Views sort options.
So, errors and warnings that were mentiond above could not be reproduced anymore.

Fixed, as I assume.