WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

Last modified 4 years ago

#10518 closed feature request (worksforme)

Make the post editing form file upload friendly

Reported by: mark-k Owned by:
Milestone: Priority: low
Severity: minor Version: 2.8
Component: Media Keywords:
Focuses: Cc:

Description

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.

Change History (16)

comment:1 @Denis-de-Bernardy6 years ago

  • Summary changed from Make the post rditing forn file upload freindly to Make the post editing form file upload friendly

comment:2 @scribu6 years ago

  • Component changed from General to Media
  • Milestone changed from Unassigned to 2.9

comment:3 @janeforshort6 years ago

  • Type changed from enhancement to feature request

comment:4 @janeforshort6 years ago

  • Milestone changed from 2.9 to Future Release
  • Priority changed from normal to low
  • Severity changed from normal to minor

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.

comment:5 @hakre6 years ago

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

comment:6 @mark-k6 years ago

  • Cc mark-k added

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.

comment:7 @dd326 years ago

  • Version set to 2.8

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..

comment:8 @azaozz6 years ago

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".

comment:9 @dd326 years ago

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?

comment:10 follow-up: @azaozz6 years ago

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
}

comment:11 in reply to: ↑ 10 ; follow-up: @Denis-de-Bernardy6 years ago

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"

comment:12 @Denis-de-Bernardy6 years ago

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.

comment:13 in reply to: ↑ 11 @azaozz6 years ago

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.

comment:14 @mark-k6 years ago

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.

comment:15 @johnbillion5 years ago

  • Resolution set to worksforme
  • Status changed from new to closed

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.

comment:16 @nacin4 years ago

  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.