Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix bugs in Managing Files and Images code #744

Merged
merged 1 commit into from
Mar 6, 2019
Merged

Fix bugs in Managing Files and Images code #744

merged 1 commit into from
Mar 6, 2019

Conversation

baudev
Copy link
Contributor

@baudev baudev commented Feb 22, 2019

As mentioned in the issue api-platform/admin#146, the code proposed in the documention to handle file upload is not fully working.

In this PR, I removed the useless <FunctionField> component. Indeed, I see no interest using it.
Other modifications don't require to be explained (minor fixes such as value instead of value[0]).


Nevertheless, the following lines (picked from the doc) need to be discussed :

field.normalizeData = value => {  
	if (value[0] && value[0].rawFile instanceof File) {  
		const body = new FormData();  
		body.append('file', value[0].rawFile);  
		  
		return fetch(`${entrypoint}/images/upload`, { body, method: 'POST' })  
		.then(response => response.json());  
	}  
  
return value.src;  
};  

This part of code is responsible of adding a new request to upload the file. When you click on the creation button, it first sends the file to /images/upload. Then, the usual request /images (the one for each creation entity) is executed.

It could be resumed with the following graph:

image

It's really important to understand that there are two requests when clicking on the creation button.

However, the documentation of how to handle file upload in the API Platform back is not corresponding to the strategy used in the admin interface.

Let's see why in different points:

  • If we use the previous code in the admin interface with the Image class, an error will occur while doing the second request as the file attribute will be null (because the code only edits the rendering of the contentUrl attribute).
    We must remove the @Assert\NotNull() annotation.

  • Now, if we try again in the admin interface to upload a file again, two instances of the Image class will be saved in the database (as there are two requests). The first one is the one which uploads the file as desired but the second one is empty. Also, the user is redirected to the page of the last image instance (the empty one, so).
    We must then change the condition to:

if ($form->isSubmitted() && $form->isValid() && $image->file != null) {

and replace:

throw new ValidationException($this->validator->validate($mediaObject));

by:

return $this->imageManager->getLastInsert();

It's only now that the whole photo upload system works! 馃帀

Do I need to do a PR to modify the documentation of this page or just add a note in the admin documentation part?
Maybe an easier solution could be proposed to handle file upload?

I got many difficulties to explain the problem in this PR in writing. Don't hesitate to ask me questions if I haven't been clear on some points.

@dunglas dunglas merged commit e08bbb2 into api-platform:2.4 Mar 6, 2019
@dunglas
Copy link
Member

dunglas commented Mar 6, 2019

Thanks @baudev.

Do I need to do a PR to modify the documentation of this page or just add a note in the admin documentation part?

A PR to update the back part would be great.

Maybe an easier solution could be proposed to handle file upload?

I definitely agree. Our long term plan is to support this directly in API Platform (without needing such docs, and without requiring the external bundle).

@baudev
Copy link
Contributor Author

baudev commented Mar 12, 2019

@dunglas However, there is a problem with my solution.

To better understand, this is the code I had to put in place in order for the administration interface to work:

    public function __invoke(Request $data): Image
    {
        $mediaObject= new MediaObject(); // we create a mediaObject entity
        // we try getting a mediaObject entity from the mediaObject form
        $form = $this->factory->create(MediaObjectType::class, $mediaObject);
        $form->handleRequest($data);
        if ($form->isSubmitted() && $form->isValid() && $mediaObject->file != null) {
            $em = $this->doctrine->getManager();
            $em->persist($mediaObject); // we store the image in the database
            $em->flush();

            // Prevent the serialization of the file property
            $mediaObject->file = null;
	    return $mediaObject;
        }

        // if the file is null, then we return the last inserted Image entity
        return $this->mediaObjectManager->getLastInsert();
    }

As I explained above, this line return $this->mediaObjectManager->getLastInsert(); allows in the case of the second request to retrieve the entity of the object posted by the first request (knowing that the second request does not send the file and therefore file attribute is null). Thus the user is correctly redirected to the page of the uploaded image.

However, the behavior may seem completely strange and surprising if you don't use the administration interface... Indeed, everyone will wonder why we return the last saved entity when the file attribute is null!

So what do we do? In the meantime I wait before making a PR of the back documentation....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants