Hi Jacob, hmm, I think there are a few things going on here...
1. I've figured out that the configuration properties for altmetric aren't
being loaded properly by Mirage -- that's fixed with a pretty easy PR and
wouldn't be hard to patch your instance. (just replacing things like
confman:getProperty("altmetrics",
"altmetric.enabled") with confman:getProperty("altmetric.enabled") )
2. Further, the variables relied on to get identifiers ($identifier_handle
and $identifier_doi) are not being created properly in global-variables.xsl
because it doesn't have access to item metadata in that context. I think
the best thing to do for this is for us to create these variables in
somewhere like item-view.xsl which has access to all the item metadata.
3. A couple of extra issues with $identifier_handle -- it's looking in a
field called dc.identifier.handle which doesn't exist by default (most of
us use dc.identifier.uri) and isn't reading the altmetrics.field config
property to see which field you've actually told the altmetric badge to
use. Also, for handles, altmetric expects just the prefix/identifier in the
"data-handle" attribute, not the full URI so we'll have to try and strip
that out too (ie. yours should be passed as 10133/3376) when creating the
$identifier_handle variable
I'll keep testing (I have managed to get the badge displaying properly when
I fix the config property stuff and hardcode your handle instead of relying
on the variables) but I think best steps are: I'll submit a PR to fix the
config issues, I'll figure out where and best DRI path to access identifier
metadata is for variables to use with altmetric/plum badges, tell said
variable to look at altmetrics.field to make sure it is looking in the
right field, and if it's expecting a handle, strip out everything before
the prefix.
4. You might have trouble loading the JS in on your site anyway, based on
something else I saw:
The browsers I try are blocking jquery from being loaded because it's
trying to load from the Google CDN with http:// whereas your site is secure
under https://
(most modern browsers will now block this kind of mixed/insecure content
loading)
XMLUI does attempt to compile the correct scheme (http or https) into the
URL for javascript loading
(see
https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-xmlui/src/main/webapp/themes/Mirage/lib/xsl/core/page-structure.xsl)
so I think XMLUI must think that your base URL starts with http:// and not
https://
One reason for this could be that your site is sitting behind some
frontends/appliances which handle the SSL endpoint and then offload traffic
to your backend application servers running on http:// -- does this sound
like it could be the case? If so, the fix might be as simple as finding the
line in page-structure.xsl that compiles the javascript script element:
<script type="text/javascript" src="{concat($scheme,
'ajax.googleapis.com/ajax/libs/jquery/', $jqueryVersion ,'/jquery.min.js')}"
> </script>
...and tell it to just use relative scheme regardless, eg.
<script type="text/javascript"
src="{concat('//ajax.googleapis.com/ajax/libs/jquery/',
$jqueryVersion ,'/jquery.min.js')}"> </script>
The plain "//" will look at what the browser sees rather than what XMLUI
thinks is your base scheme, so it should load jquery securely.
Now that's not directly related to altmetric but the altmetric JS is loaded
in the same way:
<script type="text/javascript" src="{concat($scheme,
'd1bxh8uas1mnw7.cloudfront.net/assets/embed.js')}">
</script>So if you have to keep your xmlui base URL as http:// in your
DSpace config but serve it over https:// you can force this to also use a
relative scheme like:
<script type="text/javascript" src="
{concat(,'//d1bxh8uas1mnw7.cloudfront.net/assets/embed.js')}">
</script>
I wonder if we should think about forcing $scheme everywhere to be '//'
instead of trying to figure it out from config -- I think that might break
compatibility with some older IE versions, but not sure if I'm remembering
correctly.
Hope this helps! Will let you know what else I figure out and if anyone
reading this can chip in with a good place/full DRI path to get the
identifiers out and into a variable, that'd be great, my XMLUI has gotten
rusty and
./mets:dmdSec/mets:mdWrap[@OTHERMDTYPE='DIM']/mets:xmlData/dim:dim/dim:field[@element='identifier'][@qualifier='uri']
for
instance doesn't grab it...
Cheers
Kim
On Thursday, January 19, 2017 at 6:50:41 AM UTC+13, jacob.cameron wrote:
>
> Hello Everyone,
>
>
>
> We are running DSpace 6.0 with Postgres and Tomcat.
>
>
>
> I’ve enabled Altmetrics in the altmetrics.cfg, we are being being tracked
> by Altmetrics and have ports 80 and 443 open to http://api.altmetric.com
> but stats are not showing up for items that have stats on our DSpace
> instance. (https://www.altmetric.com/details/9020018,
> http://hdl.handle.net/10133/3376)
>
>
>
> Any suggestions on how what to look at next? I’ve checked the
> item-view.xsl and all of the proper code appears to be there for getting
> Altmetrics to display.
>
>
>
> Jake
>
>
>
> --
>
> Jake Cameron, BCS(UNB)
>
> Systems Support Specialist III
>
> Information Systems and Technical Services University of Lethbridge Library
>
> Phone:(403)329-2756
>
>
>
> This e-mail, including any and all attachments, is only for the use of the
> intended recipient(s) and may contain information that is confidential or
> privileged. If you are not the intended recipient, you are advised that any
> dissemination, copying or other use of this e-mail is prohibited. Please
> notify the sender of the error in communication by return e-mail and
> destroy all copies of this e-mail. Thank you.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.
