301

(3 replies, posted in Showkase Support)

It looks like the following <div> elements are not closed on your web page and this could potentially cause layout issues in some browsers.

<div id="outer">
<div id="wrapper">

This might be due to manual modifications you have made (all elements seem to be closed correctly when I generate a Juicebox gallery page under the Kosel theme in Showkase v1.7.0 myself).

Small changes may have been made to the layout of pages in Showkase v1.7.0 but a default Juicebox gallery under the Kosel theme in Showkase v1.7.0 will still fit within the browser window without any adjustment necessary (as long as site header text of the default font size is used).
I'm not sure what might have changed in your website between v1.6.1 and v1.7.0 to warrant a change to your 'External fit px' values, though.

I've just created sample Juicebox gallery pages under the Kosel theme in Showkase v1.6.1 and v1.7.0 using the default 'External fit px' value of zero and a custom value of -50.
With 'External fit px' being set to zero, both galleries (in v1.6.1 and v1.7.0) are exactly the same size in the browser window. (The galleries are both fully visible no matter what the height of hte browser window is.)
With 'External fit px' being set to -50, both galleries (in v1.6.1 and v1.7.0) are, again, exactly the same size in the browser window. (A similar 'External fit px' value gives the same results in both v1.6.1 and v1.7.0, at least in my own test sites.)
I've even tried uploading and using a site header logo (taller than the standard site header text) and the logo is displayed at the same size in both v1.6.1 and v1.7.0 (pushing the galleries down their respective pages by the same amount, resulting in equal 'External fit px' values being required).

Unfortunately, I really cannot explain why you have had to change your 'External fit px' values in v1.7.0 unless some custom modifications are coming into play or the unclosed elements on your web pages (see above) are somehow contributing to the issue.

302

(8 replies, posted in Showkase Support)

Can you show me an example of one of the paths you are referring to?

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/

If these changes are made to use this compression, will it be lost each time I add photos or make a change to the website or when there is an updated Showkase version?

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.

303

(8 replies, posted in Showkase Support)

On further investigation, it looks like your web server is using gzip compression for HTML files but not for CSS or JavaScript files (which is probably why Google's PageSpeed Insights report suggests using compression on your website). Try entering the absolute path to a CSS or JavaScript file on your website into this online checker.

Add the code provided on this web page (there are many other web sites that provide similar code) to your root directory's .htaccess file to enable gzip compression for CSS and JavaScript files (as well as HTML files).

That should hopefully speed things up a bit (though maybe not noticeably) and increase your speed score on the PageSpeed Insights report.

304

(8 replies, posted in Showkase Support)

I checked that site and yes it does appear that the gzip compression is already active. Not sure how that happened, but as long as it's advantageous I'm good with that.

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

Once again thank you the direction with this!

You're welcome!

305

(8 replies, posted in Showkase Support)

To be honest, I've never timed the loading of a Showkase site with and without gzip compression but anything that helps with loading times and is as quick and easy to set up as gzip compression is should probably be implemented. The time saved in downloading a compressed file (over its uncompressed version) will usually more than compensate for the time it takes for a client's browser to decompress the file so using gzip compression will almost always be preferable to not using it (at least for highly compressible content such as HTML).

There are several online gzip compression tests (try this one) which will check whether or not a website has gzip compression enabled. It looks like your website already uses gzip compression.

306

(8 replies, posted in Showkase Support)

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.

Optimize images

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.

Enable compression

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

Eliminate render-blocking JavaScript and CSS in above-the-fold content

Prioritize visible content

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.

Leverage browser caching

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.

Minify CSS

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.

Minify JavaScript

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.

You're welcome!
I'm glad that solved your problem.
Thank you for letting me know.

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.

309

(1 replies, posted in Showkase Support)

It would be great if you could post your suggestion over in the Feature Requests thread. (It is less likely to be overlooked by the developers there.) Thanks!

I'm not aware of anyone having tried to use a masonry layout in a Gallery Index Page. I think it might be quite difficult to achieve within Showkase but if anyone has successfully managed to do this, please share your solution here.

310

(6 replies, posted in Showkase Support)

You're welcome.

311

(6 replies, posted in Showkase Support)

The link is going to a dead link. Please send new link.

Sorry about the link. I've corrected it in the post above.

The one question I do have though, the "image title" and "alt tag" are designed to use the info (from the title) and be the same in both places?

The <img> tag used for SEO purposes in a Juicebox gallery will look something like this:

<img title="Image Title" alt="Image Caption" src="/showkase/gallery/images/image0001.jpg">

Both the Image Title and Image Caption are used in the SEO code's <img> tag and also in the gallery itself (if you choose to display the captions).
Unfortunately, there is no way to manually enter different text for the SEO code.

312

(6 replies, posted in Showkase Support)

If you are using a Juicebox or SimpleViewer gallery, be sure to select the 'Add SEO content' checkbox in the page's 'Lite Viewer Options' section (Juicebox) or the 'Standard Viewer Options' (SimpleViewer). (This option is selected by default.)

A ListViewer gallery already uses <img> tags with 'alt' attributes so there is no option to 'Add SEO content' for this gallery type as it will already be there.
(Ordinarily, <img> tags do not need to be included in the HTML code for Juicebox or SimpleViewer galleries as the images are displayed dynamically via JavaScript but the 'Add SEO content' option is there to include such code for SEO purpose.)

Please see the Juicebox Search Engine Optimization support section for further information. The specifics refer to JuiceboxBuilder-Pro but Showkase provides similar functionality.

When the 'Add SEO content' checkbox is selected, SEO content will be added to the gallery page in the form of <img> tags (one per gallery image).
In a Juicebox or SimpleViewer gallery, the image's 'Caption' (entered on the 'Images' tab) is used as the <img> tag's 'alt' attribute.
(The image's 'Title' is used as the <img> tag's 'alt' attribute in a ListViewer gallery.)

If you are just inserting an individual image via the Showkase editor, then you can add text for the <img> tag's in the pop-up window's 'Alternative Text' input box.

313

(11 replies, posted in Showkase Support)

@alfavite

As far as I am aware, favicons should display correctly when using a VPN or proxy (at least they do when I try the free VPN built into Opera of the KProxy Extension for Firefox).

When using your VPN or proxy, check to see if favicons for other sites are displayed correctly.
Also, check your own site's favicon to see if it displays correctly without using a VPN or proxy.

If your favicon is not being displayed as expected, then try adding a <link> tag in your 'basetheme.tpl' file (as I suggested in this post above).

Failing that, I would recommend that you contact your VPN service provider to see if they can help further. (It does not sound like an issue directly related to Showkase but rather a VPN/proxy/favicon issue.)

314

(4 replies, posted in Showkase Support)

Prior to this when it was on "Auto" the picture was cropped square when the phone was held vertically.

By default, the Splash Page uses the first image in the gallery and the image is scaled to fill (rather than fit within) the Splash Page and, as such, cropping may occur.
You can select a different image to use for your gallery's Splash Page (it does not even need to be a gallery image) via the splashImageUrl configuration option. You could perhaps use an image that is representative of your gallery as a whole and is more tolerant towards cropping when it is displayed in different viewport shapes.
(You could upload an image for your Splash Page to your Showkase 'Library' and then use its URL for the splashImageUrl.)

When the phone was held horizontally, the picture changed sizes as the page was scrolled up and down.

This sounds like it might be due to Showkase dynamically resizing the Splash Page image when the viewport size changes. (As you scroll up and down (in Mobile Safari on iOS at least), the browser toolbars can appear and disappear, resulting in a different viewport height. Showkase will adjust the gallery height when the viewport height changes (just like when a desktop browser window is resized).

I'm not understanding what other setting you may be suggesting for this scenario with the Splash Page for mobile devices?

I was really just suggesting that you might set showSplashPage="AUTO". You could then configure your Splash Page using the available Splash Page options.
The Splash Page itself will still be sized the same as the gallery (when no Splash Page is used) so you'll still have the same problem as before (space above and below in certain viewport shapes) but only with a single Splash Page image. (The gallery itself will be displayed on a page of its own when expanded from the Splash Page.) Maybe with a smaller 'External fit px' value (such as '-100', for example), the spacing on desktop monitors would be acceptable and you could find a suitable image for your Splash Page which would look OK on mobile devices until the gallery is expanded.

Currently I have the "External Fit px" set to -240. Also, would decreasing the logo height be helpful at all?

I'm not sure that this would help. The height of your logo does not change the height of the gallery. A logo with a large height will just push a gallery down the page (and this can be compensated for via the 'External fit px' option).

I think that using an 'External fit px' of around '-100', setting showSplashPage="AUTO" and choosing a suitable image for your Splash Page (one that will not suffer too much when dynamically cropped to fit various different viewport shapes) might be your best course of action.
With an an 'External fit px' of '-100', the space surrounding your gallery in desktop monitors should not be excessive and it should hopefully be a low enough value for a usable Splash Page on mobile devices.

315

(4 replies, posted in Showkase Support)

It's always going to be difficult to display a gallery of landscape-style images in both landscape and portrait-style viewports without any space surrounding the gallery in either, especially when Showkase has been designed to have the gallery fill the remainder of the page below the header.
Ordinarily, on small screen devices, Juicebox would display the Splash Page and, when the gallery is expanded to fill the viewport, the images are displayed as large as possible given the space available.
However, you've set showSplashPage="NEVER" so your gallery is displayed in your embedding page (rather than on its own expanded page).
In such a scenario, a compromise might be the easiest solution. Try to find an 'External fit px' value that works for mobile devices and does not result in too much space surrounding your images on desktop monitors (although perhaps a little more than you currently have).

The ideal solution would be to have your gallery's height be determined by the viewport width and the aspect ratio of your images.
However, this is not a regular scenario and it would not be easy to implement, especially within Showkase which has its own gallery sizing routine and any manual intervention might cause problems.
If you tried to modify the Showkase source, then the modification would apply to all galleries within your site (which, I guess, would not be what you want) and it would be very difficult to do.
If you edited just a single gallery's 'index.html' page, then the modification would be overwritten each time you republish your Showkase site.

You might like to take a look at these two Juicebox forum posts which deal with having a gallery height change depending on the image size and aspect ratio. They might point you in the right direction.
https://juicebox.net/forum/viewtopic.php?pid=7014#p7014
https://juicebox.net/forum/viewtopic.php?pid=9392#p9392

However, it would really not be easy to implement such a solution into Showkase and I'd recommend trying to find a compromise via the Showkase interface if at all possible, either by using a different value for 'External fix px' (one that is 'good' for both desktop and mobile devices rather than one that is 'great' for desktop but 'poor' for mobile devices) or perhaps by allowing the Splash Page to be used for mobile devices (by setting showSplashPage="AUTO").

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

[Query moved from Feature Requests forum to new thread.]

@saidn

Any custom code added to the 'showkase/_themes/base/pagetypes/layout.tpl' file will appear in all pages created by Showkase (whether they are password protected of not). Showkase uses this file as a base template for all pages.

Make sure that your custom code is in the 'layout.tpl' file and re-publish your site (just click the 'Publish' button) to re-generate your pages with your custom code.

If you then check the source of any of your web pages in your browser, you should see your custom code there.

If you continue to experience difficulties, please let me know and I will contact you via email (where you can send me details of how to access your password-protected web pages so that I can investigate further). Thank you.

318

(3 replies, posted in Showkase Support)

Thank you for the additional information.
Unfortunately, an error 500 is a rather generic error message generated by the web server (rather than an error message specifically displayed by Showkase) that can cover a multitude of problems.
Also, a lot has changed between v1.3.4 and the current version (v1.6.1) so I'm not sure what might be causing your problem. (Please see the Version History for a list of changes between version.)
However, here are a few things to check and try.

(1) Please try installing and running 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 clue as to the nature of the problem. (Also, there are troubleshooting tips in the link above.)

(2) Try contacting your web host to ask if they have made any changes recently or are currently experiencing any issues which might be contributing to your problem.

(3) Try running Showkase in debug mode to see if a more informative error message is displayed in the Showkase status bar when (or before) the problem occurs.
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);

Please note that the line number above refers to the current version of Showkase (v1.6.1).

(4) Try reinstalling Showkase following the upgrade instructions here using v1.6.1. Something may have happened during your initial upgrade attempt which resulted in corrupt files on your web server. Following the upgrade process should (as long as it is successful) replace all Showkase core files (whilst retaining all your existing pages and settings) so if you currently have any corrupt files, then this should fix them.

(5) Try installing a fresh Showkase v1.6.1 site (in a new subdirectory of its own so that it is completely self-contained and does not interfere with your existing site) to see if the problem happens with this new site. This should let us know whether or not the problem is unique to your original Showkase site.

Hopefully the suggestions above will help or at least point you in the right direction.
Please let me know how you get on and if you need any further assistance.

319

(4 replies, posted in Showkase Support)

Update for others experiencing similar symptoms:

The 'Pages' layout problem was caused by old or corrupt versions of the '/showkase/admin/css/all.css' and '/showkase/admin/css/bootstrap.min.css' files.
Replacing them with the stock versions from Showkase v1.6.1 resolved the problem.

320

(3 replies, posted in Showkase Support)

I've moved your post to a new thread to keep it separate from Vasily Iakovlev's problems in this thread.

Vasily's 'Pages' layout problem was caused by old or corrupt versions of the '/showkase/admin/css/all.css' and '/showkase/admin/css/bootstrap.min.css' files.
Replacing them with the stock versions from Showkase v1.6.1 resolved the problem.

i am getting the same error as the OP trying to upgrade from v1.3.4 to v1.6.1 (unable to publish the site).

Vasily was not actually unable to publish the site. There was just a warning regarding the PHP function set_time_limit() being disabled. Clicking through this message (it was just a warning, not an error) published the site successfully.

If you are seeing the same warning "Warning: set_time_limit() has been disabled for security reasons", then this is due to the set_time_limit() function being disabled in your PHP configuration settings.

As I mentioned in Vasily's thread, this is just a warning (not an error).
Showkase (since v1.3.4), makes use of set_time_limit() and if this PHP function has been disabled on your server, then there is nothing that can be done within Showkase to enable it.
However, unless your site is very large (and Showkase needs more than the default time limit to process everything), it may never actually become a problem. Just clicking through the warning message should publish your site fine.

If you do have a large site and you are unable to publish it successfully because of set_time_limit() being disabled, then I am surprised that reverting to v1.3.4 helps. (Versions prior to v1.3.4 do not use set_time_limit() so the default time limit will be used, just like in v1.6.1 with set_time_limit() disabled.)

In any case, if you would like remove the set_time_limit() warning, you'll need to enable this function in your PHP configuration settings. If you do not have access to change your PHP settings yourself, your web host should hopefully be able to help you out.

If you are getting any different messages when you try to publish your site (whether they are notices, warnings or errors), please let me know and I'll try to help further.
Thank you.

321

(4 replies, posted in Showkase Support)

But both of this problems have arisen after i tryed to update Showkase to lastest version.

I'm not sure what version of Showkase you upgraded from but Showkase has only been making use of it set_time_limit() since v1.3.4 so, if you have upgraded from a version prior to v1.3.4, then it is possible that set_time_limit() has always been disabled on your server but that you've not known about it until now. Please note that the message is just a warning (it is not an error) and it will not cause a problem unless Showkase has to process a very large site (which might take longer than the default time limit). You would know if this was a problem as there would be errors (not just a warning regarding the set_time_limit() function) when publishing your site.
There is nothing that can be done from within Showkase to enable set_time_limit() in your PHP settings. This has to be done at server level so if you do not have access to change your PHP settings yourself, your web host should hopefully be able to help you out.

I've sent you an email where you can forward me your FTP and Showkase login details.
Once I'm able to see the 'Pages' layout problem for myself, I should hopefully be able to help further.

322

(4 replies, posted in Showkase Support)

It looks like there are two issues here:
(1) The set_time_limit() warning
(2) The layout of the admin 'Pages' page

(1) It looks like your web host has disabled set_time_limit(). This is unlikely to cause any problems (unless you have a very large site with lots of images and your web server's default time limit is too short for Showkase to process everything when you re-publish, in which case you will not be able to increase the time limit). However, this may never actually cause you any real problems. (You could, however, ask your web host to enable set_time_limit() on your hosting account and see what they say.)

(2) Your 'Pages' page layout is set by CSS code in the 'showkase/admin/css/all.css' file. Please double-check that the 'all.css' file is present in its correct location on your web server and that it is not corrupt or incomplete.
Also, try clearing your browser's cache before reloading your 'Pages' page to see if this helps.
You could also try viewing your 'Pages' page in a different browser to see if this makes a difference.

If you continue to experience difficulties, I would be happy to help further but I'd really need access to your web server and Showkase site to check things out.
If you are agreeable to this, then please let me know and I'll send you an email address where you can forward me your FTP and Showkase login details.
Once I'm able to see the problem for myself, I should hopefully be able to determine the cause and propose a solution.
Thank you.

323

(11 replies, posted in Showkase Support)

You're welcome.
I'm glad that you've been able to resolve your problem.
Thank you for taking the time to let me know and for detailing the reason for the problem.
Hopefully it will help out any other users experiencing similar symptoms.

By the way, so far I have been extremely impressed with ShowKase.  It works perfectly for me and I love all the config options.  I also like that it doesn't break whenever there's a Wordpress update like my last web gallery experiment.

That's really great to hear! We're glad you're getting on well with Showkase!

324

(11 replies, posted in Showkase Support)

Thank you for the link to your Showkase site.
Your favicon displays OK in the browser tab when I view your Showkase site in Firefox 51.0.1 on my PC (and everything looks OK: your <link> tag is in place, your 'favicon.ico' file is in place and your <link> tag's 'href' attribute is correct).
Try completely clearing your browser's cache before reloading your web site. Hopefully this will resolve your problem.

325

(11 replies, posted in Showkase Support)

It looks like the line of code is in the correct place.
Here are a few things to check.

(1) After making the change to the 'basetheme.tpl' file and re-publishing your site, check the source of one of your Showkase pages in your browser to make sure that the code is present in the page.

(2) Check that the favicon file has been uploaded to your web server and ensure that the path to the favicon file (the 'href' attribute in the <link> tag) is correct.

(3) If your favicon is not an 'ico' file (and is perhaps a 'png' or a 'gif' file instead), then make sure that its file extension is correct and change the 'type' attribute in the <link> tag as appropriate:

<link rel="icon" href="http://example.com/favicon.ico" type="image/x-icon">
<link rel="icon" href="http://example.com/favicon.png" type="image/png">
<link rel="icon" href="http://example.com/favicon.gif" type="image/gif">

(4) Try using an absolute path (like in the examples in #3 above) instead of a relative path for the 'href' attribute in the <link> tag.

Hopefully these suggestions will help.
However, if you continue to experience difficulties, please post a link to your Showkase site so that I can take a look at things for myself and hopefully help further.
Thank you.