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.  To do so, as root run:
 cpan LWP::Authen::OAuth
* Download each of the Bazaar plugins you have installed as EPM files.
* Make a backup of your local configurations.

==Process==

We will move your existing eprints 3.3.12+ installation from <tt>/opt/eprints3/</tt> to <tt>/opt/eprints3.3</tt>, install eprints 3.4, then migrate your configurations into EPrints 3.4. 
<br>
'''as root'''
 apachectl stop
 cd /opt
 eprints3/bin/epindexer stop
 mv eprints3 eprints3.3

* Download EPrints 3.4 core and publication flavour tarball and install them from [http://files.eprints.org/ Files.eprints.org] with
 wget https://files.eprints.org/2305/4/eprints-3.4.0.tar.gz
 wget https://files.eprints.org/2305/5/eprints-3.4.0-flavours.tar.gz
'''as root'''
 cd /root
 tar xvzf eprints-3.4.0.tar.gz
 tar xvzf eprints-3.4.0-flavours.tar.gz

* Have a look to <tt>/root/eprints-3.4.0/INSTALL</tt> for some local adaption options.
'''as root'''
 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 <tt>/opt/eprints3</tt> are still owned by eprints user and belongs to eprints group, thus
'''as root'''
 chown -R eprints:eprints /opt/eprints3

* Create <tt>/opt/eprints3/archives/ARCHIVENAME/cfg/cfg.d/00_flavour.pl</tt> to set the appropriate flavour, typically 'pub', i.e. 
 echo "\$c->{flavour} = 'pub';" > /opt/eprints3/archives/ARCHIVENAME/cfg/cfg.d/00_flavour.pl

* create a symbolic link to <tt>default.xml</tt> 
 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.<br> The first <tt>diff</tt> below will identify all the files that are the same.  If so, delete the ones in <tt>archives/ARCHIVENAME/cfg/cfg.d/</tt>.  You almost certainly should not find any, as the files in <tt>flavours/pub_lib/cfg.d</tt> will at very least have updated copyright/licensing boilerplate.  <br>The second <tt>diff</tt> 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 <tt>archives/ARCHIVENAME/cfg/cfg.d/eprint_fields.pl</tt> with <tt>flavours/pub_lib/cfg/cfg.d/eprint_fields_pub.pl</tt>  maybe with the help of [http://diffuse.sourceforge.net/download_de.html ''diffuse''] to overcome this business easier:
** If these are different and fields are present in <tt>eprint_fields_pub.pl</tt> and not <tt>eprint_fields.pl</tt> or the definitions (e.g. type, options, etc.)  for the same field are different then:
**# Copy <tt>flavours/pub_lib/cfg.d/eprint_fields_pub.pl</tt> to their archive's <tt>cfg/cfg.d/</tt>
**# Modify the fields in their archive's <tt>cfg/cfg.d/eprint_fields_pub.pl</tt> where they have different definitions (e.g. type, options, etc.) to those in <tt>eprint_fields.pl</tt>
**# Remove all fields in their archive's <tt>cfg/cfg.d/eprint_fields.pl</tt> where they also occur in their archive's <tt>cfg/cfg.d/eprint_fields_pub.pl</tt>
** If there are only additional fields in <tt>archives/ARCHIVENAME/cfg/cfg.d/eprint_fields.pl</tt> then just do the last step.
** If the two files are identical then you need to do nothing.  However, this is extremly unlikely.

* Synchronise <tt>archives/ARCHIVENAME/cfg/cfg.d/epm.pl</tt> with <tt>ingredients/bazaar/cfg.d/epm.pl</tt>, i.e. remove <tt>archives/ARCHIVENAME/cfg/cfg.d/epm.pl</tt> in case of ''no'' local modifications.

* 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.  Using epadmin test is a good way of discovering which files need this doing, but below is a list of common files that should be temporarily moved, if they exist in your archive's <tt>cfg/cfg.d/</tt> directory:
 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 <tt>epadmin update</tt> 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 new Apache configuration and as root test (fixing any issues) and restart Apache after necessary site-specific adaption are done.
 /opt/eprints3/bin/generate_apacheconf --system --replace ARCHIVENAME
'''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, the epindexer into service and reload Apache
'''as root'''
 /opt/eprints3/bin/epindexer start
 apachectl graceful

* Finally, run <tt>generate_static</tt> to make sure all pages are regenerated with any changes to configuration.
  /opt/eprints3/bin/generate_static ARCHIVE_NAME

==Notes==
* 3.4 does not automatically update an archive's <tt>html/en/</tt> files. If there are any bugs with broken Javascript or unexpected CSS, try deleting the archives <tt>html/en/javascript/auto.js</tt> or <tt>html/en/style/auto.css</tt>.  Similarly if a static page cannot be changed try deleting it under the archive's <tt>html/en/</tt> 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;

[[Category:Upgrading]]