Fix bugs in Managing Files and Images code

[baudev]

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].rawFileinstanceofFile){constbody=newFormData();body.append('file',value[0].rawFile);returnfetch(`${entrypoint}/images/upload`,{ body,method: 'POST'}).then(response=>response.json());}returnvalue.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:

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:

thrownewValidationException($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]

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]

@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:

publicfunction__invoke(Request$data): Image
{
$mediaObject= newMediaObject(); // 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 entityreturn$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....

[baudev]

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].rawFileinstanceofFile){constbody=newFormData();body.append('file',value[0].rawFile);returnfetch(`${entrypoint}/images/upload`,{ body,method: 'POST'}).then(response=>response.json());}returnvalue.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:

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:

thrownewValidationException($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]

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]

@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:

publicfunction__invoke(Request$data): Image
{
$mediaObject= newMediaObject(); // 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 entityreturn$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....

[baudev]

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].rawFileinstanceofFile){constbody=newFormData();body.append('file',value[0].rawFile);returnfetch(`${entrypoint}/images/upload`,{ body,method: 'POST'}).then(response=>response.json());}returnvalue.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:

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:

thrownewValidationException($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]

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]

@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:

publicfunction__invoke(Request$data): Image
{
$mediaObject= newMediaObject(); // 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 entityreturn$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....

[baudev]

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].rawFileinstanceofFile){constbody=newFormData();body.append('file',value[0].rawFile);returnfetch(`${entrypoint}/images/upload`,{ body,method: 'POST'}).then(response=>response.json());}returnvalue.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:

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:

thrownewValidationException($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]

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]

@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:

publicfunction__invoke(Request$data): Image
{
$mediaObject= newMediaObject(); // 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 entityreturn$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....

[baudev]

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].rawFileinstanceofFile){constbody=newFormData();body.append('file',value[0].rawFile);returnfetch(`${entrypoint}/images/upload`,{ body,method: 'POST'}).then(response=>response.json());}returnvalue.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:

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:

thrownewValidationException($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]

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]

@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:

publicfunction__invoke(Request$data): Image
{
$mediaObject= newMediaObject(); // 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 entityreturn$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....

[baudev]

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].rawFileinstanceofFile){constbody=newFormData();body.append('file',value[0].rawFile);returnfetch(`${entrypoint}/images/upload`,{ body,method: 'POST'}).then(response=>response.json());}returnvalue.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:

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:

thrownewValidationException($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]

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]

@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:

publicfunction__invoke(Request$data): Image
{
$mediaObject= newMediaObject(); // 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 entityreturn$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....

[baudev]

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].rawFileinstanceofFile){constbody=newFormData();body.append('file',value[0].rawFile);returnfetch(`${entrypoint}/images/upload`,{ body,method: 'POST'}).then(response=>response.json());}returnvalue.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:

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:

thrownewValidationException($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]

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]

@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:

publicfunction__invoke(Request$data): Image
{
$mediaObject= newMediaObject(); // 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 entityreturn$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....

[baudev]

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].rawFileinstanceofFile){constbody=newFormData();body.append('file',value[0].rawFile);returnfetch(`${entrypoint}/images/upload`,{ body,method: 'POST'}).then(response=>response.json());}returnvalue.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:

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:

thrownewValidationException($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]

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]

@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:

publicfunction__invoke(Request$data): Image
{
$mediaObject= newMediaObject(); // 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 entityreturn$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....