Thank you for posting your suggestion in the Showkase Feature Requests thread.
You could post it in the Juicebox Feature Requests thread, too, if you like (as it is perhaps more relevant to Juicebox than it is to Showkase itself).

You're welcome!

Please check your email. I have sent you a message.
Thank you.

In the meantime, I think I might have found the root of the problem.
Each Showkase page has its own folder in the Showkase root directory. Inside each page's folder is a file named 'page.xml'. (This file contains information about the page such as the page type.)
You should be able to view the 'page.xml' files directly in a browser. For example, here is the 'page.xml' file for one of the page's in our Live Demo: https://www.showkase.net/livedemo/about-page/page.xml
However, trying to view the 'page.xml' file for any of your own Showkase site's pages fails (with the browser showing just the folder's 'index.html' page instead), for example: http://renaldi.com/projects/page.xml

It looks like the 'page.xml' files are missing from your Showkase site (they may not have been transferred successfully to their new locations when you moved your site) and this may be the reason for the incorrect page types.
If the 'page.xml' files are present in the page folders, then please check that their permissions are not too restrictive. Default file permissions of 644 should be fine.

Try creating a new page (in your moved site) and see if a 'page.xml' file is created in the page's folder on your web server.
If a 'page.xml' file is created for the new page, then it looks like the problem might be that your site's existing 'page.xml' files were not transferred successfully when you moved your site.

Otherwise, if a 'page.xml' file is not created for the new page, then there may may some underlying issue on your server whereby Showkase is unable to create the 'page.xml' files in the page folders.
If this is the case, then try running Showkase in debug mode to see if any warning or error messages are displayed in the application's status bar which might help to pinpoint the cause of the problem.
Open your 'showkase/admin/settings/constants.php' file in a plain text editor and change line 12 from:

define('DEBUG', false);

... to:

define('DEBUG', true);

The line number above refers to the current version of Showkase (v1.7.0).

I hope this points you in the right direction.

Edit:
It might also be wise to install and run the Showkase Server Compatibility Test to check that your server has all the features Showkase needs.
Even if you ran the test before installing Showkase, please try again in case your web host has made any changes recently.
If any of the tests fail, then it might give us a further clue as to the nature of the problem. (Also, there are troubleshooting tips in the link above.)

That certainly seems strange.
It looks like all the pages have become clones of your gallery index page.

The first thing Id try is to re-publish your site (if you have not already done so) by just clicking the 'Publish' button.

The next thing I'd try is to go to 'System -> Repairs -> Repair' to rebuild the page records.

Hopefully one of these suggestions will help.

Otherwise, as long as you made a backup of your site before moving it, if the intention of the move was to allow your site to be accessible from your root directory, then you could maybe reinstate your backup (to the way things were before moving your site) and then just follow the 5 step instructions in the Showkase Home Page support section.

The Showkase root directory's 'index.php' file is used (to display the Showkase home page) only when the Showkase site is accessed via the root directory (without specifying an actual page name).
Every Showkase page has its own folder in the Showkase root directory (and an 'index.html' page inside the folder).
For example, a Showkase page named 'my_page' will be located here: http://www.example.com/showkase/my_page/index.html
However if the designated Showkase home page is 'my_page' and a visitor to your site goes to: http://www.example.com/showkase/
... then the 'index.php' page will be used to show the '/my_page/index.html' page.

That's really just an aside about the function of the root 'index.php' file. (Your tags should not go in this file).

If you want to have all your own <link> tags included on all your Showkase pages, then the best place to put them would be alongside the existing <link> tags in the /showkase/_themes/base/pagetypes/basetheme.tpl file.
Open the basetheme.tpl file in a plain text editor, scroll down to the {block "stylelinks"} section and add your own <link> tags alongside the other ones there.
All you now need to do is republish your site for all your own <link> tags to be added to all your Showkase pages.

I'm glad to hear that reverting to v1.6.1 has resolved your problem. Thank you for letting me know.
Unfortunately, I have been unable to reproduce the problem you are describing myself (which makes me think that some of your custom modifications might be contributing to the problem).

If anyone else is experiencing difficulties with 'External fit px' when upgrading from v1.6.1 to v1.7.0, please let me know so that I can try to reproduce the problem myself and notify the developers if necessary. Thank you.

Sure. Try entering either of the two paths below (an example of a CSS file and a JavaScript file on your website) into the online gzip compression checker and you'll see that gzip compression is not currently enabled on your web server for CSS or JavaScript files.
Sample CSS file path: https://djphoto.com/_themes/kosel/css/styles.css
Sample JavaScript file path: https://djphoto.com/_themes/base/js/jquery-min.js
Online gzip compression checker: https://www.giftofspeed.com/gzip-test/

Setting up gzip compression for your website is completely independent of Showkase. Making changes within the Showkase interface or to the Showkase source files will not change whether your website uses gzip compression or not. Using gzip compression is simply a way to minimize the filesize (via lossless compression) when content is passed from your web server to the user's browser (to save bandwidth and also time).

Add the following code to your root directory's .htaccess file and check the CSS and JavaScript files in the online gzip compression checker again.

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_include mime ^text/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_include handler ^cgi-script$
</ifModule>

You should find that gzip compression is now enabled for CSS and JavaScript files (as well as .htm, .html, .php and .pl files).
(Images are not included in the list of files as they are not as highly compressible as text files and generally do not benefit from gzip compression.)

I hope this helps to clarify things.

It's probably just set up on your web server by default (as it's generally a good idea).

You're welcome!

Google's PageSpeed Insights tool can certainly be very helpful but it is also useful to remember that the results are just Google's ideal recommendations for a perfect score which, in a real-world scenario, might not be easy to achieve or make a great deal of difference depending on the web page in question.

Here are a few notes on some of the recommendations.

You could make some of your images smaller in filesize by reducing their quality slightly. This would address this recommendation in the report and should increase the speed score. However, I notice that the images for your homepage's gallery are around 200KiB each and I personally do not think that this is excessive (knowing that Juicebox preloads images as required and does not load all gallery images at once). You are certainly best positioned to know whether you'd want to decrease the filesize of your images. You might be perfectly happy with the filesize and quality of your current images, in which case, you won't need to worry too much about this recommendation.

You could try enabling gzip compression on your web server. Please see this web page for details.

Your Juicebox gallery is above-the-fold and it is absolutely essential that the gallery's JavaScript and CSS files ('juicebox.js' and 'theme.css') are loaded as soon as possible so that the Juicebox gallery can be displayed. In fact, almost everything on your Showkase homepage is above-the-fold so all external resources need to be loaded before the above-the-fold will be rendered correctly. There's really nothing that can be deferred.

Knowing the content of your web page and what files are required for the above-the fold content to be rendered correctly, the two recommendations above can be put into context. They are not truly problems but necessities for the gallery (and, indeed, the layout of your web page) to be displayed correctly.

You could certainly set HTTP cache headers within an .htaccess file if you like. You could allow files to be cached by browsers rather than force browsers to always fetch files fresh from your web server (which is what I expect your web server currently does, being that this recommendation is in the 'should fix' section). Take a look at this web page for more information.

You could minify Showkase's CSS files (for example using an online CSS minifying tool) but I doubt that it would be a worthwhile venture. I genuinely think that the speed increase that it would give you would be minimal and it would have a couple of drawbacks: the CSS would no longer be easy to read (or, indeed, modify if necessary) and if or when you upgrade Showkase, all the CSS files would be overwritten with un-minified new versions and you'd need to repeat the process all over again.

Showkase already loads minified versions of the jQuery, Modernizr and Juicebox JavaScript files.
There is very little other JavaScript content that could be minified and if you tried to combine all the JavaScript into a single large file, you'd break Juicebox (and it would be difficult to do within Showkase).

I wouldn't worry too much about the tool's speed score. I would be more inclined to just load your website in a browser (which is what visitors to your website will be doing) and make sure that it loads within what you consider to be reasonable amount of time (and then perhaps address some issues if you really feel you need to). You'll likely have a good feel for whether you think your website's loading speed is acceptable or not. When I view your website in a browser, I reckon it loads pretty quickly. The tool just gives you some recommendations to maximize everything in an ideal scenario although, in many cases, not every recommendation is achievable. Don't get me wrong: the recommendations are useful but, even if they are achievable and increase your resulting speed score (by becoming green ticks instead of red crosses), I think the real-life speed increase in a Showkase site would barely be noticeable.

Showkase does not create hugely resource-heavy web pages. It loads only a few JavaScript and CSS files (I've seen some websites loading upwards of 50 JavaScript files and a similar number of CSS files) and, because of this, there is really no need to minify absolutely everything for the sake of a few milliseconds and at the expense of making the code very difficult to read and customize. Anything you do to reduce the number of recommendations in the report would likely be for little real-life gain.

Try entering a few other websites into the tool and you'll probably find similar speeds to that of your own website being reported.
I've just entered 'amazon.com' into the tool (as an example) and it scores similar speed scores to your own website. Being that Amazon probably want as many customers as possible, if the speed of their website was really an issue, I'm sure they would have addressed all the recommendations themselves.

At the end of the day, there are certainly a few things that you can do: check the filesize of your images, enable gzip compression on your server and allow browser caching. Anything else would be difficult to implement within Showkase.

However, I'd be happy that your website has a score of 100/100 for mobile friendliness and loads pretty quickly in real life.

I hope this goes some way to putting your mind at ease.

Edit:
On Google's own site, the full report is immediately available on-screen without needing to be emailed.
According to the report, minifying CSS on your homepage would save 9.6KiB and minifying JavaScript would save 4.2KiB. These are not huge savings that are going to make much of a difference.

It certainly sounds like a server or PHP related issue although it seems strange that you are left with blank page (with no error messages) and a working gallery. It sounds like the script is stopping short of completing the import (perhaps due to a script timeout) and, although the gallery is created, the entry is not written to the page records.

Does it happen with every gallery you import?
How many images are in the gallery you are importing?
Try importing a small gallery (with just 2 or 3 images) to see if it happens with this.

If it seems to happen only with large galleries, then you could perhaps try increasing your PHP max_execution_time directive (for the set_time_limit() function) to see if this helps. The default value is 30 (seconds) but try a value such as 300 (which is what Showkase attempts to use internally for certain functions, such as publishing, if max_execution_time is set to a lower value in the PHP settings). Increasing the max_execution_time in your PHP settings might help.

You should be able to check your PHP settings using phpinfo() as follows:

• Create a new file in a plain text editor with the following code: <?php phpinfo(); ?>

• Save the file with a .php file extension (for example, 'phpinfo.php').

• Upload the file to your web server and open it in a browser.

You should be able to change PHP values using a php.ini file, via an .htaccess file or via your web hosting online Control Panel.
If you have trouble changing any PHP values, your web host should be able to help you out.

Hopefully increasing max_execution_time will solve your problem.
However, if this does not help, then please let me know and I'll try to help further. Thank you.

Edit:
Incidentally, if you are not already using the latest version of Showkase, you might like to try upgrading to v1.6.1.
Instructions can be found on the Upgrading Showkase support page.

You're welcome.