The newly-added ability for any user uploading a file to change the storage is extremely problematic for us. We do not want users changing the default storage specified in the field settings, that would let them mistakenly store sensitive documents publicly and potentially open the company to considerable liability.

The same applies to any other steps that allow the user to change defaults. We just want step 1 ;-)

Please provide a simple way to skip each step of the form after step 1. A permission per step would be ideal, but if that would result in too many permissions, a hook would be welcome.

#9 add-ability-to-skip-upload-wizard-steps-2001074-9.patch4.24 KBDevin Carlson
PASSED: [[SimpleTest]]: [MySQL] 874 pass(es). View
#8 add-ability-to-skip-upload-wizard-steps-2001074-8.patch4.18 KBЕлин Й.
PASSED: [[SimpleTest]]: [MySQL] 874 pass(es). View
#5 skip_step_ui.png78.47 KBDevin Carlson
#5 add-ability-to-skip-upload-wizard-steps-2001074-5.patch4.18 KBDevin Carlson
PASSED: [[SimpleTest]]: [MySQL] 874 pass(es). View


John Pitcairn’s picture

I think if this were permission-based you'd possibly need a separate permission per-filetype and per-step, which really would result in far too many permissions?

Devin Carlson’s picture

rsmylski’s picture

I can understand having the 'Destination' step (step 3) when adding a brand new file via file/add, but when adding a file via a field that already has that information defined, shouldn't there be a check for that in order to skip that step?

Елин Й.’s picture

I am also looking for a way to skip 'Destination' step, which makes the file uploads very cumbersome and unnecessarily complicated for users. Even if there are no permissions or something to skip those steps, I would appreciate any hints about to hide/skip those site-wide.

Thanks in advance!

Devin Carlson’s picture

Status: Active » Needs review
4.18 KB
PASSED: [[SimpleTest]]: [MySQL] 874 pass(es). View
78.47 KB

A patch to provide options for skipping each of the upload wizard steps. A description of what each step does and what happens if a certain step is skipped is included.


The default behaviour for skipping the file type selection step would be enhanced by #1920350: Provide a "catch all" default application file type.

John Pitcairn’s picture

Doesn't apply against most recent dev snapshot:

$ git apply -v add-ability-to-skip-upload-wizard-steps-2001074-5.patch 
Checking patch file_entity.install...
Checking patch file_entity.module...
error: while searching for:
    '#weight' => -10,
    '#description' => t('Separate extensions with a space or comma and do not include the leading dot.'),


error: patch failed: file_entity.module:439
error: file_entity.module: patch does not apply
Checking patch
avinoam’s picture

Status: Needs review » Reviewed & tested by the community

I applied it against the last dev version and it work well for me

Елин Й.’s picture

Status: Reviewed & tested by the community » Needs review
4.18 KB
PASSED: [[SimpleTest]]: [MySQL] 874 pass(es). View

Patch on #5 has a little typo on 'Skip scheme selection' checkbox. The corrected patch is attached.

By the way many thanks to Devin Carlson for the patch!

Devin Carlson’s picture

4.24 KB
PASSED: [[SimpleTest]]: [MySQL] 874 pass(es). View

A reroll of #8 since #1994080: Previous Button not working from step 4 to step 1 in file_entity_add_upload form got in. It also uses FILE_TYPE_NONE for files which can't have their types automatically determined.

John Pitcairn’s picture

Status: Needs review » Reviewed & tested by the community

Applied to July 22 dev and working, thanks.

aaron’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Removed link to unrelated issue

Sergey Filimonov’s picture

Never mind, it's already in module.

Sergey Filimonov’s picture

dchampine’s picture

I was struggling with this issue even with the latest code. In my case I found the issue to be an invalid value for $trigger. The triggering_element #id was different.
Not sure how that #id gets set, but it may help a regular guy and a contributor to know that it could be different.
I discovered this by inserting dpm($trigger) and dpm($form_state) inside the file_entity_add_upload_submit() function. Comparing the value of $trigger to the values evaluated later in the function made it clear that the tests for skipping steps would never evaluate true.

if (($form['#step'] == $step - 1 && $trigger == 'edit-next2') || ($form['#step'] == $step + 1 && $trigger == 'edit-previous')) {

modified (not sure if this is unique to my install, but it fixes things for me in the short term):
if (($form['#step'] == $step - 1 && $trigger == 'edit-next--2') || ($form['#step'] == $step + 1 && $trigger == 'edit-previous')) {

museumboy’s picture

If the Allowed File Types is already selected in the field setting for the content-type why must this process ask again? This setting in the field manager sets what type of file can be uploaded, but does not set the file to that field-type. Why not?

igorik’s picture

hello, I am curious - this feature is already included in media module?
I found there is on admin/config/media/file-settings

Configure the steps available when uploading a new file.
Skip filetype selection.
Skip scheme selection.
Skip available fields.

it is this what is going here about, ot this patch #9 is adding some other simplicity?

Thank you

John Pitcairn’s picture

@igorik: Yes, and the issue is marked as fixed.

museumboy’s picture

Does not work like it should. I have multiple file-types configured for a JPG mimetype.

In a content-type I define an image field and select the media browser. In the setting of that field I select one 'Allowed file types' that is acceptable for this field.

Upon adding a node of that content-type I may be able to skip the filetype selection in the upload wizard, but the filetype defaults to whatever Filetype is first on the list. It does not obey the rule I defined in the field setup.

John Pitcairn’s picture

@museumboy: That would be a bug then. Since this is now in the module, and this issue is closed, you would be best to file a new issue specifically for that bug.