Tuesday, November 23, 2010

Gallery Server Pro 2.4 Released

After several tireless months, last Friday I released the newest version of Gallery Server Pro. There is a new set of options for controlling the look and feel of the gallery, support for multiple galleries, new HTML 5 and CSS capabilities, performance improvements, and dozens of bug fixes.

Auto slide show and other UI customizations

Prior to 2.4, Gallery Server Pro had a single look – there was a header and footer, and the contents were either a thumbnail view of an album or a single view of a media object. This worked well for many users, but didn’t offer much flexibility when developers tried to integrate a gallery into an existing site.

For example, one couldn’t automatically show a slide show of an album on the home page. Now you can:

This screen shot – and several more below - are from the DotNetNuke version of Gallery Server Pro, but the stand-alone version works the same way. You can see the slide show in action on the home page of the online DotNetNuke Module Demo. This scenario, and many others, are made possible through a new Gallery Control Settings page in the Site admin area. Here is a screen shot of the actual settings used for the slideshow demo:

The key settings are:

View mode – By setting it to “Show a single media object”, we tell GSP to show one image at a time rather than a thumbnail view of an album. There is also a new treeview mode.

Default gallery object – We set it to the album “United States Scenery”.

Display options – We select the checkbox to override the default settings, then turn off most of the UI elements. We also turn on the option to start the slide show when the page loads.

These settings offer a lot of flexibility for controlling how your gallery looks with just a few clicks of the mouse. Each setting has a helpful popup tooltip with info and advice:

Multiple galleries

A gallery is a collection of albums and media objects that are bound together with a common set of settings, such as file storage location, watermark settings, image size, allowed file types, and whether user albums are enabled. Starting in 2.4, each web application can contain multiple galleries. This is a big difference from the pre-2.4 notion of multiple galleries, which allowed a single database to share galleries from multiple *applications*.

The demo site illustrates the usefulness of multiple galleries. There, in a single web application, are five galleries to demonstrate all the major features, with each gallery roughly linked to each menu link. The galleries are managed in the new Gallery Manager:

New concept: gallery administrator

Previous versions of GSP had site administrators, which were users who belonged to the System Administrators role. Those users had unrestricted access to the gallery. When I created the multiple gallery feature, it became apparent that some administrators would like to allow a user to manage one gallery but not others.

For example, imagine you are an IT Administrator and you want to give the Marketing and Engineering departments their own galleries. Employee Bob can administer the Marketing gallery and Vino can control the Engineering gallery. Each can view – but not manage – the other gallery. The way to do this is to assign each user as a gallery administrator to their gallery and give them view-only access to the other gallery. This particular example is fleshed out in step-by-step detail in the DotNetNuke Module QuickStart Guide.

There are two main tasks that only a site admin can do:

Enter a product key and change application settings on the Site Settings – General page.

Perform a backup and restore.

A gallery admin can edit settings for their gallery and create, edit, and delete users and roles, but they can never make a change that affects a gallery they do not have permission to administer. In the example above, Bob can create a user and give them access to the Marketing gallery but not the Engineering gallery. Nor can Bob promote himself to a site admin. And he can’t remove Vino as gallery admin for the Engineering gallery. You get the idea.

Video thumbnails

Gallery Server Pro 2.4 now supports the extraction of thumbnail images from most videos. Below is an album showing thumbnails from WMV, AVI, FLV (Flash video), MP4, DIVX, ASF, and MOV. Notice that only the Shockwave Flash file (SWF) does not have a thumbnail.

Video thumbnail extraction is made possible through the open source FFmpeg utility. Installing it is as easy as copying a single .EXE file into the bin directory. Read the Gallery Server Pro Binary Pack section below for more information.

Thumbnails from more file types

In addition to thumbnails from videos, GSP can now extract a thumbnail from these image and document formats: EPS, PSD, TXT, HTML, and PDF. Here is an example:

The open source utilities GhostScript and ImageMagick are used to generate the thumbnails. As with FFmpeg, these require Full Trust on the server. More info is in the Gallery Server Pro Binary Pack section below.

More accurate TIFF colors

A user alerted me to an issue several months ago where the .NET Framework messes up the colors of certain TIFF images when creating the thumbnail and optimized versions. Interestingly, it only happens on Windows Server operating systems – Vista and Win7 work correctly. Here is an example of how 2.3 created a thumbnail from a TIFF image on Win Server 2008:

Here is what it *should* look like, and how it now looks in 2.4:

.NET does well with most TIFF files, but I believe it has trouble with CMYK formats. At any rate, the fix was to use ImageMagick for the conversion instead of .NET.

This again requires the server to run in Full Trust. If not, GSP reverts to using .NET for the image conversion.

I’d like to throw out a special thank you to Paul Ecke Ranch who alerted me to this issue and generously donated $300 so I could focus on its resolution.

Gallery Server Pro Binary Pack

The previous features – more thumbnail support and better TIFF color processing, are made possible through three open source components:

ImageMagick – Creates thumbnail images from EPS, PSD, TXT, and PDF files. It requires GhostScript to be able to create images from EPS and PDF files.

GhostScript – It knows about the internal format of EPS and PDF files.

These utilities must be installed separately. ImageMagick and FFmpeg are EXE files that can simply be copied into the bin directory of the web application. GhostScript must be installed using a setup program. You can acquire these programs from the sites linked above or from any number of sites that redistribute them. For your convenience, I created a Gallery Server Pro Binary Pack that includes all three, including detailed instructions.

Installing these utilities is optional. If they are not present, or if the web application is not running in Full Trust, Gallery Server Pro gracefully defaults to generic thumbnails and using .NET for TIFF processing.

Note that ImageMagick also requires certain C++ components on the server. In many cases they will already be present, but if you run into any trouble, try installing the free Visual C++ 2010 Redistributable Package. A download link is included in the instructions in the download.

HTML 5 support

Most browsers – including Internet Explorer 9 – now include some level of support for HTML5. The <video> and <audio> tags in particular have great potential for Gallery Server Pro, since it offers the promise of cross-browser video and audio playback without any dependence on plug-ins. So, in the spirit of moving toward this multimedia nirvana, 2.4 now renders <video> and <audio> tags for browsers and files that support it. For example, .webm, .ogg, and .ogv files are sent to the browser with this syntax:

<video src="getmediaobject.ashx?moid=XXXX&dt=X&g=X" controls autobuffer ><p>Cannot play: Your browser does not support the <code>video</code> element or the codec of this file. Use another browser or download the file by clicking the download toolbar button above (available only when downloading is enabled).</p></video>

In Google Chrome, it looks like this (click the image to go to the actual video):

This .webm video will play in Firefox 4, Chrome, IE 9 (when VP8 codec is installed), and Opera. For IE 9 users without the VP8 codec or for versions of IE8 and earlier, users will see this:

Support for the video and audio tag is sporadic and inconsistent across browsers, so use these new file types with caution, as you may not be able to reach as many internet users as when using something more common such as Flash video.

Shorter media URLs

All recent versions of Gallery Server Pro use a custom HTTP handler to send all media objects to the browser. For example, an image tag might in 2.3 look like this:

This is better than simply linking to the actual media file for two reasons:

It allows the gallery to serve files that are stored outside the web application.

It allows the gallery to verify the user has permission to view the media object.

But as you can tell, the URL is very long. Why so long? Well, there are several pieces of information encoded into it that helps reduce the number of database lookups. However, it turns out some firewalls will block any request where the query string is longer than 2048 characters, and occasionally GSP will run afoul of this rule, resulting in media objects that mysteriously don’t work/can’t be seen.

So for 2.4, I drastically reduced the amount of data stored in the query string. A typical URL now looks like this:

So now we should avoid getting blocked by firewalls. And as far as performance, while I haven’t measured it, I think things might actually be faster (and at least one user has said this). Since GSP aggressively caches items from the database, most media objects that are requested through an URL are already present in memory, so no extra database lookup is necessary. Plus, we also benefit from not having to encrypt and decrypt data. Finally, we benefit from less data being streamed up and down the internet tubes.

Web farm support

As mentioned in the previous section, Gallery Server Pro uses caching to dramatically increase performance. However, in web farm scenarios, this causes issues because caches are stored on the server, and there is no way to purge caches on all the servers in a web farm when the data changes, leading to stale data and even errors.

2.4 now allows you to turn off the cache, thus enabling web farm support. The setting is on the Site Settings – General page.

CSS rounded corners and shadows

Gallery Server Pro has sported drop shadows around images for a while now:

The technique, which I adapted from Position Is Everything, was a fairly complicated combination of nested div tags and images. Here is what it looks like under the hood:

IE8 browsers and older will still get the old HTML, but everyone else benefits from the new CSS support.

One benefit to this change is that it is finally possible to center portrait images in the gallery. Here is how a portrait image used to look (and still does in IE 8 and older):

In 2.4, all other browsers see this:

MOV files played in Silverlight Flash instead of QuickTime

Update Dec 5, 2010: In 2.4.3, the rendering for .MOV files was switched to FlowPlayer/Flash rather than Silverlight. Read more about it in this blog post.

This version changes how .MOV files are handled. Previously, these files were played with the QuickTime browser plug-in, but in my experience it has been buggy, difficult to use, and quirky. Starting in 2.4, .MOV files are played with the Silverlight Flash plug-in. In most cases this offers a superior user experience, including a smoother install experience if the plug-in is not present.

Silverlight Flash only works, however, when the .MOV file uses an MPEG-4 codec. This is true of most newer .MOV files, but may not be the case for older ones. If you discover that one or more .MOV videos won’t play in your gallery, try renaming it with a .MOOV extension and re-adding it. .MOOV files continue to use the QuickTime plug-in.

Or, if you want to revert to the previous behavior of using the QuickTime plug-in for .MOV files, execute the following SQL against your gallery database:

You will need to restart the application pool to force the gallery to recognize this change.

Reorganized site admin pages

Here is the updated admin pages menu:

No major changes, but there were some opportunities for improving the organization. The Site Settings section is reserved for site admins – gallery admins won’t even see it. The new Gallery section contains gallery-level settings.

Remember the e-mail settings page in 2.3?

This page has been merged into the Gallery Settings page. And I finally fixed something that bothered me for a while: What was the deal with the Gallery Administrator on the e-mail page? It’s not a real account and is only used for e-mail. Confusing if you ask me. So I deleted the two settings that had been in galleryserverpro.config (EmailToName, EmailToAddress) and replaced it with a new setting UsersToNotifyWhenErrorOccurs. This setting stores a list of user accounts that should be notified when an error occurs.

The upgrade wizard will automatically migrate this setting to the correct user if you have a user with the same e-mail address as is specified here. You should probably check this after the upgrade to make sure it is set to the desired user.

Optional treeview navigation

There is a new option for browsing your media gallery. If you turn on treeview navigation, a treeview of albums appears on the left side of the screen:

The treeview loads quickly because only the top level albums are displayed by default. As you drill down, efficient AJAX callbacks populate the nodes. Clicking any album causes the album contents to appear on the right.

Turn on this feature on the Gallery Control Settings page:

Increased limits for album and media object data

The maximum number of characters has increased for several types of data:

This change was made possible through the use of the nvarchar(max) data type in SQL Server. Since this type was introduced in SQL Server 2005, Gallery Server Pro 2.4 no longer supports SQL Server 2000.

Eliminated galleryserverpro.config

Back in July I blogged about how I was essentially forced into getting rid of galleryserverpro.config so that the gallery could support the multiple portals feature in DotNetNuke. But this has been a blessing in disguise, as eliminating the file has two benefits:

Less app restarts. The nature of the ASP.NET configuration system requires that any changes to a config file triggers an application restart. This causes issues like synch and file upload failures when an administrator makes almost any change to a site setting. Now that the data is in the database, admins can change these settings without affecting users. Note that there is an empty galleryserverpro.config file where the old file used to be – it is there solely to prevent an error the first time you run the upgrade wizard, since at that point you are still using the old web.config file that expects the gsp config file to be there. Feel free to delete the file when you are done installing or upgrading.

Better architecture for future changes. With the data in the database, it becomes easier to programmatically manage. In particular, writing an upgrade wizard that dealt with XML files was a chore. It also becomes easier, for example, to write an admin page for editing the browser templates (formally known as HTML templates).

There is one downside to eliminating the file – manual changes must be made against a database table rather than an easy-to-edit XML file. One of the more common situations where this comes into play is needing to set ShowErrorDetails to true when the app doesn’t load and you need to see the error message. To help address this particular situation, I tweaked the logic so that error details are *always* shown when debug is set to true in web.config. That is, if an error is preventing you from loading the app and you want to see the error details, open web.config and look for this line:

<compilation debug="false">

Change it to this:

<compilation debug="true">

Of course, you can still go into the database table gs_GallerySettings and set ShowErrorDetails to true, but most of you will find this easier.

Removed dependence on ASP.NET profile provider

One thing I have learned over the years is to minimize the amount of stuff you have to add to your web.config file. Anyone who has tried to manually merge GSP’s web.config file with their own app’s config file will agree. So when I was presented with a choice a few months ago – revamp the profile system to support multiple gallery settings or build a completely new profile system – I jumped at the chance to migrate away from the ASP.NET profile provider. There are two main benefits:

GSP no longer has to worry about a properly configured profile provider in web.config.

Developers who are already using the profile provider in their app no longer have to manage two subsystems (their app and GSP) that might both share the same profile configuration.

Profile data is now stored in a new table gs_UserGalleryProfile. The upgrade wizard automatically migrates data from the aspnet_Profile table into the new one.

Improved install and upgrade wizards

The upgrade wizard has several changes, as it necessarily must to handle the uniqueness of each major upgrade. It is more robust, with more informative error messages, better error handling, and the ability to modify your existing web.config file. It is also designed to be repeatable. That is, if an error happens early in the upgrade process, you can re-run it and it will resume where it left off.

Both wizards detect when they are needed and start automatically. For example, when a copy of galleryserverpro_old.config is in the gs/config/ directory, the upgrade wizard will start. If the file install.txt is present in the App_Data directory, the install wizard will start. Note that for performance reasons, the app checks for these files only when the application first starts, so if you need to trigger these wizards at some other time, you can still do it by appending “?g=install” or “?g=upgrade” to the query string.

Upgrade warning: change in role constraint

A change in the structure of the table gs_Role may affect a small number of you when you upgrade. Who is affected? Anyone who has more than one gallery web application that shares the same database. In other words, anyone using the multiple gallery feature of 2.3.

If this might affect you, read this thread for details on how to prepare the gs_Role table before your upgrade.

Where is version 2.4.0?

The DotNetNuke module, the stand-alone version, and the Microsoft Web Application Gallery version all share the same code base. Shortly after releasing 2.4.0 of the DotNetNuke module, a few bugs were found before I could release 2.4.0 of the stand-alone version, so it was never released. Similarly, a few bugs have already been found with 2.4.1 before I could release the DotNetNuke 2.4.1 version, so by the time that gets released, it will be 2.4.2 (or maybe even higher). As I write this it sounds like it could get confusing, so I am open to changing this, but at present this is what is going on.

New product key and option to hide footer

This version requires a new product key. As always, it is completely free, although your donation is what allows me to continue working on it. Please support it so I don’t have to get a real job (which I am dangerously close to having to do). As an extra incentive to donate, I offer two great rewards to those who donate $50 or more: (1) A copy of the Dilbert book Casual Day Has Gone Too Far, and (2) A special product key that hides the Gallery Server Pro logo at the bottom of each page.