Exposed form options - Text on demand does not show

Could you please clarify what you mean with "the text on demand"?

Same here: previously set text on demand in exposed form style when input is required is not displayed anymore after update to 3.4-3.5.

please, let us know how to fix this issue: when exposed form is set to input required and the text on demand is given (text to display in the view before any user input is made) it is not displayed anymore in versions 3.4-3.5.

Same here, did anybody found a solution or fixed it? I did the update from 3.3 to 3.5 and the "Text on demand" is missing.

EDIT: I made a diff between 3.3 and 3.5 and found some changes in the empy result-behavior. I think it has something to do with one of these changes, as the Text on demand should be displayed in the $empty-var.

Confirming issue.

• Drupal 7.15
• Views 7.x-3.5+23-dev
• View of [Content] displaying [Fields] as 'Page'
• Various exposed filter criteria (taxonomy, fields)
• Form set to 'Input Required'
• Text on Demand entered
• Exposed form in block (also tested with exposed form in Block set to 'No')

Text on Demand does not appear.

Also confirmed on -dev, bumping priority as this might break functionality on sites updating to views to 3.5+.

A quick look reveiled that views_plugin_exposed_form_input_required->query() never gets called.

Mind the comment in this piece of code:

  function query() {
    if (!$this->exposed_filter_applied()) {
      // We return with no query; this will force the empty text.
      $this->view->built = TRUE;
      $this->view->executed = FALSE;
      $this->view->result = array();
    }
    else {
      parent::query();
    }
  }

This might be related to this issue: #1877678: Exposed filter gets error class without submitting it

Small follow-up: it seems to be broken since the 3.4 release.

I am running Drupal 7.19 and Views 3.5. I can reproduce this issue. I set up Exposed form style:Input required and it's not displaying the configured Text on demand. It is running both pre_render and query in views_plugin_exposed_form_input_required. I can't tell why since I'm not an expert in Views, but this adding the text in a hook_views_post_render worked for me.

Example:

function mymodule_views_post_render(&$view, &$output, &$cache) {
 if ($view->name == 'my_view' && empty($view->exposed_raw_input['my_input'])) {
    $output .= $view->display_handler->handlers['empty']['area']->options['content'];
  }
  return $output;
}

I think I've narrowed it down to the render function in the views_render_area_text class (views_handler_area_text.inc)

  function render($empty = FALSE) {
    $format = isset($this->options['format']) ? $this->options['format'] : filter_default_format();
//    if (!$empty || !empty($this->options['empty'])) {
      return $this->render_textarea($this->options['content'], $format);
//    }
//    return '';
  }

If I comment out the lines above, the Text on demand show properly.

Haven't investigated enough to know if there are side effects to commenting out the lines, but it seems to work in the way it should.

The "solution" suggested in #12 works for me, but like dppeak says I am not sure of the ramifications of commenting out those lines...

By the way, I am using Views 7.x-3.6.

I think the assumption was that if $empty was true and there was a value for $this->options['empty'] that there would not be anything that needed to be rendered but it didn't account to actually check it there was anything in $this->options['content'] which is where Text on demand is so this should account for it.

  function render($empty = FALSE) {
    $format = isset($this->options['format']) ? $this->options['format'] : filter_default_format();
    if (!$empty || !empty($this->options['empty']) || !empty($this->options['content'])) {
      return $this->render_textarea($this->options['content'], $format);
    }
    return '';
  }

And the patch.

I can't speak to the test failure, but that last patch makes sense to me and works. Let's see if a maintainer can provide input on this one.

The reason the patch fails is this:

This is modifying an area handler. The area handler relies on whether or not the view is empty, not whether it, itself, is empty, on whether or not to appear. There is a flag ($this->options['empty']) to override this. This patch destroys that functionality.

Obviously, colan doesn't care about other functionality being destroyed, or he wouldn't have set it RTBC without investigating what test failed.

Adding 'empty' => TRUE to the $options in views_plugin_exposed_form_input_required::pre_render() probably fixes this, if anyone wants to try that instead.

Thank you merlin! Never would have tracked that one down. Though I am slowly starting to understand views little by little.

Probably going to need to apply this over at #1447730: Add 'input required' option/functionality as well. As a matter of fact I'm off to do that now.

Go speed test bot go!

@merlinofchaos: It's not that I don't care so much as I wanted your help to point us in the right direction. Sorry if that was a less-than-elegant way to get your attention.

In any event, it certainly did the trick.

This seems pretty great! I guess for d8 we need a proper test for that, but for d7 this seems okay.

I manually tried and indeed this fixes the issue.

That's committed and pushed to 7.x-3.x
For Drupal 8 we need a test to ensure this never happens agan.

add tests

I'm using views 7.x 3.7 on drupal 7.19 and this problem still pending.

After applying patch from comment #20, all seem to be ok.

Is patch from comment #23 really applied on 7.x branch ?

@mjobber This was committed in May 7.x-3.7 was released in April. If you need this change then you need to run the -dev version or wait for the next release.

I need this fix in my website ASAP. Can I apply patch #20 for now and successfully upgrade to Views 3.8 when it is next released?

@gumdal, I don't see why not. As always, first try this on your test/dev environment before using it on a production site!

Patch from #20 works as expected in Drupal 7. Kind of surprised this hasn't found its way into a release in the last over-a-year.

Hi, patch from #20 seems to be in current views. Is there any chance to hook the function in a way the empty text from views (no result behaviour) is used?
Tried to put a php return false in this field, but than nothing is shown ...

Created patch form http://cgit.drupalcode.org/views/commit/?id=d66421e

Unrelated fail

Fatal error: Call to a member function isActive() on a non-object in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/user/src/Tests/UserCreateTest.php on line 115
FATAL Drupal\user\Tests\UserCreateTest: test runner returned a non-zero error code (255).

Now with test fix.

Looks nice!

Updated the issue summary, removed the update issue summary tag, added needs screenshots tag.

I am unable to test this issue. I followed the steps in #8, I am still not able to figure out what "text on demand" means.

This is the test view I have created:

And I thought #8 "Text on Demand" was telling about this:

Text on demand can be found under:
Advanced > Exposed form style : set to 'Input required'
Then
Advanced > Exposed form style > settings

This text shows up, so I think this bug is fixed, but when initially loading the page, it gives an empty error message and a red form field. This should only happen after submitting the search form.
Will look if there is an issue open for that.

However, you are getting an error....How do I eliminate the error?

I am getting the same error and can't find way to fix it. Has anyone found a solution to that problem? I.e., how to avoid validation error before any input has even been made.

Anyone? Please :)

I have finally found a solution that seems to work just fine. I used the patch of user dawehner, suggested at: https://www.drupal.org/project/views/issues/1169092#comment-4932422

It should be noted that the suggested code has already been included in D8 (in /core/modules/views/src/Plugin/views/filter/FilterPluginBase.php), but in a little different way. I had to "reverse" the code back to the original suggestion of dawehner (switching required with optional, etc.) and it worked for me.

I hope that's a permissible way to do it and that it would help others :)