1

Problem

I have a case where the dpm printout is working fine in all cases except on a specific node type, in a very specific scenario.

If I edit the node type and place dpm($form_state) in the custom node submit called by hook_form_alter, no messages display on submitting the form.

If I create the node it works fine. If I put dpm($form) in the custom node submit it works fine. It's only that exact scenario which breaks.

I've read other questions where dpm breaks, but never for something so utterly and irritatingly specific.

I've cut down my code to:

function mymodule_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id === 'mycustom_node_form_id') {
    $form['#validate'][] = 'mymodule_form_validate';
    $form['actions']['submit']['#submit'][] = 'mymodule_form_submit';
  }
}

function mymodule_form_validate ($form, &$form_state) {
  dpm($form_state);
  dpm($form);
}

function mymodule_form_submit ($form, &$form_state) {
  dpm($form_state); <-- THE PROBLEM
}

The node type itself, contains a fairly complex field collection, a bunch of ordinary fields and a fivestar field.

Can anyone provide any guesses or places to begin debugging this? I'm completely stumped.

  • Is the submit button inside of 'actions' by default? – Darvanen Feb 12 '15 at 23:47
  • 2
    Have you checked your php error logs to see if it's exceeding the memory limit (or another error)? – thumbson Feb 12 '15 at 23:57
  • @thumbson spot on. I needed to increase my maximum mysql packet. Possibly because of the large nested field collection it was running out of memory space. Feel free to add that as an answer so I can mark it as correct – Dominic Woodman Feb 14 '15 at 14:22
2

Thumbson was spot on. MySQL was hitting it's the packet limit and increasing maximum_allowed_packet in /etc/mysql/my.cnf solved the problem. (ubuntu path)

The error won't show in Drupal, the only place I could find it was in my php-fpm log. See below:

[13-Jan-2015 00:54:27] WARNING: [pool www1] child 21620 said into stderr: "NOTICE: PHP message: PHP Fatal error:  Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away' in /srv/w$
[13-Jan-2015 00:54:27] WARNING: [pool www1] child 21620 said into stderr: "Stack trace:"
[13-Jan-2015 00:54:27] WARNING: [pool www1] child 21620 said into stderr: "#0 /srv/www/eslsearch.net/public/includes/database/database.inc(2171): PDOStatement->execute(Array)"
[13-Jan-2015 00:54:27] WARNING: [pool www1] child 21620 said into stderr: "#1 /srv/www/eslsearch.net/public/includes/database/database.inc(683): DatabaseStatementBase->execute(Array, Array)"
[13-Jan-2015 00:54:27] WARNING: [pool www1] child 21620 said into stderr: "#2 /srv/www/eslsearch.net/public/includes/database/database.inc(2350): DatabaseConnection->query('SELECT expire, ...', Array, Array)"
[13-Jan-2015 00:54:27] WARNING: [pool www1] child 21620 said into stderr: "#3 /srv/www/eslsearch.net/public/includes/lock.inc(167): db_query('SELECT expire, ...', Array)"
[13-Jan-2015 00:54:27] WARNING: [pool www1] child 21620 said into stderr: "#4 /srv/www/eslsearch.net/public/includes/lock.inc(146): lock_may_be_available('schema:runtime:...')"
[13-Jan-2015 00:54:27] WARNING: [pool www1] child 21620 said into stderr: "#5 /srv/www/eslsearch.net/public/includes/bootstrap.inc(433): lock_acquire('schema:runtime:...')"
[13-Jan-2015 00:54:27] WARNING: [pool www1] child 21620 said into stderr: "#6 /srv/www/eslsearch.net/public/includes/bootstrap.inc(455): DrupalCacheArray->set(Array)"
[13-Jan-2015 00:54:27] WARNING: [pool www1] child 21620 said into stderr: "#7 [internal function]: DrupalCacheArray->__destruct()..."
  • Glad to help! It's good to this in mind when using dpm with large objects/arrays if you notice the output is not what you expect, or isn't updating like you think it should. – thumbson Feb 14 '15 at 15:06
  • I think what got me was the fact it only broke in a specific certain function. Of course now you've said it, it makes perfect sense... – Dominic Woodman Feb 14 '15 at 17:26
  • I have run into this with a custom submit handler on an incredibly simple content type: title and body only. Not sure this answer completely satisfies the question. A dpm of the $form_state shouldn't result in a massive packet of data shutting down the page load. Does anyone actually know how/why this happens, even with a super-simple content type? How else can you explore the $form_state to write the custom submit handler? Should you really be expected to increase the max_allowed_packet value just to see the info you need? I've been dpm'ing in Drupal forever and never run into this until now. – scotself Jun 7 '18 at 19:11

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.