Exposed filters not being applied in Preview

I'm gonna try to deal with this...(or souldn't i? ;-)

Tested with other Filters (e.g. Content: Published)--> the same situation.

Well, this issues are caused by the separation of the forms in the preview, one containig the checkbox 'Auto preview' and the textbox 'Preview with contextual filters' (FAPI ID views_ui_edit_form) and the otherone the exposed filters + preview results (FAPI ID views_ui_edit_form), there also some comments and @todo in the code related to this.
All exposed input is gadered in admin.inc

 118  // AJAX happens via $_POST but everything expects exposed data to
 119   // be in GET. Copy stuff but remove ajax-framework specific keys.
 120  $exposed_input = $_POST;

First of all it's clear that is not gonna work for non-JS users since the form containig the exposed filters has the method set to get (views_plugin_exposed_form.inc line 117), $_POST is empty when submiting the form, this no happening in the 'normal page' (not preview) becouse the the request is handle by a different callback.
On the other hand the approach to JS-users also fails becouse when clicking the 'Apply' or 'Reset' button the click on the 'Update preview' button is triggered (via ajax) submiting the form views_ui_edit_form and not views_ui_edit_form, wich contains the exposed filters, the 'normal page' works here becouse differents js files are included depending on the situatuion (ajax.js for views ui in contrast to ajax_view.js in the normal page), this is the good news ;-)
Well, here is a solution althoug i think a more consistent approach could be developed.

1. Remove the ajax behavior of the Apply button (we'll do it with FAPI) in ajax.js, leave the reset (not so consistent:-(

      // Within a live preview, make exposed widget form buttons re-trigger the
      // Preview button.
      // @todo Revisit this after fixing Views UI to display a Preview outside
      //   of the main Edit form.
 182   - $('div#views-live-preview input[type=submit]')
    

      // Within a live preview, make exposed widget form buttons re-trigger the
      // Preview button.
      // @todo Revisit this after fixing Views UI to display a Preview outside
      //   of the main Edit form.
182    + $('div#views-live-preview #edit-reset')
   

2. Add the ajax behavior to the Apply button in views_plugin_exposed_form.inc

    $form_state['pager_plugin'] = $pager;
  }
236 +  // If we are in live preview give the buttons ajax behavior, if not do nothing,
      +  // views_ajax takes care.
      +  if (isset($this->view->live_preview) && $this->view->live_preview == TRUE)  {
      +      $q = 'admin/structure/views/view/' . $this->view->name . '/preview/' . $this->view->current_display . '/ajax';
      +      $form['submit']['#ajax']  =  array (
      +          'path' => (!empty ($this->view->args)) ? $q . '/' . implode('/', $this->view->args) : $q,
      +          'wrapper' => 'views-preview-wrapper',
      +          'event' => 'click',
      +          'progress' => array('type' => 'throbber'),
      +          'method' => 'replace',
      +      );
      + }

3. Now both forms are passing throug views_ui_build_preview in admin.inc -> attempt to discriminate between them and handle contextual filters and exposed filters input mapping them to the right variables.

  $build = array(
    '#theme_wrappers' => array('container'),
    '#attributes' => array('id' => 'views-preview-wrapper', 'class' => 'views-admin clearfix'),
  );
895 + if (!isset($_POST['form_id'])  ||  ($_POST['form_id'] != 'views_ui_preview_form')) {
      +     $_POST['view_args'] = implode('/', array_slice(func_get_args(), 2));
      + }

4. Adjusting the way the exposed input is handle in admin.inc function views_ui_preview , since there are now two forms $_POST could contain contextual filters and no more (e.g. the user enters a parameter and click 'Update preview'). Also remove the 'hack', (no such a variables in $exposed_input), but leave the form_id for consistency.

          // AJAX happens via $_POST but everything expects exposed data to
          // be in GET. Copy stuff but remove ajax-framework specific keys.
 120     - $exposed_input = $_POST;
 120     + // If the user is updating the preview to incorporate parameters (contextual filters)
           + // DON'T asume the exposed input come from $_POST, just live the exposed_input empty
           + if (empty($_POST) || (isset($_POST['form_id']) && $_POST['form_id'] == 'views_ui_preview_form')) {
           +     $exposed_input = array();
           + }
           + else {
           +     // $exposed_input is comming from $_POST
           +     $exposed_input = $_POST;
           + }

126    - // @todo Remove this hack after fixing Views UI to display the preview
         - //   outside of the edit form, so that the edit form doesn't conflict with
         - //   the exposed widget form.
           $exposed_input['form_id'] = 'views_exposed_form';
         - unset($exposed_input['form_build_id'], $exposed_input['form_token']);

5. Also we have to add the default value to the 'Update preview' form element ('Apply' refresh the whole container).

1146  -  //      '#attributes' => array('class' => array('ctools-auto-submit')),
        +  '#default_value' => $form_state['input']['view_args'],

6. Finally, in view.inc function get_exposed_input, this is important for non-JS users

           // Fill our input either from $_GET or from something previously set on the
           // view.
   199   + if (!isset($this->exposed_input) || empty ($this->exposed_input)) {
           +    $this->exposed_input['form_id'] = 'views_exposed_form'; 
           + }
   
           -   if (empty($this->exposed_input)) {
           -       $this->exposed_input = $_GET;
   
           +   if (count($this->exposed_input == 1) ) {
           +      $this->exposed_input += $_GET;
   

Done!

Fixing an undefined index in the first run.

Let's see, i was testing this patch (#9) and it doesn't work pretty well (apart of the formating thing) -and for you?
Before let's try to agree in the logic (in a simplified flow):
There are two FORMS: one $_POST (views_ui_edit_form) and one $_GET (views_ui_edit_form)

1. The user build the view, introduce arguments and click 'update preview'- only the content of the textfield is sent to the server.

What happens actually is that arguments are appended to the url of the $_GET form.

2. The user wants to test the exposed filters and now clicks 'apply' - all the info in exposed filters is sent to the server (here there is a problem with #9 for JS users becouse the whole container is refreshed so parameters of the $_POST form are lost)

Question:
Shoud we nice degradate when no-JS-preview? I would say yes. At the momment views only degradate (but not so nice e.g. only the preview is rendered but not the view-edit-form)

Drupal uses 2 spaces here.

OK.

What is the reason to remove it?

Now the information comes separately, there is no need to do it becouse those values are beeing posted only when clicking 'update preview' and in this case we want them (why shoudn't we?), if 'Apply' is clicked then this values are not posted (why attempt to remove them if they don't exist).

A comment would be cool here

What about something like:

// There are two form information passing through this function:
// views_ui_edit_form and views_ui_edit_form, 
// attempt to descriminate between them.

!isset is also empty, so why is here a check for both?

Good catch!
Thanks guys for the review!!

@jpstrikesback, we're almost there ;-)
Did you try the patch and realize 2. of #14??
Thanks!

Patch #16 seems to be working very well (NOT the reset, we would have to file an issue report for this one) and compliant with the logic in #14.
It also degradates (like before said NOT nice) for non-JS users.
I say we commit it.

;-)

Crossposting:
#1188532: Reset button not working in Preview