View source for Upgrading 3.3.12+ to 3.4

These instructions help you upgrade EPrints 3.3.12 (and newer version of EPrints 3.3) to EPrints 3.4 while keeping all your eprints, documents and local configuration changes.

It assumes your EPrints 3.3.12+ was installed using a tarball (tar.gz) file and installed in /opt/eprints3. The commands in these instructions assume Centos 7 OS and run as the eprints user, unless it stated to run as the root user.

=Upgrade from Tarball=

==Pre-upgrade==
* If you have local modifications to the core files (in /opt/eprints3/perl_lib), you may need to manually migrate your changes.
* If you use Twitter integration, use CPAN to install LWP::Authen::OAuth as this is no longer in perl_lib.
as root:
 cpan LWP::Authen::OAuth
* Download each of the Bazaar plugins you have installed as EPM files.
* Make a backup of your local configs.

==Process==

We will move your existing eprints 3.3.12+ installation from /opt/eprints3/ to /opt/eprints3.3, install eprints 3.4, then migrate your configurations into EPrints 3.4. 

as root:
 apachectl stop
 cd /opt
 mv eprints3 eprints3.3

* Download EPrints 3.4 core and publication flavour tarball and install them [http://files.eprints.org/ Files.eprints.org]
as root:
 cd /root
 tar xvzf eprints-3.4.0.tar.gz
 tar xvzf eprints-3.4.0-flavours.tar.gz
 cd eprints-3.4.0
 ./configure
 make install

* Move your current repository from 3.3 to 3.4
as root:
 cd /opt
 mv eprints3.3/archives/ARCHIVENAME eprints3/archives/
After moving, make sure all files inside /opt/eprints3 are still owned by eprints user and belongs to eprints group.

* In /opt/eprints3/archives/ARCHIVENAME/, create cfg/cfg.d/00_flavour.pl and set the appropriate flavour, typically 'pub':
 $c->{flavour} = 'pub';

* create a symbolic link to default.xml 
 cd /opt/eprints3/archives/ARCHIVENAME/cfg/templates/ (or /opt/eprints3/archives/ARCHIVENAME/cfg/lang/en/templates/
 ln -s default.xml default_internal.xml

* Audit each of their local config files against the pub_lib flavours config files.  The first Diff below will identify all the files that are the same.  If so delete the ones in archives/ARCHIVENAME/cfg/cfg.d/.  You almost certainly should not find any, as the files in flavours/pub_lib/cfg.d will at very least have updated copyright/licensing boilerplate.  The second diff will find where files exists in both directory are different.  Here they should be compared to see if the local differences are superficial (e.g. slightly different comments or spacing) and therefore can be removed.  Also the pub_lib flavour version may fix an outstanding bug or perform the required functionality more succinctly.  If this is the only change then the local archive version can be deleted otherwise the change should be incorporated in the local version.
 cd /opt/eprints3/
 diff -rs archives/ARCHIVENAME/cfg/cfg.d flavours/pub_lib/cfg.d | egrep '^Files .+ and .+ are identical$'
 diff -rq archives/ARCHIVENAME/cfg/cfg.d flavours/pub_lib/cfg.d | egrep '^Files .+ and .+ differ$'

* Compare archives/ARCHIVENAME/cfg/cfg.d/eprint_fields.pl with flavours/pub_lib/cfg/cfg.d/eprint_fields_pub.pl, 
** If these are different and fields are present in eprint_fields_pub.pl and not eprint_fields.pl or the definitions (e.g. type, options, etc.)  for the same field are different then:
**# Copy flavours/pub_lib/cfg.d/eprint_fields_pub.pl to their archive's cfg/cfg.d/
**# Modify the fields in their archive's cfg/cfg.d/eprint_fields_pub.pl where they have different definitions (e.g. type, options, etc.) to those in eprint_fields.pl
**# Remove all fields in their archive's cfg/cfg.d/eprint_fields.pl where they also occur in their archive's cfg/cfg.d/eprint_fields_pub.pl
** If there are only additional fields in archives/ARCHIVENAME/cfg/cfg.d/eprint_fields.pl then just do the last step.
** If the two files are identical then you need to nothing.  However, this is extremly unlikely.


* Ensure the following bazaar files are disabled by renaming to FILENAME.pl.disabled.  Once they have been reinstalled via the Bazaar then they can be moved back into place:
 mv z_orcid_support.pl z_orcid_support.pl.disabled
 mv zz_hefce_oa_fields.pl zz_hefce_oa_fields.pl.disabled
 mv zz_rioxx2.pl zz_rioxx2.pl.disabled
 mv z_meprints.pl z_meprints.pl.disabled 


* As the eprints user, run epadmin update to add any new fields that were not previously present (typically this is embargo_reason for documents and requester_email for request)
 /opt/eprints3/bin/epadmin update ARCHIVENAME

* Generate Apache configuration and as root test (fixing any issues) and restart Apache.
 /opt/eprints3/bin/generate_apacheconf --system --replace
as root:
 apachectl configtest
 apachectl restart

* Once confirming that EPrints is generally working.  Go to Admin->Bazaar then install the Bazaar plugins you downloaded from your 3.3 repository before starting the upgrade process.  This can be done by going to the Available tab in the Bazaar and strolling to the Upload section at the bottom.  Unfortunately, you cannot do a bulk upload, so will need to install each plugin in turn. 


* Move back the files you renamed to FILENAME.disabled earlier and reload Apache:
 apachectl graceful


* Finally, run generate statics to make sure all pages are regenerates with any changes to configuration.
  /opt/eprints3/bin/generate_static ARCHIVE_NAME

==Notes==
* 3.4 does not automatically update an archive's html/en/ files. If there are any bugs with broken Javascript or unexpected CSS, try deleting the archives html/en/javascript/auto.js or html/en/style/auto.css.  Similarly if a static page cannot be changed try deleting it under the archive's html/en/ or running generate_static.
* If some perl modules are giving out error message like: 
  Can't locate object method "new" via package "EPrints::Plugin::Event::PIRUS" at /opt/eprints3/bin/../perl_lib/EPrints/PluginFactory.pm line 276.
  Can't locate object method "new" via package "EPrints::Plugin::Screen::EPrint::Box::Tools::SUPER" at /opt/eprints3/site_lib/plugins/EPrints/Plugin/Screen/EPrint/Box/Tools.pm line 12.
It is because their parent module has not been initialised. This happens when the parent module lives in perl_lib, and the problem module live in elsewhere  e.g. parent module of PIRUS(Event.pm) is in perl_lib, while the PIRUS.pm is in pub_lib. 
Just need to "use" the parent module before the ISA line:
 use EPrints::Plugin::Event;