If a File is uploaded with a name containing spaces it disapears.

[Aku-benj]

Description

The upload of a file containg spaces in his name is not added to the Gform entry at the end of the submit process.
I can see the file in the upload/gravity_forms1-xxx/tmp but then the gravity-form code fails to move it to the entry.

Steps to reproduce

1 - Create a form with an upload file field with option Enable Multi-File Upload active
2 - Create a local file with one or multiple spaces in the name
3 - Use the submitGfForm mutation to send the file
4 - The file is not associated to the entry at the end.

Additional context

I think the issue comes from the initialize_files function in the EntryObjectMutation class.
If we compare the creation of the $target_file to the one gravityForm uses it is missing the use of sanitize_file_name :

wp-graphql-gravity-forms: wp_basename( $temp_filename )

vs

set_uploaded_files function in GFFormsModel class.

gravity-forms: sanitize_file_name( wp_basename( $upload['temp_filename'] ) )

This leads to the call of file_exists returning a missing file.

Plugin Version

0.13.0.1

Gravity Forms Version

2.8.15

WordPress Version

6.4.3

WPGraphQL Version

1.28.0

Additional enviornmental details

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have disabled ALL plugins except for Gravity Forms, WPGraphQL, and WPGraphQL for Gravity Forms

• Yes
• My issue is with a specific 3rd-party plugin.

[justlevine]

Hey @Aku-benj thanks for reporting this!

I'm having trouble replicating locally. Do you perhaps have a minimal frontend replication I can try?

Also can you:

• please confirm you have disabled all plugins (including GF extensions and custom code) besides WPGraphQL, Gravity Forms, and WPGraphQL for Gravity Forms
• Share any additional environment details (OS version, etc).

Also, just curious but if you change the line in EntryObjectMutation::initialize_files() locally as you propose, does the issue go away?

( GFFormsModel::set_uploaded_files() is actually used within our lifecycle, and EntryObjectMutation::initialize_files() just primes the variables that method looks for, so my gut tells me double-sanitizing there won't help, but I need to be able to replicate to know for sure).

[mohanrajr18]

Bug Report: File uploads crash when filename contains a space
Plugin: WPGraphQL for Gravity Forms v0.13.4 (latest release — bug reproduces on the current stable version, not just an old/dev build). Note: the plugin's directory on disk is named wp-graphql-gravity-forms-develop (visible in the stack trace paths below), but WP Admin reports the installed version as 0.13.4 — the directory name appears to just be a leftover from how it was originally deployed, not an indication of running unreleased code. File: src/Data/FieldValueInput/FileUploadValuesInput.php (around line 51) Affects: submitGfForm and updateGfEntry mutations, any FileUploadField (fileUploadValues) Environment tested: test2hcms2.americanfirstfinance.com, form #10 — WordPress 7.0.4, WPGraphQL 2.19.0, Gravity Forms 3.0.2 Related upstream issue: AxeWP/wp-graphql-gravity-forms#446 — same bug, reported Aug 2024, closed not_planned (stale, never fixed) after the maintainer asked for a reproduction and environment details that the original reporter never provided. This report supplies that missing info.

Summary
Submitting a file whose original filename contains a space (e.g. certificate - 1.png) through either submitGfForm or updateGfEntry causes an uncaught PHP TypeError in the plugin's file-handling code, returned to the client as a generic "Internal server error" with no useful detail (unless GRAPHQL_DEBUG is enabled).

Files with no whitespace in their original name (e.g. certificate.png) are unaffected and save correctly and reliably.

Reproduction
Create/have an existing Gravity Forms entry with at least one FileUploadField.
Run updateGfEntry (or submitGfForm) with a file upload whose original filename contains a space, e.g. location 1.png.
mutation updateGfEntryFile($entryId: ID!, $fieldId: Int!, $file: Upload) {
updateGfEntry(input: { id: $entryId, fieldValues: [{ id: $fieldId, fileUploadValues: [$file] }] }) {
clientMutationId
errors { id message }
entry { id }
}
}
Variables: any valid entryId / fieldId for a FileUploadField, with a space-containing filename attached as $file.

Actual result
{
"errors": [
{
"message": "Internal server error",
"path": ["updateGfEntry"],
"extensions": {
"debugMessage": "copy(): Argument #1 ($from) must be of type string, null given"
}
}
],
"data": { "updateGfEntry": null }
}
Full stack trace (captured via GRAPHQL_DEBUG) for the analogous crash during submitGfForm:

/opt/www/wordpress/wp-content/plugins/wp-graphql-gravity-forms-develop/src/Data/FieldValueInput/FileUploadValuesInput.php:51
/opt/www/wordpress/wp-content/plugins/wp-graphql-gravity-forms-develop/src/Data/FieldValueInput/AbstractFieldValueInput.php:157
/opt/www/wordpress/wp-content/plugins/wp-graphql-gravity-forms-develop/src/Data/EntryObjectMutation.php:112
/opt/www/wordpress/wp-content/plugins/wp-graphql-gravity-forms-develop/src/Mutation/SubmitForm.php:232
/opt/www/wordpress/wp-content/plugins/wp-graphql-gravity-forms-develop/src/Mutation/SubmitForm.php:150
... (WPGraphQL core / webonyx graphql-php executor frames)
Expected result
Either the file saves successfully (matching Gravity Forms core's own filename sanitization, which silently converts location 1.png → location-1.png without issue for normal form submissions), or the mutation returns a clean GraphQL errors[] entry describing the problem — not an uncaught fatal.

Root cause
Around FileUploadValuesInput.php:51, the code resolves the uploaded file's temp path and then calls PHP's copy($from, $to) on the result without checking that the lookup actually succeeded. When the lookup fails — which happens whenever the original filename contains characters Gravity Forms strips during its own sanitization (spaces confirmed; likely also other special characters) — $from is null, and copy() throws a TypeError, which is uncaught and surfaces as a generic 500/"Internal server error".

This matches the diagnosis already proposed in #446 by the original reporter: EntryObjectMutation::initialize_files() builds the target filename with wp_basename( $temp_filename ), while Gravity Forms core's own GFFormsModel::set_uploaded_files() uses sanitize_file_name( wp_basename( $upload['temp_filename'] ) ). Without that sanitize_file_name() call, the plugin registers/looks up the temp file under its raw filename while Gravity Forms core expects (and produces) the sanitized one — for a filename with a space, that mismatch means the file can never be found by the name the plugin looks it up with.

A related, non-crashing symptom of the same underlying lookup mismatch was also observed via Gravity Forms' own debug log for some of the same space-containing filenames:

GF_Field_FileUpload::get_multifile_value(): Aborting; no valid file, name, or URL to save.
So the mismatch can surface two ways depending on which code path is hit: a silent no-op (no file saved, no error at all — the original #446 report's symptom) or an uncaught TypeError (this report's copy() crash). Same root cause, two different failure modes.

Suggested fix
In FileUploadValuesInput.php (~line 51), guard the copy() call:
if ( empty( $from ) || ! is_string( $from ) ) {
// return a graceful GraphQL error instead of calling copy()
}
Investigate why the temp-file lookup fails for filenames containing spaces — likely a mismatch between the raw uploaded filename and Gravity Forms' internally sanitized filename somewhere in the lookup key/path construction.
Workaround in use
Client-side (Angular) sanitization: any filename containing whitespace is renamed (spaces → underscores) via the browser's File API before upload, avoiding the mismatch entirely. This avoids the crash but does not fix the plugin — other characters GF sanitizes (if any) could plausibly trigger the same bug and aren't covered by this workaround.

[mohanrajr18]

Hi @justlevine — we just hit this same bug independently and can supply the reproduction/environment info you asked for back in 2024.

Environment

• WPGraphQL for Gravity Forms: 0.13.4 (latest release — so this is not fixed as of the current version)
• Gravity Forms: 3.0.2
• WordPress: 7.0.4
• WPGraphQL: 2.19.0

Confirmed reproduction

Filenames containing a space (e.g. certificate - 1.png, location 1.png) reliably fail to save, while the identical file renamed without a space (certificate.png, location.png) saves correctly every time. This reproduces on both submitGfForm and updateGfEntry — not just the initial submission.

We got a stack trace with GRAPHQL_DEBUG enabled. Depending on the code path, the mismatch surfaces two different ways:

1. A silent no-op — matches this issue's original report exactly, confirmed via Gravity Forms' own debug log:

   GF_Field_FileUpload::get_multifile_value(): Aborting; no valid file, name, or URL to save.
   

2. An uncaught fatal, returned to the client as a generic "Internal server error":

   {
     "errors": [{
       "message": "Internal server error",
       "path": ["updateGfEntry"],
       "extensions": { "debugMessage": "copy(): Argument #1 ($from) must be of type string, null given" }
     }]
   }

   Stack trace bottoms out at FileUploadValuesInput.php:51, called from AbstractFieldValueInput.php:157 → EntryObjectMutation.php:112 → SubmitForm.php.

Both symptoms point to the same root cause you and @Aku-benj already discussed here: EntryObjectMutation::initialize_files() builds the target filename with wp_basename( $temp_filename ), with no sanitize_file_name() call, while Gravity Forms core's GFFormsModel::set_uploaded_files() does sanitize (sanitize_file_name( wp_basename( $upload['temp_filename'] ) )). That mismatch means a file with a space in its name gets registered/looked-up under its raw name on one side and its sanitized name on the other, so the lookup fails — and in FileUploadValuesInput.php, the resulting null path gets passed straight into copy() with no guard.

Happy to test a patch against our environment if useful — we can reproduce this on demand.

[justlevine]

thanks for the reproduction @mohanrajr18 , I'm currently traveling at WCUS I'll take a look ASAP