Thursday, April 10, 2014

Show high-resolution image during slideshow

You can view a slideshow in an album by clicking the Play slideshow button that appears above an image:

slideshow_start

By default, the slideshow scales to use the entire browser window to show the web-optimized version of the image, as seen below.

slideshow_opt

For most people, the web-optimized version is preferred over the original. It’s a much smaller amount of data sent to the browser (around 50 KB instead of 3,000-20,000 KB). This results in faster loading pages, less bandwidth requirements, and greater ability to scale.

But some of you may prefer to see the high resolution originals. You want to see the full detail in your photographs and aren’t concerned about the larger size travelling across the wire. Well, here’s an easy edit to make it happen.

  1. Open gs\script\gallery.min.js in a text editor.
  2. Look for this text: Gsp.getView(j, Gsp.Constants.ViewSize_Optimized)
  3. Change it to this: Gsp.getView(j, Gsp.Constants.ViewSize_Original)
  4. Save and close the file.

Hit F5 to refresh the script file in your browser and take a look at the slideshow. Notice the increased detail you can see in this example (click for a larger version):

slideshow_original

Keep in mind that if your original images are in a format that can’t be rendered in a browser (RAW, TIF, WMF, etc), this obviously won’t work. And if you have a slow internet connection or your files are particularly big, the slideshow may not work very well.

Cheers!

Gallery Server Pro not vulnerable to Heartbleed bug

A vulnerability in OpenSSL (CVE-2014-0160) was disclosed a few days ago. It has been named the Heartbleed bug. There is a lot of concern due to its seriousness, widespread impact, and difficulty in fixing.

I just wanted to confirm that Gallery Server Pro is not vulnerable because it cannot run on the platforms where it exists. Gallery Server Pro is based on .NET and must run on IIS on a Windows Server. A blog post from Microsoft employee Ben Ari confirms that default configurations of Windows do not include OpenSSL. He writes that one *could* use OpenSSL on Windows by running the Windows version of Apache, but GSP cannot run under Apache, so this is not applicable to us.

So, no worries about the Heartbleed bug with Gallery Server Pro.

Monday, March 31, 2014

Gallery Server Pro DotNetNuke Module History and Roadmap

Gallery Server Pro has been available as a DotNetNuke module since 2.4.0 was released in 2010. Subsequent releases of Gallery Server Pro have always had a corresponding DNN module release…until 3.0 was released in June 2013. Version 3 was a significant release, introducing—among other things—a new data layer built on Entity Framework Code First Migrations 5.0. Using EF CF Migrations greatly simplified data access, as we no longer had to maintain separate code bases for each database technology (that is, SQL Server and SQL CE).

However, EF CF Migrations had a limitation that was incompatible with DNN—one could have only one migration model per database. Since the GSP module shared its data access with a variety of other modules as well as the DNN core, it would be asking for trouble for the module to assume it could have the only allowed migration model in the database.

But there was hope, as the EF team recognized this issue and promised to support multiple models in 6.0. And so we put the 3.0 version of the GSP DNN Module on hold until EF 6 was released. Indeed, they delivered on their promise in October 2013. We eagerly upgraded to this version as we prepared to hunker down on the DNN module. Unfortunately, we immediately hit a snag. The ASP.NET Universal Provider library, which is used to provide membership and role services, didn’t work with EF6. Microsoft recognized this and resolved the issue when they released Microsoft ASP.NET Universal Providers Core 2.0 in December 2013.

Finally, the pieces were in place to proceed with the GSP DNN module.

Unfortunately, more roadblocks…

In the last few weeks we’ve been sitting down and taking a serious look at what it’ll take to merge the GSP 3.0 code with the GSP DNN module 2.6 source code. Despite resolving the initial roadblocks, significant hurdles remained.

Lack of DNN support for EF CF Migrations

DNN assumes that a module builder follows a specific data architecture that involves generating the required data structure as SQL script files that are executed by the DNN module installer. Then all data access is performed by executing manually-generated SQL statements against the database or invoking stored procedures.

But EF CF Migrations generates and executes the SQL for us, making integration with the DNN architecture problematic. We tried to find out if and how others were building DNN modules using EF CF Migrations but couldn’t find anyone who is doing this. At this point it is not clear to us whether it is even possible. We don’t mind being trailblazers when appropriate, but we’d rather not take on a huge amount of risk when dealing with something as mundane as accessing the database.

JavaScript and jQuery widget issues

Version 3 dramatically increased the number of jQuery widgets. These widgets provide a lot of flexibility and work well with the jsRender-based UI template architecture. But jQuery widgets are tricky to use in an environment where others may be using the same—or similar—widgets. For example, how does one handle the situation where two modules are on the page, and each module uses a different version of jsTree? In reality, you can’t make it work unless you jump through hoops like building a forked version of jsTree with a custom name.

There are other risks as well. The increased use of JavaScript everywhere (the GSP DNN module, other 3rd party modules, and the DNN core) has increased the risk of conflict and hard to find bugs. For example, GSP adds a trim() method to the String object when it’s missing:

if (!String.prototype.trim) {
   // Add trim() function for browsers that don't implement it (IE 1-8).
   String.prototype.trim = function () {
     return this.replace(/^\s+|\s+$/g, '');
   };
}

What if another module beats us to it and defines its own implementation? We get unexpected behavior and you think there’s a bug in GSP. As you can imagine, this type of issue is pretty much impossible to test for or prevent with any degree of certainty.

web.config changes

All ASP.NET applications share a web.config file in the root that defines certain behaviors. GSP has this as well, where we define things such as the EF version, the membership provider, and Web.API configuration. The DNN module version of GSP also requires most of these things in the web.config file. But since this file affects the entire application, including other modules, there is a substantial risk that the configuration required for GSP conflicts with someone else’s configuration requirements.

Furthermore, Web.API requires setting up routes so that ajax requests get sent to the correct controller. GSP defines what it needs, but these may conflict with routes defined in other modules or the DNN core.

Object qualifier and database owner

DNN recommends that tables be created with support for a custom object qualifier and database owner. That means the SQL scripts that create the tables look something like this:

CREATE TABLE {databaseOwner}[{objectQualifier}gs_Album](...)

Since EF CF Migrations generates tables by reverse engineering the code first model, support for this kind of customization is difficult or possibly impossible. Skipping support for this leads to the possibility of a module installation damaging the database if a user attempts to install the module on two different installations hosted inside the same database. Not cool.

Decline of DNN

Perhaps the most significant issue for us is the signs that the DNN ecosystem is dying. Take a look at this chart generated from Google Trends:

dnn_trend

Searches for the term DotNetNuke peaked in 2006 and have dropped to almost nothing since then. Much of this, of course, is the name change from DotNetNuke to DNN. But even the term DNN peaked between 2006 and 2009 and is down by about 50% since then.

There are other signs, too. Go to any job site and compare the jobs for DNN with those of other CMS’s. DNN is dwarfed by jobs for WordPress, Drupal and Joomla. Even among .NET CMS’s, Umbraco has overtaken DNN as the go-to CMS.

Sales of the GSP DNN module have never been great. We have yet to recover the resources we have put into it over the years.

The unknown

Developing the GSP DNN module in 2010 took far longer than we expected due to surprises we encountered along the way. For example, DNN disables the native .NET localization services GSP used to provide language support. We spent a ridiculous amount of time trying to figure out how to get DNN to serve text from GSP’s resx file. We fear more such issues as we ponder the 3.0 migration.

Moving forward

The issues described above have been heavily weighing on our minds, and we had to make a decision about how to move forward. If we poured resources into supporting DNN, it takes away from adding cool new features to the core GSP product. More importantly, we're not sure it's even possible for GSP 3 to run as a DNN module. At the very least, it would be significant undertaking.

Ultimately, we have decided to no longer support DNN. That’s a painful sentence to write, as it’s like abandoning one of our children. Plus, we know there are many of you who have been looking forward to continued DNN support. But we need to do what serves the greatest good for the most customers, while allowing us to keep paying the bills.

If you currently use GSP DNN Module 2.6, be assured it will continue to work indefinitely. And remember that you can always install the latest version of GSP as a stand-alone instance and link to it from your DNN site.

As for us, we are putting the finishing touches on a 3.2 release. This will be a free update to all 3.X license holders. Details will be shared soon. After that, we’ll be hunkering down on version 4.0, where we plan several significant features you’re just going to love.

The future of GSP is bright, and we love that you’re coming along with us for the ride. Great things to come!

Wednesday, January 15, 2014

Eliminate startup delay in your galleries using Application Initialization

It is well known that ASP.NET applications have a startup delay after they’ve been idle for a while. Every once in a while someone posts in the forum that the gallery is slow to load at first and then is quite fast. That’s because IIS is doing a lot of stuff when that first HTTP request comes in:

  • Spins up an application pool
  • JIT-compiles the code
  • Performs view generation of the EF model
  • Loads HTTP modules
  • Runs initialization code in GSP, which connects to the database and loads application settings and other lookup data.

All that takes a few seconds, which isn’t terrible, but first impressions are important. Wouldn’t it be better if IIS handled this before that first HTTP request comes in?

Well, it can. It’s called Application Initialization and is available in Windows Server 2008 R2 and higher. Once configured, the gallery application is always warmed up and ready to instantly serve HTTP requests, even after periods of inactivity that would normally shut down the application pool. Sweet!

It’s a little tricky to set up, so let’s run through the details.

 

Application Initialization in Windows Server 2008 R2 (IIS 7.5)

In Windows Server 2008 R2, use the Microsoft Web Platform Installer to install Application Initialization. Once installed, configure it by editing applicationHost.config, which is at %WINDIR%\system32\inetsrv\config.

  1. Open applicationHost.config in Notepad, being sure to run it with the "Run as Administrator" option.
  2. Find the <applicationPools> configuration section, and then look for the application pool running your gallery. If you don’t know the pool name, look it up in IIS Manager by right-clicking the application node in the left pane and choosing Manage Application > Advanced Settings. Add startMode="AlwaysRunning" so that it looks like this:

    <add name=".NET v4.5" startMode="AlwaysRunning" managedRuntimeVersion="v4.0" />

  3. Scroll down a little more in applicationHost.config to the <sites> configuration element. Find the entry for the gallery application and add preloadEnabled="true", like this:

    <application path="/gallery" preloadEnabled="true" applicationPool=".NET v4.5">

  4. Restart IIS by executing iisreset in a command prompt running as an administrator.

That’s it. Your gallery is now always running in a warmed up state and ready to instantly serve users. You can test it out by temporarily changing the application pool timeout to one minute, then waiting a couple minutes and browsing to your gallery.

 

Application Initialization in Windows Server 2012 and higher (IIS 8+)

In Windows Server 2012 and higher, Application Initialization is included in the OS but it must be enabled in the Add Roles and Feature Wizard:

app_init

One installed, you can now configure it with IIS Manager – no need to edit applicationHost.config.

  1. Open IIS Manager and navigate to the application pool the gallery is running under. Right click it and choose Advanced Settings. Verify the Start Automatically setting is set to True and the Start Mode is set to AlwaysRunning. Click OK.

    app_init2

  2. In the left pane of IIS Manager, navigate to the gallery web application. Right click the application node and select Manage Application > Advanced Settings. Set Preload Enabled to True.

    app_init3

  3. Restart IIS by executing iisreset in a command prompt running as an administrator.

That’s it. Your gallery is now in an always-on state.

 

Common mistakes

The web is filled with people talking about how they can’t get this feature to work. I’m guessing it’s because they missed one or more of the four critical steps. If you’re having trouble getting things going, make sure you did these steps:

  1. Installed Application Initialization (either through Web PI for IIS 7.5 or through the Add Roles and Features Wizard for IIS 8+).
  2. Application pool has Start Automatically = True.
  3. Application pool has Start Mode = AlwaysRunning.
  4. Application has Preload Enabled = True.

Monday, December 16, 2013

Save time editing media properties with multiple select

This is a great trick that lets you spend less time managing your gallery and more time sharing it with others. You probably already know you can easily edit the property of an album or media object using the right pane. For example, here I’m tagging a photo with the word ‘Bird’:

meta1

Notice as I type I get a drop down showing tags that have been applied to other gallery objects. This makes it easy to reuse tags and prevent misspellings.

We can also tag media objects from the album thumbnail view by selecting the media object and applying the tag:

meta4

TIP: When selecting the thumbnail, be sure to click in the border area outside the image. If you click the image, the gallery takes you to a page showing the full size version of the media object.

Okay, updating one media object at a time is easy enough. But what if you want to apply a tag to a bunch of items at once? For example, what if you want to tag every photo in an album with the word ‘Bird’? The answer lies in the multi-select feature built into Gallery Server Pro. Select the desired items and then update the property. When you exit the field, your changes are applied to all selected items.

There are two ways to select thumbnails: drag-select and control-click. Drag-select means using the mouse to drag a rectangle around the desired thumbnails. Control-click involves holding the Ctrl key down and left-clicking thumbnails. When a tag has been applied to more than one item, it displays the quantity in parentheses. Here I’ve drag-selected the thumbnails and applied the ‘Bird’ tag to all 25 photos in the album:

meta5

Deleting tags from multiple items is just as easy. Select the thumbnails and then click the ‘X’ on the tag you want to delete.

This trick works for any of the properties in the right pane. For example, you can change the title of all items and then edit individual ones as desired. Or control-click your favorites and give them a five-star rating with a single click.

Note that some properties are not editable by default. For example, the width and height of images are read only. To make them editable, go to the Media Objects – Metadata page in the Site Admin area and select the Editable attribute for the desired properties.

Editing the properties of multiple items at once is a big time-saver. Enjoy your gallery!

Wednesday, December 11, 2013

Gallery Server Pro 3.1 API Documentation Released

Today we released the Gallery Server Pro API Documentation, freshly updated for 3.1. This is primarily a resource for developers who want to better understand  the namespaces and classes used in Gallery Server Pro.

This documentation can be accessed any time from the support page.

Monday, December 9, 2013

Gallery Server Pro Binary Pack Updated

Today we released an updated version of the Gallery Server Pro Binary Pack. It contains the latest versions of three open source utilities that give you advanced gallery functionality such as audio/video transcoding and video, PDF, TIF and EPS image generation. They are ImageMagick 6.8.7, FFmpeg 2.1.1, and GhostScript 9.10.

To update your gallery, download the Binary Pack, extract the contents from the zip file, and copy convert.exe and ffmpeg.exe over the existing files in the bin directory of your web application. GhostScript is updated by copying gs910w32.exe in the GhostScript directory to your web server and then running it. If you are using a web hosting company, you likely aren’t allowed to run executables on the server. In this case, the best you can do is create a support ticket to ask them to do it.