I'm having a problem with one of my fields when set to type "file".
The same problem is in 3.6.2 (the version I develop on) and 3.8.2 (just downloaded & checked).
If my database source is a plain setTable() and I have a field set to file "file" and setUploadSubpath("products"), I can upload, delete and view images in the "products" sub directory as you would expect. I can call getUploadSubpath() at any time and it returns "products". This all is fine.
If I add a filter to my source addFilter('category = ?','mycategory') then the file field stops working. Deletions are OK but Adding fails. The upload succeeds in placing the image as a temp file but is not moved to the "products" location on saving. The database is updated but with the field having the temp file location. Calling getUploadSubpath() returns blank.
If I manually setUploadSubpath("products") after applying the source filter, getUploadSubpath() returns "products" correctly but a file uploaded after this still has the same problem.
I can duplicate this across 2 different application masks on both 3.6.2 and 3.8.2.
Am I right in thinking this is a bug?
After extra testing, I'm pretty sure this IS a bug. By removing the addFilter() code and replacing it with setWhere() instead, my setUploadSubpath() change as expected.
actually you've to use addFilter('category = ?',$yourfield_or_datafield)
can you try with that?
The filter works correctly in that my table grid adjusts to show what I'm filtering - so my syntax is correct.
It's just that if I add a filter, the file upload thing breaks…
Thanks for looking.
it works fine for me, please create a small test case so I can directly test your code.
I've added a P4A 3.8.2 test application to the bug report at
It uses the Products_Catalogue database. My testing is on an Apache/MySQL server and Ubuntu/FF4 client.
Add a '1' to the Filter field and tick "Use Filter" to apply the filter. Then upload an image and save back to the database. The image is saved in the database with "tmp" location, the image is never moved to the correct subpath location.
answered in bug, not a bug anyway