Search

Hi, Michael.

With the original setup,

<input type="file" name="fields[avatar]" />
<select name="fields[avatar]">
    <option value="{avatar/@path}/{avatar/filename}" selected="selected">Keep existing</option>
    <option value="">Remove or upload new</option>
</select>

I've got this in the request body,

with the option to keep the existing file, which throws the Illegal string offset 'name' error,

Content-Disposition: form-data; name="fields[avatar]"; filename="" Content-Type: application/octet-stream
Content-Disposition: form-data; name="fields[avatar]" /images/avatars/img_8363-1.png

and with the option to remove the file, which does that, and I can see the 0 value of the field in the post-values with ?debug:

Content-Disposition: form-data; name="fields[avatar]"; filename="" Content-Type: application/octet-stream
Content-Disposition: form-data; name="fields[avatar]"

The second setup,

<input type="hidden" name="fields[avatar]" />
<select name="fields[avatar]">
    <option value="{avatar/@path}/{avatar/filename}" selected="selected">Keep existing</option>
    <option value="">Remove or upload new</option>
</select>

keeps the existing file regardless of the option.

The first option, to keep the file:

Content-Disposition: form-data; name="fields[avatar]"
Content-Disposition: form-data; name="fields[avatar]" /images/avatars/img_8363-1.png 

and the option to remove the file:

Content-Disposition: form-data; name="fields[avatar]"
Content-Disposition: form-data; name="fields[avatar]"

As I mentioned, the first setup is identical to what I use for a project on a live server, where I have PHP 5.3.10 and no errors for that. I tested it, the request was the same:

Content-Disposition: form-data; name="fields[image]"; filename="" Content-Type: application/octet-stream
Content-Disposition: form-data; name="fields[image]" /images/img_20130712_145133.png 

Thank you for your help.

Surely that is the culprit. AFAIK, @ellie's concept—keeping a file by passing the file's path in the POST request—is not a feature of Symphony (nor does it sugest itself, to be honest). It works with older PHP versions, only because PHP's error fallback prevents Symphony from overwriting/deleting the file in this case.

So I don't think that this can be fixed, unless we imlement this special "POST behaviour" for files in Symphony. At the moment Symphony will keep a field's value if the field is not sent at all, see my suggested solution.

That said, of course Symphony shouldn't throw such an error.

I, see. I always thought that passing the path was more reliable than not passing it, in order to keep an existing file.

I guess the second setup doesn't display errors because, with the input field type being hidden, PHP doesn't know it's a file...

Thanks, Michael. I like your approach, but for the two projects I need this, I think it would be better to use a separate form for files. There are a number of fields and by reloading the form I'll have to think about preserving data users have already entered.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details