Thursday, July 17, 2014

Did you know you can change your file names?

This is one of those hidden gems in Gallery Server Pro that is not widely known but can be really handy. You can modify the underlying file name of any media object through the gallery UI.

You already know you can edit several attributes of your media assets in the right pane. The common ones are title, caption, and tags, but any property can be editable. In a default gallery, the file name is visible and read only:

fn_metadata1

To make the file name editable, go to the Metadata page in the site admin area. Find the row for the FileName property and check the box to make it editable. Note that there is a quirk in the jQuery grid widget that requires you to tab *out* of the cell before saving, so be sure it has the green check mark when you save.

fn_metadata2

That’s it. Notice you can now edit the file name for any asset:

fn_metadata3

Changing the file name updates it in two places – the Metadata table in the database and the file system on the server’s hard drive. This can be handy for cleaning up those ridiculous names that come out of your camera.

A few things to note. If you pick a name that is already used by another file in the directory, Gallery Server Pro will automatically tweak it until it is unique. For example, the name MyPhoto.jpg may become MyPhoto(1).jpg.

The names of the thumbnail and web-optimized versions are not updated. Not a big deal for the thumbnail version but the optimized file name is used when you are downloading the image:

fn_metadata4

This might be a bit of a nuisance, so I plan to correct this in a future version.

Another thing is when you are running a gallery in read-only mode (i.e. the option ‘Media files are read only’ is selected on the Media Objects – General page), the file name is not changed on the hard drive. The meta property, however, is updated, since that is just a database value. This might cause some confusion, so I’m guessing those of you with read only galleries will want to leave this property read only.

Lastly, this trick applies only to the FileName metadata property. A related one – FileNameWithoutExtension – does not persist changes back to the server’s hard drive. It only updates the database value, just like the vast majority of the other properties.

Thursday, June 19, 2014

WPI version of Gallery Server Pro released

Microsoft has completed their testing of 3.2.1 and published the new version to their web application gallery. A link to install it is on the download page.

Monday, June 2, 2014

Gallery Server Pro 3.2.1 Released

Today we released 3.2.1, which contains a small set of bug fixes and a couple minor behavior changes. There are no changes to web.config or the skins, so upgrading from 3.2.0 is as easy as copying the files from the upgrade package over the existing files in your gallery. Instructions for upgrading other versions are in the Admin Guide.

Bug fixes

  • Left pane UI template partially updated during upgrade
  • Parent nodes in the tree cannot be unchecked in certain cases
  • Quotation marks in user and role names cause trouble
  • Page scrolls to top when dialog auto-closes

The first two bug fixes were added to the 3.2.0 packages as soon as they were identified (May 19 and May 23, respectively), so they may already be fixed in your installation of Gallery Server Pro.

More details about the bug fixes are in this report.

Behavior changes

Remove confirmation message after drag and drop sorting

Drag and drop sorting was added in 3.2.0. When you finish dragging the thumbnail, the new position is sent to the server and a confirmation message is displayed. Some users found the confirmation message annoyingly repetitive, especially when you factor in the bug where the screen auto-scrolled to the top when the message disappeared. Although we fixed that bug in this release, we agree that the message is unnecessary, so we removed it.

Prevent UI template changes to the default template

This is a behavior change that might catch some of you by surprise. Starting with 3.2.1, you can no longer save changes to any UI template with the name ‘Default’, except for selecting which albums the template applies to. If you want to edit a template, first make a copy and apply your changes to that. There are two reasons for this change:

  1. Allow reverting to the default template – By forcing you to make your changes to copies, you always have a default template to revert to.
  2. Allow template upgrades – Newer versions of Gallery Server Pro routinely require modifications to one or more UI templates. This is typically done through a search and replace on a particular string. However, if a user has modified the template, the search may not find a match, causing the template to not be upgraded. This can leave the user with a broken gallery and no easy way to fix things. By preserving the integrity of the default templates, we can be assured they upgrade correctly during an upgrade. And if you are using a modified template, you can refer to the default template to identify changes and merge them with your custom template.

View the official feature change report for 3.2.1.

Thursday, May 29, 2014

Migrate your DNN gallery to 3.2

Back in March we announced there will be no further releases of the Gallery Server Pro DotNetNuke Module. Since that time a number of you have asked about migrating your DNN gallery to a stand-alone instance of Gallery Server Pro. Some of the data in the DNN gallery is specific to DNN, so we can’t use the built-in migration path. But a few days ago a customer running clockdoc.org hired me to migrate the data, so I was able to dig into the details about what was involved. It’s actually pretty easy so I thought I’d write up the steps so you can migrate your own DNN gallery.

As an alternative, you can hire me to do the migration. See the end for details.

  1. Start by logging in to your DNN gallery and turning off the auto sync feature if enabled (it’s on the Albums page in the site admin area). This prevents a sync from kicking off and deleting records before your new gallery is fully set up.

  2. Go to the Backup/Restore page and make a backup of your gallery data.

    If you aren’t using the user albums feature and your gallery has only a few users, uncheck the option Export user accounts before making the backup file. This option includes DNN roles like Translator (en-US) and Unverified Users, which you really don’t need in your new gallery. However, it also includes user profile data such as the user album assigned to each user, so you’ll need this data if you want to transfer the user albums.

    NOTE: I haven’t tested a DNN migration that includes the user accounts, so there may be unforeseen obstacles or it may not work at all. Let us know what you find.

  3. Install a new instance of the latest version of Gallery Server Pro using either SQL CE or SQL Server and configure an admin account.

  4. Copy the media files from your DNN gallery to the location you want to use in your new gallery. For example, the default media location is the gs\mediaobjects directory of the web application. If you have multiple galleries, you’ll have multiple locations.

  5. Log in to your new gallery and go to the Backup/Restore page. Restore the backup file you made in step 2. Once complete, DO NOT click anything until completing the following steps.

  6. In the database of your new gallery, manually delete all records in the GalleryControlSettings table. If using SQL Server, use a tool like SQL Server Management Studio. For SQL CE, use a tool like SQL Server Compact Toolbox.

  7. Manually delete all records from the GallerySettings table where SettingName=’EnableDotNetNukeSearch’ and SettingName=’PortalId’.

  8. In the GallerySettings table, look for the records where SettingName=’MediaObjectPath’. There will be at least two – one for the template gallery and one for your actual gallery. You can look in the Gallery table to figure out which gallery is the template gallery (it’s the one where IsTemplate=true).

    Update the one for the template gallery to something like ‘gs\mediaobjects’ – this is the default path that is used when you create a new gallery on the Manage galleries page.

    Update the path for your actual gallery to the place where you copied the media files earlier. If you have multiple galleries, update the path for each gallery. If you want, you can skip this step for now and instead do it on the Media Objects – General page, but you will get an application error if the gallery can’t find – or create – the path defined in the setting.

  9. Now navigate to your gallery in the browser. Because we emptied the GalleryControlSettings page, the gallery will assign the first non-template gallery to the default.aspx page. If this is incorrect, use the Manage galleries page to pick the right one. If you have multiple galleries, you can create additional pages and assign them to each gallery as needed.

  10. If you use the auto-sync feature, turn it back on.

That should complete the migration. Enjoy your new gallery and all the cool new features in v3!

If you don’t want to hassle with it yourself, hire me to do the migration. It is priced at four hours of custom work ($320). Contact me if you’re interested.

Wednesday, May 28, 2014

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.9, FFmpeg 2.2.2, and GhostScript 9.14.

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 gs914w32.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.

Friday, May 23, 2014

Tree bug fixed in latest build of 3.2.0

This afternoon we noticed an issue with using the jQuery jsTree widget in 3.2.0. This widget is used in several places in Gallery Server Pro – basically anywhere we need to display a tree of data we use jsTree.

The issue is that when you select all the children of a node, the parents are automatically selected as well. For example, you might want to create a role with all edit permissions but no admin privileges. This bug caused the Admin gallery and Admin site nodes to be selected when all the children were selected, with no way to de-select them:

treebug2

This is actually the intended behavior of the jsTree widget, as I suppose it is the behavior you want in most cases. But not us. You need to select the children while leaving the parent unchecked if you so choose. If you want to select the parent, fine, but it should be optional.

A couple months ago I tweaked the jsTree library to change this behavior to what we need in Gallery Server Pro. And all was well until I updated to the latest version of jsTree just before releasing 3.2.0. And I didn’t re-apply my changes. Thus a regression was born.

It was easy enough to fix, as I just had to put the changes back in the jsTree library. Tonight I updated the 3.2.0 builds to include this fix. To apply the fix to your own gallery, download the install or upgrade package and copy gs\script\lib.min.js and gs\script\debug\lib.js over your existing versions of those files. Once the fix is in place, you are able to select child nodes while leaving the parent unchecked:

treebug1

This bug actually justifies a point release of 3.2.1 which I will probably get out in the next week or two, but today is the start of a holiday weekend and I wanted to get the fix out as quickly as possible so you wouldn’t have to wait.

To sum up – if you are installing or upgrading, the fix is already in the download packages and you can ignore this post. If you updated to 3.2.0 on or before May 23, you should update the script files or apply 3.2.1 as soon as it is released.

Monday, May 19, 2014

Missing UI template update in 3.2.0 upgrade

Oops! Earlier today we noticed that the left pane template didn’t get updated when upgrading a gallery from one of the 3.X versions. Because of this, the left pane appears empty when viewed on a touchscreen device larger than 750 pixels, as seen here on a Nexus 7:

32fix0

This only affects users who upgraded their gallery to 3.2.0 in the last four days. In addition, regular monitors (non-touchscreen) don’t have an issue, and neither do mobile devices smaller than 750 pixels. But those of you using an iPad, Nexus 7/10, Surface, touchscreen laptops and similar devices will see an empty left pane.

What happened is that we forgot to tell the 3.2.0 migration code to update the JavaScript portion of the left pane template to use the new, improved touchscreen features we added in 3.2. The end result is that the script continues to use the 3.0/3.1 behavior of not rendering the album treeview when a touchscreen is detected.

The fix was easy enough, and the download files have already been updated, so any upgrades you perform from this point on include the latest templates. If you already migrated your gallery to 3.2, there is a quick edit you need to fix your UI template. Follow these steps:

  1. In the UI Templates screen in the site admin area, select the LeftPane gallery item. Then click the JavaScript tab. Delete the script as shown here:

    32fix1

  2. In its place paste the following text:

    // Render the left pane if it exists
    var $lp = $('#{{:Settings.LeftPaneClientId}}');

    if ($lp.length > 0) {
    $lp.html( $.render [ '{{:Settings.LeftPaneTmplName}}' ]( window.{{:Settings.ClientId}}.gspData ));

    It will look like this when you are done:

    32fix2

  3. Save your changes. Repeat the process for any custom left pane templates you’ve created, if any.

We will include this fix in the next update as well, so those of you who already upgraded to 3.2 but don’t apply the fix described here will still get the fixed template in the next release after 3.2.0.

Sorry about any inconvenience.