search

omeka / omeka-s

Omeka S is a web publication system for universities, galleries, libraries, archives, and museums. It consists of a local network of independently curated exhibits sharing a collaboratively built pool of items, media, and their metadata.
GNU General Public License v3.0
410 stars 138 forks source link

Use internal assets #365

Closed Daniel-KM closed 9 years ago

Daniel-KM commented 9 years ago

Hi,

I'm just testing Omeka-S and it works fine, but it's impossible in a plane: it requires external libraries (google fonts, jquery...)... Could you modify the install process to download them during it and/or add an option "useInternalAssets" like in Omeka 2? This is important for privacy purpose too. Thanks.

Sincerely,

Daniel Berthereau Infodoc & Knowledge management

zerocrates commented 9 years ago

Something closer to the Omeka 2-style switch is more likely, but yeah we'll look into this. Always good to have that option for both philosophical and practical reasons for some users.

Thanks for the feedback.

zerocrates commented 9 years ago

Implementation note:

We probably want to have this configured by a simple config file switch a la Omeka 2, but we don't want to do anything else about it in the style of Omeka 2 (in this case, that means the hardcoded set of things that useInternalAssets controlled).

The simplest nicer solution is probably a map in merged module configuration somewhere, with a structure like (with the top-level key subject to change, of course):

'asset_urls' => array(
    'ModuleName' => array(
        'path/to/asset.whatever' => 'CDN url'
    )
)

The views would refer to everything by the "local" asset path, as currently passed to the assetUrl helper. If the config flag is set to use internal assets, we just use that local path unchanged. If the flag is set to allow external/CDN assets, we look up in the map to see if the asset we're using is in there, and if it is we use the specified URL instead, rather than looking for a local asset.

A setup like this would both be easier for us to maintain as we advance in versions of things like jQuery, and it would also make it possible for modules to use the same system, and even for local administrators to override our choices of CDN with theirs on a file-by-file basis, all without editing any of the code.

zerocrates commented 9 years ago

There's some ongoing work for determining what things we'll want to have local/CDN for, but the basic feature here is done.