Hi All,

I use come different plugins with CKEditor from time to time, and I thought I might share this information in case it is useful to someone.

Adding or removing plugins before the editor loads is a piece of cake. This can be useful if you want to include plugins which are not part of the WebAssist HTMLEditor extension. To use plugins that are not part of the WebAssist HTMLEditor extension, you either need to hard code the plugin into the configuration file for CKEditor, or add a line to the generated code. In either case, when you edit the editor instance, you have to reapply your changes.

NOTE: You can make changes to the CKEditor config.js file in the DreamWeaver configuration directory. Then you changes would appear EVERY time you use the editor.

This is also useful if you have hard coded an additional plugin because you use it most of the time, but don't want it on a particular page. In that case, you can't use the WebAssist GUI to control the plugin.

With this method, you won't have to do anything to the WebAssist code when you edit the HTMLEditor instance.

To include or remove an additional plugin to the editor per page, do the following:

The extension includes the CKEditor JavaScript file when the PHP code for the editor instance is created. That isn't soon enough to do this, so in the head of the document, include the file yourself.

<script type="text/javascript" src="/webassist/ckeditor/ckeditor.js"></script>

Now the object CKEDITOR has been instantiated. Just below this inclusion, add the following code:

<script type="text/javascript" src="/webassist/ckeditor/ckeditor.js"></script>
<script type="application/javascript" language="javascript">CKEDITOR.config.extraPlugins = 'bbcode';CKEDITOR.config.removePlugins = 'smiley';
</script>

This code would include the bbcode plugin and remove the smiley plugin from all subsequent CKEditor instances on the page.

I have not looked into adding or removing a plugin after the CKEditor instance has been created, so I do not know if that is feasible. That would be helpful for adding or removing plugins to a specific instance of the editor. Right now, the best way to do that is to add a line to the WA code like this:

$CKEditor_config["extraPlugins "] = "bbcode, adobeair";
$CKEditor_config["removePlugins "] = "smiley";

The above code will have to be redone if you use the WebAssist GUI to edit the instance of the HTMLEditor.

This article is writen for users of WebAssist HTML Editor, but it can be applied to any ckeditor application.

When I wrote this, I was still using what I believed was the latest version of CKEditor in DataBridge (3.6.4). I since learned that that last update included version 4.0. I have confirmed that this works with CKEditor 3.6.6.1 which was actually released after 4.0. CKEditor is on version 4.02, and will be pushing out version 4.1 soon. I have looked at the source files and I believe this patch will work with CKEditor version4, at least as of the last build I looked at. The line numbers have changed, but this part of the code looks to be the same. However, I have not figured out how to get the source files and correct ckeditor.pack file together to incorporate this patch into CKEditor4 and test it.

The CSS matching is far more important to me. I am going to stay with CKEditor 3.6.6.1 until I can sort out version 4. I am attaching a zip file of the CKEditor file that I use for anyone who is interested. The patch has already been compiled into it. I make no promises. Backup what you have, but it works for me. This zip file also contains KCFinder as a file manager. The lines to implement it are commented out in the CKEditor config.js file. If you want to get away from KFM, just uncomment the lines. Implementing Security Assist to work with KCFinder is easy, but that would have to be another post...

 ckeditor_ver3.6.6.1_patchedBodyPreappend-BodyAppend.zip

(Note, I have made some modifications to this for issues I found with this patch. See my comments HERE and HERE for more details. The download file has NOT been updated at this time.

I don't know how many of you struggle with this, but I have always struggled to get the css in the editor to match the website. Recently, I found this post.

The plugin proposal by ElMoonLite, allows you to wrap the editor contents inside other HTML elements which will not be saved but will impact the css of the editor contents.

In other words, instead of having a body class and trying to make everything match the site contents, you simply wrap the editor area with the same HTML elements that would wrap it on the actual output page. Then just attach the same css file that the site uses, and you're home free (except for any css specified on the output page itself).

WARNING: THIS INVOLVES CHANGING CKEDITOR CORE FILES. DON'T FOLLOW ALONG UNLESS YOU HAVE THE STOMACH FOR IT.

WARNING 2: You MUST have "Encode HTML Entities" unchecked in the Editor Settings under the Formatting tab or the editor messes up the second comment tag used to remove the prepended and appended information before saving.

WARNING 3: I've only tried this in a couple of configurations and only using XHTML 1.1 and HTML 4.1 Transitional. Test before deploying.

To do this, you have to go into the .../ckeditor/_source/plugins/wysiwygarea directory and edit plugin.js according to the instructions located HERE.

You can test it by editing ckeditor_php5.php (or ckeditor_php4.php if you are using 4) and changing:

$out .= "<script type=\"text/javascript\" src=\"" . $ckeditorPath . 'ckeditor.js' . $args . "\"></script>\n";

to this:

$out .= "<script type=\"text/javascript\" src=\"" . $ckeditorPath . 'ckeditor_source.js' . $args . "\"></script>\n";

If you are not using HTMLEditor, just change your reference from  ckeditor.js to ckeditor_source.js. If you make the change above, this is just for testing, so you will want to change it back once you see that it works.

Be sure to change your css references so that you are only referencing the css of the web site and that the body class is N/A.

Now, edit the config.js file in the ckeditor root directory by adding these lines:

config.bodyPrepend = '<div id="pageWrapper"><div id="contentWrapper"><div id="content">';
config.bodyAppend = '</div></div></div>';

Change the HTML elements to match your site. Be SURE to only include the elements that are parents of the location the editor's contents will be placed. In other words, don't include the header/banner, horizontal menu, or column elements. The best way to think about it is if you wrote a CSS rule that specifically addressed your content area, what would the rule look like. Those are the elements you need to include.

Once you see that it is working (or if you skipped testing), you need to compile the _source directory into a new ckeditor.js and a new ckeditor_basic.js.

To do that, get the files from HERE (You need both the jar and exe file for widows, and you must be running Java on the computer). Windows users may also find this TIP helpful.

To make this change permanent to HTMLEditor, copy the config.js and config_basic.js files from your site to the configuration folder. Remember you'll have to redo this if you update HTMLEditor unless you protect your source files.

On windows, that would be something like:

C:\Users\[User Name]\AppData\Roaming\Adobe\Dreamweaver CS6\en_US\Configuration\Shared\WebAssist\RichTextEditor\Source\ckeditor

Hopefully the next update for CKEditor will contain this feature.

That's it. Thanks to all the people who posted the content I referenced here.

If you find any other issues that break this like I found the use of HTML Entity Encoding breaks this, please let me know. My tests say it works. It should be fairly bullet proof in terms of what an end user can do to break it, but there may yet be issues with how it works with different editor configurations.

I have updated the WebAssist reoder code to make it easier as I am updating a significant number of files and wanted to reduce the headache. Be warned. This has not undergone extensive testing, but it is WAY easier than before.

Here are the files: reorderDA2.class.zip

FILE UPDATED 3/19/2013.

• The code was checking for whether the query was sorted by the sort colum but not adding it to the query. Fixed

FILE UPDATED 3/31/2013.

• If you set the rows to show more records and the page number value became invalid, and error would be thrown. Now it steps back one page at a time until it finds the correct page to display. Fixed

The instructions are similar to the original post HERE, so I will make this brief.

1. Follow the first step and include the file only the current name is reorderDA2.class.php
   
   
2. Next, and this is where it gets easier, just include the following below the WADA Databridge recordset.
   
   
   Now the parameters are just the text portion of the connection variable and the table name.
   If your cannection variable is $connReorder, the first parameter is "connReorder".
   Also include the sort column name if it is not sortorder.
   Lastly you can include an array for the choices on how many records to display, so it looks like this:
   connection (string), table name (string), sort column name (string), display # records (array)
3. Next follow the step for inserting the head code, and that is it.
4. If you are using the current version of WADADB, your're done, but if you are using a custom form, or you are adding this to an old form, you need to follow the step to adjust the table.

I've tested this against the old and new forms. I'm using the WebAssist=>Database=>DataAssist Pages gui to generate the pages, so if you're making custom forms and it doesn't work, please let me know, though I may not do anything about it, if it is easy, I will. I'm basically generating the pages using this GUI with no template and then adding the template (or theme) afterwards. This is designed for site backend use, so custom page structures are generally not needed.

If it works for you the way it is working for me, this method adds all thepage elements you need and even adds the sort column to the query if you forgot to add it since it is generally not displayed. Updating some of my ADDT and older WADA pages just got easier!.

Hope this helps.

Steven

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.

getDirectory.zip

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:

1. Include the function file from the link above at the top of the file
2. Whatever code or validations you have before the update stuff begins.
3. The WA recordset that includes the image field.
4. The upload transaction.
5. The Delete transaction with the name check conditional statement.
6. The code snippet that deletes the resized images (remember to customize the confguration values at the top of the snippet).
7. The update transaction that ONLY:
   1. Triggers on successful upload,
   2. Updates the image file field with the uploaded server name, and
   3. DOES NOT redirect the page when completed.
8. 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.

I have read several discussion on this but I have not seen what I believe to be a good answer to the various possible conditions.
I believe I have a reasonably strong solution, but would love to hear from anyone who could improve on it.

The issues:

1. Delete the old file if there is a new one uploaded.
2. If the new file uploaded has the same name as the old one, DO NOT ACCIDENTALLY DELETE THE NEW ONE WHEN USING THE OVERWRITE METHOD FOR THE FILE NAME
3. Save the old file and do not update the database field if the upload fails

To do this, I added a file delete behavior for the existing file name in the database, then the upload behavior, and triggered both off the submit button.

Then the update transaction. You may have to juggle the code around to get it in this order.

Now, here is the trick. Enclose both the delete and the upload transactions in a PHP if statement that checks for whether or not there was an error in the file upload.
(Note the value of the PHP $_FILES array for the error key IS 0 if there were no errors, and an empty file field actually produces an error code of 4)

Now set the update binding for the file name to the WA Server File Name ($WA_DFP_UploadStatus["WA_UploadResult1"]["serverFileName"]) with a default to the recordset value of the file name (the original file name)

If there is any upload error, the WA upload code will not be executed, so $WA_DFP_UploadStatus["WA_UploadResult1"]["serverFileName"] will not be set.

Now if no file is uploaded, or there is any error in the upload, nothing will be deleted or uploaded (copied from temp to the web site space), and the file name will remain unchanged.

If a new file is uploaded, the old will be deleted, the new uploaded, and the database updated correctly.

If the new upload has the same name as the old one, the old file will be deleted first, the new one uploaded, and the database name will still be correct.

None of this will protect against collisions with the same file name from a different record, so always use caution with overwrite.

This method will also work fine with a renaming scheme like incrementing except you will never increment unless the file with the same name belongs to another record.

It would also work with a fixed file name like File_RecordID.jpg