---

do not leave the primary key in your picture table, just leave the path of the two pictures associated with the content id, so that it is very convenient for you to delete it. When you modify it, you can directly delete the content-related data of this picture table, and then add

---

this kind of essence is to insert pictures in the content, while pictures can be linked to entities with id, and entities see how to store them. However, the modification of the content and the modification of the insertion position are fully updated, and the increase in the picture is actually to add an id in the picture library, while deletion does not necessarily delete the entity (of course, you can delete it to see how the specific picture is stored), but there is no reference to the picture id in this content. This is probably most of the ways to deal with it.
I don't know what your so-called modification is. How does the front end modify the picture and save it to the back end?

---

I've done similar functions before, and my idea is something like this:

1. when you add a picture, store the path of the added picture (picture information parameters, etc.) in the hidden field where the name of input is already_photo []
When you modify
2. , take out the existing image path and place it in the hidden field. Then, when you modify it, replace (add) the new image and put it in the hidden field
. When
3. submits the entire form, use the function array_diff to compare it with the front-end text field and the image data in the database. To compare twice, you need to find the added and deleted files, delete the database information and delete the resource files, and add
to the ones that need to be added.

The advantage of this is that when you add it, you can get unwanted file information even if you replace it many times. When submitting the form, by comparison, you can delete the corresponding resource file and reduce the extra resources on the server.