full url for thumbnails

[fgravin]

Actually, the metadata xml files just contain the name of the thumbnail file, then an internal service retrieve the thumbnail.

If you harvest such metadata, you will lose the internal service then you won't be able to see the thumbnail.

The idea is to put in the MD xml file the full public url of the thumbnail, that can be accessed from everywhere.

ex: ​http://www.mycatalogue.com:8080/geonetwork/srv/eng/resources.get?uuid=3989dcf0-d816-11de-9242-000086f6a603&fname=rcp_s.png

The url will be build from the host and port values in settings table of the DB.

You can see the pull request : ​https://github.com/geonetwork/core-geonetwork/pull/15

[jesseeichar]

merged to both 2.8.x and master

[fgravin]

I noticed there were bugs on removing a thumbnail: it wasnt properly deleted on the disk. I've fixed another bug in the gui widget thumbnail form, which didnt pass the 'type' value correctly to the service.

You can find changes : ​https://github.com/geonetwork/core-geonetwork/pull/18

[fxp]

There is a hardcoded webappname (ie. geonetwork) in:

<xsl:variable name="serverHost"   select="/root/env/host" />
  <xsl:variable name="serverPort"   select="/root/env/port" />
  <xsl:variable name="serverPrefix" select="concat('http://',$serverHost,':',$serverPort,'/geonetwork/srv/eng/resources.get?')"/>

To be replaced by the current webappname.

[fgravin]

Hi,

I resolved this issue through the pull request ​https://github.com/geonetwork/core-geonetwork/pull/27

[ianwallen]

Closing as the pull request has been implemented - commit 51b15ef9d29a05398f7e99263dbb36c9e4ed5df5

[landry]

I think fixing that issue leads to re-breaking the fix from issue #950 - now all urls contain the full fqdn prefixed with ​http://, and the link sent to the widgets ui contain type='unknown' since contains($fileName ,':') in iso19139/present/metadata-iso19139.xsl line 3347 succeeds -> you get only a small thumbnail, and if you click on it you get the small thumbnail, not the large one.

Confirmed to be an issue with 2.8.0, upload a thumbnail, it gets assigned a full url, autogenerate the small one, in the search results clicking on the small thumbnail shows the small one instead of the large one.

[landry]

Hm, i was mistaken, the issue is in iso19139/index-fields.xsl instead, around lines 316 / 323. The lucene index stores type as unknown if the fileName contains a full url.

[landry]

I think i have a proper full fix to recover the original behaviour of showing the overview when clicking on the thumbnail, but so far it only works on the homepage and not in the search results view - Templates.js needs to be fixed to show {overview} in the lightbox, and MetadataResultsFastStore.js needs to figure out that what's returned by the /q service (munged by index-fields.xsl) is either a thumbnail or an overview.

[landry]

Fix thumb click -> overview display in lightbox

[landry]

A bit rough on the edges, but fixes the issue here :

• i'm not sure metadata-iso19139.xsl itself needs fixing, but for consistency with index-fields.xsl i applied the same method
• Templates.xsl change doesnt check if overview exists, since it'll default to the first image if no entry is found with 'overview' keyword (like it's done for the thumbnails, in fact)

Please review, comment and eventually commit to master & 2.8.x...

[landry]

Note that this doesnt fix the display for existing MD entries with relative paths (such as ../../srv/eng/resources.get?uuid=fe61ba70-e8c4-4cfe-a080-af4852f1ebe4&fname=VVA_dechet_s.png&access=public)

For that, the second case (when filename doesnt containt :) of index-fields.xsl would need fixing to return a image Field when fileDescr is large_thumbnail.

[landry]

And for some reason having two thumbs (one small, one large) will generate 4 entries with the xsl i've set in index-fields.xsl, once with the correct type and once with 'unknown' :

    <image>overview|http://ids-dev.craig.fr/geocat/srv/eng/resources.get?uuid=89976207-3ab7-42a9-b89c-aee199b2cf22&amp;fname=vignette-mntpuy.png</image>
    <image>thumbnail|http://ids-dev.craig.fr/geocat/srv/eng/resources.get?uuid=89976207-3ab7-42a9-b89c-aee199b2cf22&amp;fname=vignette-mntpuy_s.png</image>
    <image>unknown|http://ids-dev.craig.fr/geocat/srv/eng/resources.get?uuid=89976207-3ab7-42a9-b89c-aee199b2cf22&amp;fname=vignette-mntpuy.png</image>
    <image>unknown|http://ids-dev.craig.fr/geocat/srv/eng/resources.get?uuid=89976207-3ab7-42a9-b89c-aee199b2cf22&amp;fname=vignette-mntpuy_s.png</image>

Doesnt break the rendering by the extjs template, but still weird. I'm no xsl master.

[landry]

language-index-fields.xsl needs to be updated too. ​https://github.com/geonetwork/core-geonetwork/pull/77 has all the correct bits (hopefully)

[ianwallen]

Committed

Master f3dde5c05d6c0caea3a984eca63ccfecaf5912fb 2.8 Branch bbf70554a8651a05cec17dc1e7a0c4f633e38b6b