EPrints 3.4

The latest EPrints 3.4 is publicly available.

Builds can be found at  files.eprints.org/2789/

Or see the very latest code on github.com/eprints/eprints3.4.

A technical guide on how to upgrade from 3.3 to 3.4 is here.

For more information contact us.

eprints 3.4 poster

Changes in 3.4 include

Slimmer core code

Publication repository specific code has been moved out of the core, and into its own ‘flavour’.
This leaves the core smaller and more maintainable, as well as no longer being as biased to a traditional publications repositories.

Flavour support

Each EPrints repository is now a particular ‘flavour’.
Having moved the publications specifics into its own package, when a new repository is created, one of the installed flavours is specified. This can initially be ‘publication’ or ‘zero’, where zero is the minimal set up for creating a simple repository.
Other flavours have been created, based on zero. Such as research data, open education, research impact.

Ingredient support

Similar to flavours in structure, an ingredient is an installable library of code which represents a useful and reusable feature. For example bazaar support, which some but not all flavours will need.
These ingredients are specified at a flavour level. The publication flavour naturally uses the bazaar ingredient, but zero does not.

New features

  • Multiple repository support – while you have always been able to install several repositories on the same EPrints installation, you needed to be careful about local changes to one repository affecting the others. This was mostly due to limitations with mod_perl.
    There is now an option to further isolate the repository configurations if needed.
  • Google Scholar support – to better support Google Scholar indexing the repositories, the default URL for an EPrint record is now the same as its URI, the previous URL is also supported via a redirect.
  • Workflows – many fields in a workflow can now be set as ‘read only’, rather than risking them be altered by mistake, or omitted and causing the user confusion.
  • Filtering – a set of optional callbacks can now be used to decide if a given page is accessible to a user, or if in fact a user must log in to access it. Similar callbacks can also be used to filter search results before they are rendered, meaning a user can only then see pages they can then access.

Fixes – many other changes have been made, eg improved 404 handling. As well as a round of core fixes to both 3.3.15 and 3.4.