Using the Orphanage

[anacona16]

There is a way for use it?

I configured the orphanage following the OneupUploadBundle instructions, but when I try to upload a file, the JsonResponse is empty, but the file was uploaded.

Thanks.

[jbouzekri]

No, this bundle cannot be used with the orphenage function of the openup bundle.

It does not use the orphenage manager when handling the upload : https://github.com/1up-lab/OneupUploaderBundle/blob/master/Resources/doc/orphanage.md#the-controller-part

[anacona16]

Which would be the best way to use it? Or how handler the unused files?

[jbouzekri]

I don't think it will be easy.

If you don't use the crop tool, you should be able to use it by configuring the storage to be orphanage. It should work. You will maybe have to configure your own OrphenageResolver to generate a temporary url when the file is in the orphenage storage.

If you use the crop tools, this will be harder as the crop is done in 2 actions : the classic upload one and a custom crop controller.

It was a deliberate choice to not use the orphanage. Too much trouble to implement and disk space is cheap.

Note : all uploaded files have an entry in the history table. You could use it to find which files need to be removed.

[anacona16]

I try to use the orphanage with the jb_image_ajax field type, but the ajax response is empty.

Every file uploaded have a entry in the history table, inclusive the files that are no used, suppose you upload a file, this file is inserted in the history table, but you selected a wrong image, and you upload a new image, the second image is inserted in the history table too, what happened with the first image? How I detect or control that the first image is not valid?

I suppose that a Doctrine event must be fired after the entity was saved, and here save the image data in the history table.

Thanks.

[jbouzekri]

If the response is totally empty, you most probably have a PHP error. You should check the log files of SF or your webserver.

To answer your question, every single upload is tracked in the history table. Nothing is ever deleted right now. This is not a doctrine event but an extension of the oneup upload manager which inject in the table.

As I said previously, right now, there is no detection that the first image is no longer valid. If you don't succeed in using the orphanage, I have thought of an idea : if only authenticated user can upload, you could use a single oneup mapping per upload form type in your project and add a unique constraint on the history table for type (which store the mapping used) and user_id field. That way, if you have a non unique exception it means that the user is trying to upload a new file for the same field.

[anacona16]

This is the SF log error using the orphanage and the jb_image_ajax field type.

[2015-10-07 19:22:25] event.INFO: An exception was thrown while getting the uncalled listeners. {"exception":"[object] (Symfony\\Component\\DependencyInjection\\Exception\\InactiveScopeException(code: 0): You cannot create a service (\"jb_fileuploader.file_ajax.upload_listener\") of an inactive scope (\"request\"). at /Users/ranacona/Sites/symfony_demo/app/cache/dev/appDevDebugProjectContainer.php:1835)"} []

So, the history table cannot be used for check the use files and ones not. I said this, because the history table is filled immediately the file is uploaded and not after the entity is persisted.

I can't use the last option because a user (user_id: 3) can upload a image to many different records.

[jbouzekri]

Very strange. You error you are getting is a container scope error. But the manager is called when uploading an image so in a request scope. You should not have this error.

Another idea : upload files in a directory based on the current date. And check at the end of each day which files are used or not. It is kind of hacky but it could work. But this bundle does not handle the orphanage right now. As you have pointed out, it use the onUpload event to fill in the history table.