Uploading through WireUpload works, but adding to FieldTypeFile generates HTTP 500

[Rachid Finge]

I'm building a smartphone app that allows users to record a voice clip and send it to our server, which runs ProcessWire. Files are sent over HTTPS Post, currently without any sort of authentication.

I've succeeded using the WireUpload class to fetch the uploaded file from the $_FILES super global. Where I get in trouble is when I try to add the audio file to the audio page, where there's an Input field called 'audiofile'. Whenever I try to use any file related method, an Internal Server Error occurs.

Here's my code, which runs in the page's template.

<?php

Header("Content-Type: text/plain");

$upload_path = $config->paths->assets . "files/audio/";

$u = new WireUpload('files');

$u->setMaxFiles(1);
$u->setOverwrite(false);
$u->setValidExtensions(array('mp3', 'mp4', 'm4a'));
$u->setDestinationPath($upload_path);

// I can confirm through my FTP client that the file sent through POST actually shows up in the $upload_path location.
$fileresult = $u->execute();

// This is the File input field in my template. Doing print_r($audiofield) confirms this is an existing object.
$audiofield = $fields->get("audiofile");

// Trying this for the heck of it, but all that results is HTTP 500.
$audiofield->deleteAll();

foreach($fileresult as $filename) {
	// I've seen various examples on what to do now. Here's one that causes a 500 error.
	$page->'audiofile' = $upload_path . $filename;
	
	// This seems the most logical thing to do, but also causes HTTP 500.
	$audiofield->add($upload_path . $filename);
	
	// Unlinking succeeds (given that I comment out the lines that cause the HTTP 500 errors)
	unlink($upload_path . $filename);
}
   
// We never get to this phase.         
$page->save();

?>

Things of note:

• Server runs PHP 5.4.4-14+deb7u8 on Debian with Apache/2.2.22. 
• File uploading through the admin on the audio page works without issues, also when uploading multiple files at once or sequentially.
• I've confirmed the owner of $upload_path to be www-data and its permissions to be 755.

What's the final step I'm missing to add the audio file to the input field on my page?

Edited February 7, 2015 by Rachid Finge

[adrian]

Just a quick glance, but I think what you are looking for is:

$page->audiofile->add($upload_path . $filename);

[Rachid Finge]

Thanks adrian!

This seems to have some effect, as the response time of the PHP page increases somewhat.

However, the HTTP 500 error still persists and no change is made to the page.

How can I start debugging the 500 error? Can't find a log that offers more details.

[Jan Romero]

The log will be in /site/assets/logs/errors.txt, or in the setup tab in the admin on newer dev-branch installations.

[apeisa]

500 comes from Apache, so take a look at Apache error logs.

[Rachid Finge]

Thanks so much guys, the issue has been resolved!

The error log showed the following relevant entry:

Error: 	Exception: Can't save page 1083: /en/audio/: Call $page->setOutputFormatting(false) before getting/setting values that will be modified and saved.  [audiofile] (in /(...)/events/wire/core/Pages.php line 817)

Ok, so I added $page->setOutputFormatting(false) before calling save and that fixes everything. I don't know why, I must add, but I'm sure I'll figure out in time what that method does.

Learning from all of this, there are still two questions I'd like to ask:

1. The right way to save a file to a FileInputField was using the 'add' method with the temporary file as the only argument. I never came across this in the documentation. Is this undocumented or do I need better glasses?
2. Should the omission of calling setOutputFormatting really trigger a rather harsh error on the web server?

[LostKobrakai]

I think there's no real specialized documentation about saving files from the api, but it's the same api as for pages and images. They all inherit their functions from WireArray / WireData which are kinda key components of most processwire fieldtypes. 

OutputFormating is exactly what it tells you to be. It changes the way output is presented to you. If it's off you'll get raw database data. E.g. for a page field this would be the id. If it's on you'll get not only the id but the whole page object of this page. Regarding this "harsh" error. Yeah it has to be this way, as you cannot save anything with outputformatting on. Not being able to save is pretty important stuff for a cms, which requires a hefty error.