5

I'm making a custom validation in a form I'm making but my error message is always delayed by one page refresh.

$form['submit']['#validate'][] = 'asap_sollicitation_form_validate';


function asap_sollicitation_form_validate($form, &$form_state)
{
    if(strlen($form_state['values']['pass']) < 6){
        form_set_error('pass', t('Must be longer than 6'));
    }   
}

It successfully marks the field in red but the message is delayed. If I use only drupal_set_messsage without the form_set_error I do get a message displayed in time. I render my form in a node template:

$arr = drupal_get_form('asap_sollicitation_form');
print drupal_render($arr);

How can I get my message to display after form submit?

  • Try seeing if $_SESSION['message'] is being set on the next page load. drupal_set_message() just sets a $_SESSION['message'][]. – Steven May 16 '14 at 13:02
  • Do you have '#title' fields in your form array, if not can you add that and try. Drupal is using that field to figure out I think. – abhiklpm Feb 13 '15 at 19:31
  • Another problem might be Error messages aren't actually being generated until after the call to drupal_get_form() was made. Because this call was inside the template, they were not set for the template to display. Check this link also for a solution: embiggen.net/post/fix-drupal-form-error-messages-not-showing – abhiklpm Feb 13 '15 at 19:38
  • Adding forms in the theme layer is wrong, and it is the root of your problem. Use hook_node_view instead.. – rreiss Oct 10 '15 at 20:27
3

I had the same, here is the solution and explanation: The key of this problem is the drupal_get_form('FOO') is called in theme layer. For example _preprocess_WHATEVER or directly in BAR.tpl.php

The messages are prepared in _process_page() After that it's unchangeable in deeper theme functions, like FOO_preprocess_node. (That's not exactly true, but it's out of scope of this topic.)

I bet, you prepared a variable by drupal_get_form('FOO') in _preprocess_node, maybe later.

You should use hook_entity_view_alter or hook_node_view_alter, maybe hook_page_alter if necessary, anything else than theme hooks.

Just for the record: The last time you are able to set a message by drupal_set_message() is _preprocess_page

0

This might be relevant to you, or if not maybe it will help someone else who comes across this.

If you're calling the form through a block, which is rendered in a tpl.php as opposed to with drupals block system, context or panels, then the messages will be delayed a page. (Presumably because you call the block too late in the generation process? not quite sure why.)

My workaround was to place the block on the page with context so it appeared naturally, then hide that and have people use the correctly placed block.

i.e. You need a block to be generated inside the HTML of a template (perhaps for jquery tabs) so you might call it template.php and then render it in your tpl.php.

Example code that would cause this problem.

Template File

function theme_preprocess_entity_profile2(&$vars, $hook) {
  //profile2 preprocess function
  //invoking the block from the correct module and storing it
  //to be accessible in the tpl.php
  $vars['my_form_module_var'] = module_invoke('form_module', 'block_view', 0);
}

Tpl.php file

<div class="my-class"><?php print render($my_form_module_var['content']); ?></div>
0

I ran into this issue as well. I had an unthemed tpl.php file in a custom module. I was outputting a webform using the following code

$objMessages = drupal_get_messages();
...error output code...

webform_node_view($node,'full'); 
print theme_webform_view($node->content);

I could not get the validation error messages to output until the following page. After reading the above answers, I realized that I need to rearrange the code as such

//process the form first to send
//error messages to the session vars
webform_node_view($node,'full'); 

$objMessages = drupal_get_messages();
...error output code...

print theme_webform_view($node->content);
-3

If drupal_set_message() is working for you then you should use it. You can pass a second parameter to the function to control which type of message drupal will display.

string $type: (optional) The message's type. Defaults to 'status'. These values are supported:

'status'

'warning'

'error'

Also, form_set_error() calls drupal_set_message() with a $type = 'error' so it may be that there is something else causing 'error' type messages to be suppressed.

  • Thanks but then I'm unable to mark my field red. Whenever I use drupal_set_message in combination with form_set_error the messages are both delayed. Error messages of required fields that Drupal handles also come one refresh late. – Yassin Tahtah May 15 '14 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.