Maintainers of any module that handles files always has the problem of the issue related to file upload sizes. One by one, solutions have been found to all, with the exception with max_post_size. Since PHP drops the entire $_POST array, AHAH requests fail to load the cached form and standard form submissions result in complete loss of all form data.
I'm have also had issues with this, but checks on anything after the max size of $_POST is exceeded is almost pointless as the entire reference to the form build id is lost. The only solution that I have found so far is to change theme_form to append the action with the build id. This ensures that this is never lost and a failed POST can be detected.
The attached patch simply tags the form with the form build id so that it is always passed back to the server on form submission.
<?php
// Original
function theme_form($element) {
// Anonymous div to satisfy XHTML compliance.
$action = $element['#action'] ? 'action="' . check_url($element['#action']) . '" ' : '';
return '<form ' . $action . ' accept-charset="UTF-8" method="' . $element['#method'] . '" id="' . $element['#id'] . '"' . drupal_attributes($element['#attributes']) . ">\n<div>" . $element['#children'] . "\n</div></form>\n";
}
// Modified
function theme_form($element) {
// PHP drops the $_POST array if this exceeds the PHP setting post_max_size.
$action = '';
if ($element['#action']) {
$action = 'action="' . check_url($element['#action']) . (strpos($element['#action'], '?') !== FALSE ? '&' : '?') . 'form-id=' . check_plain($element['#build_id']) . '"';
}
// Anonymous div to satisfy XHTML compliance.
return '<form ' . $action . ' accept-charset="UTF-8" method="' . $element['#method'] . '" id="' . $element['#id'] . '"' . drupal_attributes($element['#attributes']) . ">\n<div>" . $element['#children'] . "\n</div></form>\n";
}
?>
So with the modifications, a var_dump on $_GET and $_POST normally will result in something like:
<?php
var_dump($_GET);
/*
Outputs
array(2) {
["q"]=>
string(31) "admin/settings/site-information"
["form-id"]=>
string(37) "form-f3b2569b7299435726c96c962dab3d89"
}
*/
var_dump($_POST);
/*
array(11) {
["site_name"]=>
string(5) "d7dev"
["site_mail"]=>
....
}
*/
?>
But if max_post_size is exceeded:
<?php
var_dump($_GET);
/*
Outputs
array(2) {
["q"]=>
string(31) "admin/settings/site-information"
["form-id"]=>
string(37) "form-f3b2569b7299435726c96c962dab3d89"
}
*/
var_dump($_POST);
/*
array(0) {
}
*/
?>
In both cases, we can still retain the actual form that was originally posted and also detect if the form data has been dropped.
I'll leave it to someone with extensive FAPI experience to decide on the best approach if this primarily step in form validation is added to core.
Eg: Try to detect during form build: If empty($_POST) && valid($_GET[form_build_id]), tag as invalid submission.
| Comment | File | Size | Author |
|---|---|---|---|
| form.build-id.1.patch | 1.06 KB | alan d. |
Comments
Comment #1
drewish commentedsubscribing. wanted to mention that this is a follow up to #30520-19: file_save_upload() not notifying user when PHP upload limit is exceeded. where gabor pointed to this as a solution. i'd advocated deferring that part of the issue, well it's time to start on that portion.
Comment #3
danielb commentedsubscribed
Not happy that this error handling is being attempted by particular module developers, and not consistently applied by FAPI.
also upload_max_filesize in file fields
Comment #4
alan d. commentedThis is too late for D7 now as this would be considered an API change.
Comment #17
smustgrave commentedWith so many years of inactivity wonder if this is still relevant?
Comment #19
quietone commentedAnother two years and there is no discussion or support for this idea.
The proposal doesn't met the Criteria for evaluating proposed changes. In this case, there is not demonstrated demand and support for the change.
If there is interest in this re-open the issue and add a comment. Or open a new issue and reference this one.
Comment #20
quietone commented