To me, those appear to be alterations for one particular user, many of which would be unacceptable to most other users. Given that, I think you'll just have to keep making the changes manually whenever there's a new skin version.

Most other users would not agree. They want the sharing capabilities.


Again, almost every other user expects the skin to produce fully responsive albums, viewable on anything from a phone to a desktop monitor.

The same goes for things like forcibly shortening descriptions. Users expect the skin to use the text they entered.

Would you really expect Laza to remove social media and mobiles from the things that the skin supports? If not, I'm not sure what the point of your post is.

I believe I have detected the flaw in your reasoning.

Don't worry. We still love you.

"Polluting" the code? It's some 0.1% of the whole page and is used only by social sites. I don't see the drama here.

#1: Compiled with the original Tiger code.
Size of all HTML files of this project: 4.76 MB Sample

#2: Compiled with the altered Tiger code.
Size of all HTML files of this project: 2.03 MB Sample

Laza, I don't want to argue with you, David, Jeff, or Rob. The idea for this post was to summarize a few things I've learned from you so that others might benefit from it. I wasn't trying to criticize in any way. I really appreciate jAlbum and Tiger and am happy to always find very competent help here in the forum. Please keep in mind that there are some jAlbum and Tiger users who may use the product in ways you developers can't even imagine.

For example, I use the option in the comments field to write a travel report, which contains a lot of HTML code. Some of these comments are several MB in size. It all makes sense to me, believe me. And that's why it makes sense (to me) not to write these comments in these fields in the final HTML file

Thanks, Markus

Edited by: MarkusD on 28 Mar 2025, 17:39

The skin could take a more selective approach to code generation, however, which would take care of some of MarkusD's objections, and it wouldn't complicate things for other users.

For example, if the user hasn't chosen any of the social media options, don't ever generate these lines of HTML - they're not required for anything else:

		<meta property="og:image" content="shareimage.jpg">
		<meta property="og:image:width" content="620">
		<meta property="og:image:height" content="465">
		<link rel="image_src" href="shareimage.jpg">
		<meta name="twitter:image" content="shareimage.jpg">
		<meta property="og:title" content="aa">
		<meta property="og:description" content="aa">
		<meta property="og:type" content="website">
		<meta name="twitter:title" content="aa">
		<meta name="twitter:card" content="summary_large_image">

The <meta name="description" content="aa"> entry is a little more complicated. For my skins, I finally decided that since the only purpose of that is for SEO, and most users don't care about SEO at all, I would leave it out by default. But if the user actually cares about SEO, he probably wants to enter his own text there, anyway, so I provide a one-line entry in the UI, buried on a Misc tab. It's a single entry for all index pages however - no folder-specific option.

(I take this to extremes - I don't generate the same res folder contents for every album. No metadata choices by the user? No "camera" icon in res. No external home page entry? No "external link" icon in res. Not using the masonry layout? No "Justified Gallery" javascript file in res. No complication for the user, but it is tougher for me to maintain.)

Jeff, I appreciate your research which make sense to me. Thanks, Markus