Make the post editing form file upload friendly

[mark-k]

My costumers fairly constantly need the ability to upload files which are not displayed in the post itself but at some other area of the post page, and the main obstacle to achieve this is that the form do not have an enctype='multipart/form-data' attribute. Can you please add it. I'm getting tired of having to add the same small JS code which sets this attribute dynamically, for every new project ....

Actually, it would be nice to have this in all the core forms of wordpress. Run into situations where I needed an image per category, and the ability to upload an image when creating a link also comes to mind as a possible use case.

[janeforshort]

Punting b/c no community feedback interest showing in the two months since it's been opened and there's no patch submitted. Putting into "future release" since we're coming up on feature freeze and without a patch by now, this wouldn't make it into 2.9.

[hakre]

Maybe some filter/hook is adviseable here, sothat plugins can deal with it?

[mark-k]

I don't want to learn how to mess with SVN and generate patches, please shot me ;).

All I'm asking is that in every place there is a form it will have an enctype='multipart/form-data' attribute. Yes for all of the tens of places in the code, but having that for the post and page editing forms and tag and category editing will be nice enough for a start.

This is a zero risk change even if you misspell it .... Hope that my request is better explained now.

[dd32]

I'm supportive of this, Pretty sure it has no negitive side effects, but has the benefit of allowing easier file uploads from within meta boxes among others..

The only downside is letting some plugin authors mearly rely upon a form post to upload their items, instead of allowing it to happen asynchronously.

Currently some plugins are using iframes as a way around this..

[azaozz]

Adding that would switch the way form data is sent by the browser, it turns it into a multipart MIME data stream (similar to an email with attachments).

From RFC2388 ​http://www.ietf.org/rfc/rfc2388.txt

The multipart/form-data encoding has a high overhead and performance
impact if there are many fields with short values. However, in
practice, for the forms in use, for example, in HTML (in 1998), the average
overhead is not significant.

Not sure now much that would affect WordPress but seems many of our forms have "many fields with short values".

[dd32]

Hm, That is true.. However, It should have minimal impact, It wouldn't affect autosaves.

Perhaps a better option would just to add a action into the form tag so that plugins which absolutely need to add file uploaders to forms can do so?

[azaozz]

It is very easy to change all forms to this at the moment too:

add_action('admin_print_footer_scripts', 'my_form_type', 20);
function my_form_type(){ ?>
    jQuery('form').attr('enctype', 'multipart/form-data');
<?php
}

[Denis-de-Bernardy]

Replying to azaozz:

It is very easy to change all forms to this at the moment too:

add_action('admin_print_footer_scripts', 'my_form_type', 20);
function my_form_type(){ ?>
    jQuery('form').attr('enctype', 'multipart/form-data');
<?php
}

are you sure that works? I ask, because I know for a fact that this doesn't:

add_action('admin_print_footer_scripts', 'my_form_type', 20);
function my_form_type() { ?>
    <script>
    jQuery(':text').attr('type', 'hidden');
    </script>
<?php
}

when you try it, Safari spits out an error along the lines of "Can't modify this attribute"

[Denis-de-Bernardy]

Adding to this I don't think this is a very desirable thing to do. As DD32 suggests, it'll be bait for plugin authors to not deal with uploads asynchronously.

[azaozz]

Yes, there are better ways to handle uploading (perhaps not as simple).

Replying to Denis-de-Bernardy:

I ask, because I know for a fact that this doesn't:
...

    jQuery(':text').attr('type', 'hidden');

Yeah, there's no point in trying to set a text field to hidden and the otherway round with js. There's no real difference between type="text" style="display: none" and type="hidden" from form functionality point of view except that you can show/hide the text field later with js.

As far as I can see changing the enctype with js works since it's checked when the form is submitted not when the page is loading.

[mark-k]

I don't know about what other people do, but for me it is required in every project which need some images to be associated with a post and not in the form of gallery. It results in copying almost the same code which was suggested here from project to project, which I consider to be a needless waste of time.

And not always the image has to be associated with a post. In one project I provided the ability to control an header image of a category page.

I don't know about lazy plugin authors, but if they are doing something more complicated then adding the JS lines, at some day they will probably wise up and use it.

I do know about performance. I know that I am using the lowest broadband I can get and it is 96k upstream. The minimal VPS I am using for my personal blog and a small WPMU installation and a small RSS aggregator is far from reaching its bandwidth limits. I find it hard to believe that even if there will be an extra 1k wasted for each form, and since this is the admin interface we are talking about, it will have any measurable real life implication.
On the contrary, adding JS for every admin page load, even when you are just inspecting the data, can prove to be more wasteful.

[johnbillion]

Plugins can add the form encoding type using the post_edit_form_tag action.

Example:

function my_enc_type() {
    echo ' enctype="multipart/form-data"';
}
add_action('post_edit_form_tag','my_enc_type');

Not sure why this is an action instead of a filter, but there we go.