Cleaning Up Cached Image Thumbnails
The following describes how to include code to cleanup WebAssist Cached Image Thumbnails / Resized Images when the image is replaced or deleted. The tutorial provides code and describes how to apply the code to an update page. You would need to adapt it for the delete transaction, and if you are using the newest version, the delete transaction is on the results page.
I just created this code, so it is not fully tested.
On an update page, include the PHP file attached in a zip. It is a small function for getting the directory/file information out of the cache directory.
Below is a link to the primary code snippet used.
WA_thumbnail-clean-up-snippet.zip
One more VERY important note before we get started. I have tried to account for a variety of scenarios like uploading a new/edited picture with the same name as the original picture, and replacement of a picture vs deleting a record and associated picture. What I cannot do anything about is when Overwrite is used for file name conflicts and more than one record in the database uses the same picture (or same image file name) in the same directory location. Under these circumstances, deleting one record would cause a broken link in the other record since the file was deleted. If this could be an issue for you, be sure to use Rename new file as the file naming method to avoid this problem, and always rename the new file not the existing one.
And now for the tutorial:
IMMEDIATELY AFTER THE UPLOAD FILE CODE, add a WA delete file transaction based on a successful upload of your new file, and delete the file to be replaced.
That will still be the current value in the database because the update transaction has not happened yet.
<?php
WA_DFP_SetupUploadStatusStruct("WA_UploadResult1");
if((((isset($_POST["exec"]))?$_POST["exec"]:"") != "")){
WA_DFP_UploadFiles("WA_UploadResult1", "image", "0", "", "true", $WA_UploadResult1_Params);
}
?>
<?php
$WA_DeleteFileResult1 = false;
if($WA_DFP_UploadStatus["WA_UploadResult1"]["statusCode"] == 1){
$WA_DeleteFileResult1 = WA_FileAssist_DeleteFile("../../images/blogs/", "".$row_WADAblog['image'] ."");
}
?>
Below that code include the following code block. Be sure to customize the first three values to match your transaction.
<?php
// WA File Cleanup
/*
CONFIGURE THUMBNAIL TRANSACTION VALUES
*/
/*
The results value created by the WA delete transaction to use as a trigger for whether or not to cleanup any thumbnails.
*/
$deleteResult = $WA_DeleteFileResult1;
/*
The Server File Name Value. This is used to check if the uploaded file name is the same as the previous file name.
If it is, resized images will still be deleted so they can be regenerated.
This is done in case the image changed but file name remained the same, and overwrite is the method used in the upload.
For a delete trasaction, just set the value to "". The delete file transaction will be the trigger.
*/
$newFileName = $WA_DFP_UploadStatus["WA_UploadResult1"]["serverFileName"];
/*
Path to the directory where the image cache files are stored. This can be vary specific like /image_cache/images/blog or more general like /image_cache.
The higher the directory, the more potential for an inadvertant thumbnails to be included. For example, if you had an image_cache directory and under it you had
thumbnails generated in directories images/blog and images/gallery, if a source image foir thumbnails existed in both the blog and the gallery that had the
same name, both thumbnail sets would be deleted. In addition, the higher the directory setting, the greater the execution time though this may be marginal
in most cases. THE BEST PRACTICE HERE IS TO SET IT TO THE DIRECTORY JUST ABOVE THE WA DIRECTORIES OF fit, proportion, and crop.
*/
$cacheDir = '/image_cache/images/blogs';
/*
The name of the database field that held the name of the file just deleted. cachedFileName is a bit misleading since none of the cached files or directories
have this name, but the cached item's names are all based on the old file name.
*/
$cachedFileName = $row_WADAblog['image'];
/*
Any array of files to ignore. Usually just an .htaccess file, if anything, for our purposes.
*/
$ignore = array('.htaccess');
/*
END CONFIG
*/
// Code block continued
if( $deleteResult || ( ($newFileName == $cachedFileName) && ($cachedFileName != "") ) ){
$dirTree = getDirectory($_SERVER['DOCUMENT_ROOT'].$cacheDir, $ignore);
if (count($dirTree)) {
foreach ($dirTree as $dir => $files) {
$dirName = substr($dir,strrpos($dir,"/")+1,strlen($dir));
$filter = substr($cachedFileName, 0, strrpos($cachedFileName, '.'));
if (substr($dirName,0,strlen($filter)) == $filter) {
if (count($files)) {
foreach ($files as $file) {
unlink($dir."/".$file);
} }
rmdir($dir);
} } } }
?>
THE NEXT STEP IS VERY IMPORTANT. If you have one update transaction for the entire record, open that server behavior and remove any update value for the image file.
Add a new update transaction that is triggered off of a successful upload of your image file.
DO NOT SET A REDIRECT VALUE.
Be sure to place this update transaction before the existing update transaction that updates the rest of the fields and redirects the page.
This should now be working code with one caveat. If the user uploads a file with the same file name as the file being replaced, the file and thumbnails will be deleted. To prevent that, add a conditional statement around the delete transaction that checks whether the file server name is the same as the current file name in the database.
<?php
WA_DFP_SetupUploadStatusStruct("WA_UploadResult1");
if((((isset($_POST["exec"]))?$_POST["exec"]:"") != "")){
WA_DFP_UploadFiles("WA_UploadResult1", "image", "0", "", "true", $WA_UploadResult1_Params);
}
?>
<?php
if ($WA_DFP_UploadStatus["WA_UploadResult1"]["serverFileName"] != $row_WADAblog['image']) {
?>
<?php
$WA_DeleteFileResult1 = false;
if($WA_DFP_UploadStatus["WA_UploadResult1"]["statusCode"] == 1){
$WA_DeleteFileResult1 = WA_FileAssist_DeleteFile("../../images/blogs/", "".$row_WADAblog['image'] ."");
}
?>
<?php } ?>
In conclusion, if you have any problems, re-read this tutorial carefully. WebAssist may place code in places other than where the cursor was, so check and see if you need to move any code blocks around, and double check the order of the code execution which should be:
- Include the function file from the link above at the top of the file
- Whatever code or validations you have before the update stuff begins.
- The WA recordset that includes the image field.
- The upload transaction.
- The Delete transaction with the name check conditional statement.
- The code snippet that deletes the resized images (remember to customize the confguration values at the top of the snippet).
- The update transaction that ONLY:
- Triggers on successful upload,
- Updates the image file field with the uploaded server name, and
- DOES NOT redirect the page when completed.
- The update transaction that updates everything else EXCEPT this image field, and redirects the page afterwards to where ever you want to redirect to.
To implement this for a delete transaction, everything is the same except there is no update transaction and you want to do it every time there is an image file.