You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure this is a bug, but it's worth bringing up for an extra set of eyeballs.
Had a user, current EE, file upload work fine except when making attachments to emails in Communicate. You submit- it fails and comes back with a validation error 'There was a problem attaching your file'.
Turns out they were on Plesk and there is no “upload_tmp_dir” set so in plesk we have to set a PHP variable:
upload_tmp_dir = /var/www/rob1/httpdocs/tmp
This got it working, but it is interesting that it wasn't necessary for other uploads. I did notice in the communicate controller:
Not entirely sure why use_temp_dir is explicitly set to true there and I suspect that's why the different behavior. So again- not at all sure it's a bug, but if it's not, we might drop a note in the troubleshooting section of the docs about it. Pretty rare thing, but still confusing to the user.
The text was updated successfully, but these errors were encountered:
I think the behavior is correct (we want to use the temporary directory only, and we also are trying to use different places, so it's problem with their setup if the have none) - but we clearly need to display the right error message
Uh oh!
There was an error while loading. Please reload this page.
Not sure this is a bug, but it's worth bringing up for an extra set of eyeballs.
Had a user, current EE, file upload work fine except when making attachments to emails in Communicate. You submit- it fails and comes back with a validation error 'There was a problem attaching your file'.
Turns out they were on Plesk and there is no “upload_tmp_dir” set so in plesk we have to set a PHP variable:
This got it working, but it is interesting that it wasn't necessary for other uploads. I did notice in the communicate controller:
Not entirely sure why use_temp_dir is explicitly set to true there and I suspect that's why the different behavior. So again- not at all sure it's a bug, but if it's not, we might drop a note in the troubleshooting section of the docs about it. Pretty rare thing, but still confusing to the user.
The text was updated successfully, but these errors were encountered: