Günter Schenk :: Tutorials Corner
Adobe Dreamweaver Developer Toolbox

     

Image & File Upload: overwrite existing file

Author: Günter Schenk, Added: 05.02.2008, Updated: 07.02.2008

Table Of Contents

Title	Version
Introduction	n/a
The Custom Trigger	n/a
Scenario 1: no questions asked	n/a
Scenario 2: have a choice !	n/a

1. Introduction

Well, we all know that the Dreamweaver Developer Toolbox "Upload Files" respectively "Upload and resize images" server behaviours both provide a "Specify action if file exists" file renaming section which offers the following options:

• Automatic renaming : this option allows preserving the new file by assigning it a different name
• Block upload : choosing this option will block the upload attempt without affecting the existing file in any way
• Custom renaming : choosing this option allows the user specify a format to be used when doing renames. The format will be entered in the Renaming rule text-box, and can contain user-text and dynamic data

Thanks, that´s great -- but what about the pretty popular (and BTW very often requested) option to overwrite an *existing* image or file ??

Nope, this certainly "absolute must" feature isn´t available as integral part of these two ADDT server behaviours, but very fortunately we can help ourselves by adding this missing feature to our Update Record forms by integrating a -- technically comparatively simplistic -- Custom Trigger, and this is what I´m going to walk you through in the following.

When implementing this "overwrite existing file" feature into an Update Record form that using a "File Upload" or "Image Upload" behaviour, we need to consider two possible use cases respectively preferences:

• a "just do it" approach, means that an existing file will always have to be overwritten
• the opportunity to decide what´s going to happen -- by ticking an "overwrite existing file ?" checkbox

This tutorial will be covering both use cases -- however, I´m not going to explain how to create an Update Record form or implement an "Image Upload" or "File Upload" server behaviour ;-)

2. The Custom Trigger

Regardless if your Update Record form contains an "Image Upload" or a "File Upload" behaviour, the provided Custom Trigger "Delete_Existing" will work for both behaviours, as PHP´s unlink function doesn´t care about the file type it´s supposed to delete.

a) embedding the Custom Trigger within your form´s workflow

as the deletion of an existing file will have to be executed *before* ADDT´s "Image Upload" behaviour does its job, you´ll just need to assign a lower "Priority" value to the Trigger_Delete_Existing:



your existing Image Upload or File Upload trigger



the Custom Trigger "Delete_Existing"

b) the Custom Trigger´s code

copy/paste the following code to the Custom Triggers "code" field:

// user definable variables
$folderpath = '../../tutorials/assets/'.$_GET['id'];
$filename = $tNG->getColumnValue("image");

// application logic
$fullpath = $folderpath.'/'.$filename;
if (file_exists($fullpath)) {
@chmod($folderpath,0777);
@unlink($fullpath);
@chmod($folderpath,0755);
}

...and adapt the values of the user definable variables $folderpath and $filename as described next.

c) what functionality does this Custom Trigger provide ?

user definable variables
$folderpath	Defines the relative path to the designated upload folder and can comprise URL or form parameters. This path will usually be identical to what you already specified in the Image Upload or File Upload behaviour
$filename	$tNG->getColumnValue("image"); where image is the *name* of your FILE field. This variable stores the value of your form´s FILE field and will be used to compare the value of the corresponding ADDT transaction field against a possibly already existing file
the application logic
$fullpath	combines $folderpath, a forward slash (/) and $filename to a functional relative file path
if (file_exists($fullpath)) { .... }	this condition will check if an existing file is located in the specified directory, and if so, execute the file deletion process mentioned next
deleting the file
@chmod($folderpath,0777);	as the specified directory will - on Unix/Linux systems - usually require full write permission to delete a file located within, we´re using PHP´s chmod function to set its permission to 0777 the "chmod" command is not supported on a Windows environment and will be ignored
@unlink($fullpath);	the PHP function unlink will delete the existing file
@chmod($folderpath,0755);	now that the file in question has been deleted, you can change the parent folder´s permission back to e.g. 0755. This step is of course not really required -- if you want to retain the previously declared 0777 permission, feel free to comment (//) or delete this line
the @ error control operator will suppress error warnings in case the respective function fails to be executed

3. Scenario 1: no questions asked

This simple scenario perfectly matches what´s already been described before, so your existing Update Record form will work just fine with the previously mentioned Custom Trigger "Delete_Existing". As mentioned before, please make sure that the *name* of your form´s FILE field matches the variable "$filename", as displayed next

4. Scenario 2: have a choice !

Unlike the previous scenario this advanced example requires adding a new field to your Upload form, and the original Custom Trigger will have to be slightly extended -- but what you´ll get in return, is... THIS:



4.1. Updates to your MySQL table and your form

a) add a column named "overwrite" to the MySQL table that´s storing the submitted form data, and assign the column type "char(1)", as displayed next:



This column will hold the corresponding "overwrite" checkbox value, which can - according to your preferences - be either Y/N or 1/0


b) let´s now add the corresponding checkbox to your existing form -- well, rather than suggesting to have ADDT recreate your form from scratch and add this checkbox row the usual "visual" way (what´s certainly an option worth considering if you´re less risk-averse), I´m now going one step further by providing some instructions on how the required "components" can be added in Dreamweaver´s CODE view.

I´m using this "manual" approach quite often BTW, and once I understood how it works, making amendments to an existing ADDT form turns out to be soooo much faster than having to recreate the form everytime I add a column to the database -- that said, I´m pretty sure the following explanations will help you understand how ADDT works internally, and how *easy* such things can be ;-)

1. Switch Dreamweaver to CODE and search for ADDT´s "Add columns" array -- and in here add the line...

$upd_tablename->addColumn("overwrite", "CHECKBOX_YN_TYPE", "POST", "overwrite");

...as displayed next:



2. Switch Dreamweaver to LAYOUT, scroll the page down and select the existing FILE field.

3. Switch to CODE and add the following table row code *below* the table row which comtains the FILE field:



the displayed code can be obtained from this tutorial´s "download related files" page !

4. That´s it -- needless to say that you will have to replace the dummy tablename with the real table name you´re going to update !

4.2. the extended Custom Trigger code

// user definable variables
$folderpath = '../../tutorials/assets/'.$_GET['id'];
$filename = $tNG->getColumnValue("image");
$overwrite_checkbox_name = $tNG->getColumnValue("overwrite");
$overwrite_checkbox_value = 'Y';

// application logic
$fullpath = $folderpath.'/'.$filename;
if (file_exists($fullpath) && $overwrite_checkbox_name == ''.$overwrite_checkbox_value.'') {
@chmod($folderpath,0777);
@unlink($fullpath);
@chmod($folderpath,0755);
}


4.3. exploring the additional code components

user definable variables
$overwrite_checkbox_name	$tNG->getColumnValue("overwrite"); where overwrite is the *name* of your "overwrite existing" checkbox
$overwrite_checkbox_value	the preferred "checked" value of the abovementioned checkbox. Y :: if it´s a "Y/N" checkbox type 1 :: if it´s a "1/0" checkbox type
changes to the application logic
...&& overwrite_checkbox_name...	this condition segment will (in addition to the existing file check) evaluate the transaction value of your "overwrite existing" checkbox and execute the file deletion process only if this value matches what you defined for the $overwrite_checkbox_value - variable. In simple terms :: if this checkbox remains unchecked, the existing file will not be deleted