EPrints Technical Mailing List Archive
See the EPrints wiki for instructions on how to join this mailing list and related information.
Message: #01468
< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First
[EP-tech] Re: migrating customised code when upgrading 3.1.0 -> 3.3.10
- To: "'eprints-tech@ecs.soton.ac.uk'" <eprints-tech@ecs.soton.ac.uk>
- Subject: [EP-tech] Re: migrating customised code when upgrading 3.1.0 -> 3.3.10
- From: John Salter <J.Salter@leeds.ac.uk>
- Date: Tue, 22 Jan 2013 11:08:01 +0000
Matt, You may also want to consider how the nonvisible documents appear in the export plugins. If you look in the <head> section of an abstract page, you may find things aren't as 'hidden' as you first thought... I'm just going through the same thing (we have 'hidden' documents - which shouldn't be seen anywhere other than the workflow - by the depositing user and the admins). Currently (3.1.1) I've added lines to plugin/Export/ files to make sure references to 'hidden' files don't appear. Cheers, John -----Original Message----- From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Tim Brody Sent: 22 January 2013 10:10 To: eprints-tech@ecs.soton.ac.uk Subject: [EP-tech] Re: migrating customised code when upgrading 3.1.0 -> 3.3.10 On Tue, 2013-01-22 at 13:05 +1100, Matthew Brady wrote: > In previous versions (3.1.x), there used to be a line in the > file /opt/eprints3/archives/<repoid>/cfg/cfg.d/eprint_render.pl > > > > my @documents = $eprint->get_all_documents(); > > > > Which could be replaced to allow supporting documents etc., related to > the eprint item, to be stored but not made visible on abstract pages > etc.. > > my @documents = (); > foreach my $doc ( $eprint->get_all_documents() ) > { > next if $doc->get_value( "security" ) eq "nonvisible"; > push @documents, $doc; > } > > > > Does anyone know of a way to do this in 3.3.10? Hi, get_all_documents() has never changed but rendering has been moved into the XML, which allows you to customise the abstract page without having to hack in Perl. NB that doesn't mean you have to use XML, you can still do your rendering in Perl and pass it as a fragment to the XML. So from this (in citations/eprint/summary_page.xml): <epc:foreach expr="$docs" iterator="doc"> <epc:print expr="$doc.citation('eprint_page', 'eprint', $item)" /> </epc:foreach> To this: <epc:foreach expr="$docs" iterator="doc"> <epc:if test="$doc.security != 'nonvisible'"> <epc:print expr="$doc.citation('eprint_page', 'eprint', $item)" /> </epc:if> </epc:foreach> ? -- All the best, Tim
- References:
- [EP-tech] migrating customised code when upgrading 3.1.0 -> 3.3.10
- From: Matthew Brady <Matthew.Brady@usq.edu.au>
- [EP-tech] Re: migrating customised code when upgrading 3.1.0 -> 3.3.10
- From: Tim Brody <tdb2@ecs.soton.ac.uk>
- [EP-tech] migrating customised code when upgrading 3.1.0 -> 3.3.10
- Prev by Date: [EP-tech] Eprints 3.1 to 3.3 upgrade not working
- Next by Date: [EP-tech] Re: EPrints REST API documentation
- Previous by thread: [EP-tech] Re: migrating customised code when upgrading 3.1.0 -> 3.3.10
- Next by thread: [EP-tech] Re: migrating customised code when upgrading 3.1.0 -> 3.3.10
- Index(es):