This is something of a catch-all site. I use it mainly as a staging site for projects and site configuration schemes.  You are likely to find most anything here. If you are interested in my photography I recommend you visit my other websites: Tulsapanoamic.com and PhotographingTulsa.com.

The site also demonstrates the functionality of the zifimage module - a sandbox project I started at Drupal.org. It is intended to replace the ancient zoomify module which apparently has been abandoned by its creators/maintainers. My original intent was just to add support for the ZIF format.  It allows encoding the tile structure used by the Zoomify viewer into a single file.  I like to think of the zif file as a type of file archive which can be unpacked on the fly so to speak. I think the problem with the older code was in part related to the fact that the Zoomify JavaScript viewer is not a single piece of javascript but a family of viewers.  There are the free viewer and Three levels of commercial viewers: Express, Professional, and Enter[rise. Each more powerful than the last. The old code was intended to support the free viewer. At least It did not offer any support for more advanced use of the other viewer families. The free viewer will not support the ZIF format.  So, of course, the module maintainers could not add that functionality. At least that would be an acceptable excuse.  er Rational, for not doing it.

When I reviewed the cost/feature I discovered that the cost o was modest. At least up through the Professional level package. So I forgot about the free version and just went with the Professional one. The zifimzage module was developed based on the V4 Professional Version of the Zoomify viewer family.  It does not support ALL of the capabilities of V4 or V5 but only a subset of the possible display modes.  It's a pretty good subset, however. There are 7 major modes of operation:

  • Single Image
  • Destinations
  • Slide Shows
  • Image Comparisons
  • Animations
  • Image Overlays
  •  Geo-Coordinate Display

The commercial viewer families are controlled by XML command files. A different one for each Display Option. I call them modes of operation. 

You can also supply individual commands (Zoomify calls them HTML commands) either to all images and displays or by image instance.  A good bit of the complexity of the module stems from the concept of image standardization and flexibility. I don't like rigidly formatted structures. Indeed, there always exists the need to customize the Image Display to its function. The module has a configuration section which applies site wide. It will always generate a set of values even if you don't set then. If you don't like the hard-coded default values, just specify new ones. If a particular Image display needs a different set of specs you can specify them at the Image Instance Level and the site defaults will be overridden.

I did this by leaving the fields blank. Blank or no value fields? Use the site defaults Field has a value use it.  I found that the various modes of operation NEED different size containers to look good. So it's a feature you WILL use. 

Unfortunately, the use of empty fields has exposed a bug in the support module filefield_paths.  It will throw warning messages if all the TEXT fields in the node instance are not filled out. It.s a subtle bug and as it doesn't seem to stop it from working on the file directory token translation. I tried to ignore it. Crashed my development sit.tem. Took out all of Drupal and Apache was damaged as well.  On my production test/demo site, it took out 4 websites, Drupal and all database files.  You MUST fix it. I raised the issue with the maintainers but have had NO response.  I've spent over a YEAR trying to contact them. I'm not pleased.  The fix is simple. In an if statement there is a "==" sign which probably should be a "!==".  Probably a typo. It occurs on line 465 or thereabout in the file field_paths.module file. So far I've had no problem with the modified module.  I would still like a qualified reviewer to look at the change though.

Installation is fairly complex as well. Eventually, I will have a set of video tutorials on how to Install and Use the module.

Security is a concern.  The module has a lot of user input. file names, control files, control commands all could be used as attack vectors.  I discussed this with the Zoomify support staff and they seemed to think the js code was sufficiently guarded that more security was not needed. So I stopped developing it.  In the area of HTML commands (There are over 200 commands) I did write some code. Based on your level of paranoia you may want to enable some of it. I leave it off.  The security is provided in three layers. First restricting the input character set to only those needed to input the commands. Secondly, you can force the commands to be a member of the HTML command set. Thirdly you can force the VALUE of the comment to be of the correct TYPE.  The type checking should be considered experimental. There 260 commands and while I made an attempt at type checking I relied on library supplied regular expressions and have not tested each one. Hey, it IS a sandbox project!


Drupal 8/9. Right now I can't figure out D8 much less D9.  They have loaded too much new functionality for my ancient brain to easily comprehend.  So I won't LOOK a coding for D8 until I have to upgrade my websites.  Since D6 sites are STILL around that may be some time.  I guess it all depends on the level of interest. Does anyone care about the module? I will wait and see.  With the V5 code, I think I will need to re-envision the module and rewrite it completely. 


I have been experimenting with video files and editing lately.  I have added files directly too the site as well as files hosed by Youtube.  Youtube seems to play faster and with fw pauses for buffering.  Still all he files are short. I am not sure what will happen to Youtube in the comming years so I want the ability to host y own video's.