In the first post in this series, I mentioned that I’ve been working on a plugin in which the users needs to upload a file to a custom post type without the use of the Media Uploader.
This is basically done via use of an `input` type of `file`, WordPress `nonce` values, and some basic PHP functionality, but if you’d like to read more, then be sure to review the first post.
As mention in the first article, the second part of being able to store files and their associated meta data is so that you can also remove the files (and the meta data) when the user triggers the appropriate action.
Specifically, the plugin must do the following:
- Verify the request’s incoming `nonce` value
- Use (or somehow retrieve) the specified meta key for the file to be deleted
- Delete the file from the file system
- Remove the database entries – that is, the meta data – associated with the file
Just as in the last article, we’ll take a look at each step and the code required for each, as well.
Programmatically Delete Files in WordPress
Note that although my final implementation of this has been done using Ajax, this particular example will simply showcase the code necessary to programmatically delete files in WordPress, their associated meta data, and will do so without using any type of particular request.
Your mileage and implementation may vary, so your specific implementation won’t look exactly like this.
1. Verify The Nonce Value
Recall that WordPress `nonce` values as those values that are used to help ensure that requests that come into the server can be validated as coming from somewhere within WordPress.
To that end, we need to make sure that we always check the `nonce` value before doing any type of operation that’ll read or write to disk.
Note that here, I’ve defined a generic `acme_remove_file` function that is intended to be used to hooked into whatever action you want based on how you want to delete the file.
Also note that the `nonce` value that’s specified is based on the value that was used in the last article.
2. Retrieve The Meta Key
Next, we need to be able to retrieve, generate, or read the meta key based on the incoming request so that we can properly remove the information from the database.
Although I’ve covered this in the comments in the linked gist above, I want to be clear that how you retrieve the meta key depends on your implementation.
if you opt to send it via the `$_REQUEST` collection, then cool; otherwise, you need to use the same mechanism for generating the key that you did when you saved the file so that you can properly delete it.
3. Delete The File
Anyway, once that’s done, we should have enough information to actually remove the file from the file system.
In order to make sure that we don’t throw an exception or trigger an error, we have to make sure that we have an actual file path to remove. Recall that we stored this value in the previous post.
To that end, we need to check to see if the value actually exists:
And if it does, we use `unlink` to remove the file. Easy enough.
4. Remove The Database Entries
Finally, we need to remove the database entries associated with the file and its meta data.
Since we have the meta key associated to the file’s path on the disk as well as the meta key references the file’s URL, this is trivially easy to do:
In fact, so much so that I almost didn’t bother with a gist :).
All Together Now
At this point, we’ve covered everything from uploading the file, associated meta data with it, removing the file, and associating its meta data.
The final function responsible for cleaning up after ourselves is as follows:
And that should do it.
However, please be sure to read the comments from the last post as there are some great points mentioned surrounding security of storing file information in the database.
Though the methodologies covered in these two articles won’t necessarily change, how secure your meta data is might matter based on the strategies that you follow for storing the information.