Is there a method to consolidate common files in one location on a server for several different domains if all of the domains are on the same server? I will need to have a different configuration for each domain (using configurator.html). I realize I may need to run the same version on all domains. The reason I ask is because I am on a shared Linux server and although the inode limit is sufficient at 200,000 nodes, an automatic backup to the online server is shut off if I exceed an inode limit of 50,000. I am at the threshold now. Of course I also backup everything to my local PC in case the online backup fails. A full restore from the online server takes less than 5 minutes whereas a restore from my local PC would most likely take many, many hours because of limited upload bandwidth.

Any suggestions?

Thanks,
Steve

Multiple sites can load the Floatbox files from the same location.

|--= 1 =--|
My preferred approach is the simplest. The floatbox css and js include lines can be identical across all sites. For example, aa.com and bb.com could both reference and load the Floatbox package installed on cc.com. This approach has only one instance of Floatbox to install and manage and makes doing version upgrades a snap. Multiple license keys can be installed in the one options.js file.

You mentioned the requirement to have different options.js files for each site. There are other ways to vary the option settings that are worth considering. You could use a variety of classOptions defined in the one options.js file and assign the desired classNames to the floatboxed elements on the various sites. Alternatively, you could move your site-specific options into fbPageOptions, fbClassOptions and/or fbTypeOptions on each page that uses Floatbox. You may wish to have a read of the "Configuring options" through to the "License key" sections of the Instructions for approaches and ideas.

|--= 2 =--|
There's another trickier approach which I'm not too enthusiastic about. Each site could contain a stripped down floatbox folder that holds only floatbox.js and options.js for that site. The rest of the floatbox folder could reside on a centralized server. Each page that loads floatbox would need fbPageOptions defined to tell Floatbox where to find its bits. My lack of enthusiasm for this setup is largely because of upgrade problems - every floatbox.js file must always match the release of the supporting files on the backend.

The approach just described is setup by have only floatbox.js and options.js in the floatbox folder of the individual sites. Then each page would have something like the following on it to load Floatbox:

<script>
fbPageOptions = {
    modulesPath: "http://cc.com/floatbox/modules/",
    graphicsPath: "http://cc.com/floatbox/graphics/",
    languagesPath: "http://cc.com/floatbox/languages/"
};
</script>
<link href="http://cc.com/floatbox/floatbox.css" rel="stylesheet" />
<script src="/floatbox/floatbox.js"></script>

In this setup, fbPageOptions must be defined on the page prior to floatbox.js being fetched.

|--= 3 =--|
If using Floatbox version 5.6.0 or later, we can be a little trickier as well and just leave options.js file on the individual sites. This gets rid of the problem of multiple copies of floatbox.js to manage during upgrades.

<script>
fbPageOptions = {
    installPath:  "/floatbox/",
    modulesPath: "http://cc.com/floatbox/modules/",
    graphicsPath: "http://cc.com/floatbox/graphics/",
    languagesPath: "http://cc.com/floatbox/languages/"
};
</script>
<link href="http://cc.com/floatbox/floatbox.css" rel="stylesheet" />
<script src="http://cc.com/floatbox/floatbox.js"></script>

The options.js file will be loaded based on the defined local installPath, while everything else comes from cc.com.


I think |--= 1 =--| is the winner, but you might be more attracted to complication than I am.

Thanks - I'm an advocate of simpler is better if I can obtain the same results. I have one question about multiple license keys. Is the format:

globalOptions: {
  licenseKey: "key1, key2, key3",          // Paste your license key between the quotes, or enter it in the configurator form.

or

globalOptions: {
  licenseKey: "key1","key2","key3",          // Paste your license key between the quotes, or enter it in the configurator form.

I suspect it's the former.

It's the former: just one string with the keys separated by commas or spaces. The latter is not valid javascript and the options.js file is a javascript file.

If you've got multiple registrations, you probably have access to the registration and key management page where you can generate the appropriate multi-key string to paste directly into the options.js licenseKey field.