ERA Journal maintenance and IT

This page is meant to serve as a collection point for information on maintaining the Ethnobotany Research and Applications journal website, the Open Journal Systems PHP and MySQL scripts that run the journal, upgrades, and any errors that we've encountered in the past, so that future journal managers have an easier time of site maintenance.

Most of these actions require you to be logged into the site as a journal manager (http://www.erajournal.org/ojs/index.php/era/manager) or into our hosting service's (currently InMotionHosting.com) cpanel website at http://erajournal.org/cpanel. Han Lau, Will McClatchey, and Nat Bletter have the login and password for these sites.

Trouble shooting

General trouble shooting and assistance can be found at the OJS support forums at http://pkp.sfu.ca/support/forum

They are your friends, use it early and often, post any problems as soon as they happen. The OJS authors usually respond within a day or so.

InMotion has it's own support forum at http://forum.inmotionhosting.com/ where you can post questions as well, but these are only for more general website problems. It is more likely that errors are coming from within the OJS software. Inmotion support can be emailed at support@inmotionhosting.com or called at 888-321-4678 ext. 2, 24 hrs/day, but they are fairly useless and blame most of the problems on individual software or installs. Since we are on a shared server (i.e. several websites running from 1 physical machine and IP address), they cannot reset the MySQL or http servers/daemons for us individually.

Some errors seem to be intermittent, perhaps based on the load at different times of day on our server and the other websites hosted on the same server. We've seen some "DB Error: MySQL has gone away" errors that appear during the day in Hawaii, but not late at night (3 AM). It is unclear why our relatively low access journal would overload the servers.

File transfer

Files can be managed, downloaded, uploaded, and edited either via an FTP client logged into ftp://erajournal.org site with TLS/SSL encryption, or the site cpanel file manager https://secure63.inmotionhosting.com:2083/frontend/x3/filemanager/index.html?dirselect=webroot&domainselect=erajournal.org&dir=%2Fhome2%2Ferajou5%2Fpublic_html&showhidden=1

Upgrades

The best upgrade method seems to be the patch method where it looks at all the customized files you have and just puts in the changes that have been made in the code between versions. But a remote upgrade can be done as well with a lot more tinkering. Both methods are outlined below.

Before any upgrades,

1. back up the entire site by copying the entire public_html/ojs directory to a local disk and another offsite backup,
2. back up the mySQL database by downloading it from the cpanel backup manager:
3. https://secure63.inmotionhosting.com:2083/frontend/x3/backup/index.html (this link will only work if we are still on InMotion and on their same server #63, but can always be entered from the main cpanel website http://erajournal.org/cpanel)
4. as upgrades can often change the database structure so that reverting to previous versions is impossible without downgrading back to the previous database.
5. rename the old ojs folder to something with another informative name, like "ojs 2.2.0".
6. rename the "ojs down" folder to "ojs" which will put up a message that the site is temporarily under maintenance.

Upgrade

a. Patch method

This requires command line access which we do not have on our current provider, so the only way this could be accomplished is to do it on a local downloaded copy of journal site

1. Download the entire OJS directory to a local machine which you can run a patch program on (Mac command line or some PC GUI variants).
2. Run the patch program, pointing it at your local downloaded copy of the OJS, with the upgrade patches. This goes through each file and keeps all of our customizations, just adding in changes to the code between versions.
3. upload the patched OJS directory to another directory on the server such as ojs2.2.3 that people will not be able to stumble across while you test it.

b. Remote method

This does not require command line access, but a lot of individual modifications to files.

1. Proceed with the instructions in the OJS upgrade, uploading the new version into a temporary directory like "ojs2.2.3" where it can be tested before it goes live.
2. Once the upload is complete, COPY (do not move) the old files and public ojs directories (in this case from dir ojs 2.2.0) to the new directory.
3. We can only currently due the final OJS upgrade process through the web interface instead of the command line interface (CLI) since Inmotion does not give us CLI access. So first make sure the "Installed = Off" is set in the config.inc.php and then go to the base URL of the temp site (http://www.erajournal.org/ojs2.3.3/index.php in this case) and select the upgrade link, making sure to wait for this process to complete.
4. If successful, this should set the "Installed = On" in config.inc.php but check to be sure.
5. compare the old and new config.inc.php files from the one on the upgraded directory to the one in the local backup of the old system you've made. This can be done with the UNIX command "diff" on the command line (e.g. on a Mac or Linux) with something like
6. diff ojs_backup/config.inc.php ojs2.2.3/config.inc.php
7. or via a Tools/Compare Files... menu in MS Word, then double check to put in an specific ERA changes into the new config.inc.php via the ftp client or the cpanel file manager.
8. Our customizations (ERA History, Resources, Announcements pages )are in the locale/en_US/locale.xml, pages/misc, pages/about, templates/misc and templates/about directories so make sure any files in the old version that do not appear in the new version are uploaded, and do a diff as above on any current files in there to make sure our changes are added in. There is a whole section in the locale.xml file in the about, misc and that needs to be added that references text strings like
9. <message key="about.erahistory">ERA History</message>
10. <message key="about.eraphilosophy">ERA Guiding Philosophies</message>

These all must be patched into the upgraded locale.xml file, and optimally into all the languages we support if possible.

After upgrade

1. run through as many pages of the site as you can without doing anything that would change the database or the publication status of the articles (i.e. create new users, assign them as reviewers, send them review request emails, have them decline those reviews from the email they are sent, check the Resources and ERA History links).
2. Once you are confident things are correct, rename the current ojs directory back to "ojs down" and rename the new directory (e.g. "ojs2.2.3") to simply "ojs".
3. Keep an eye for the next week for any problems in the public_html/error_log and reported from users.

Config files

The hidden file public_html/.htaccess (notice the period before the name that is the UNIX symbol for hiding a file. Some FTP clients need the "Show invisible files" option turned on to be able to see these files):

Be VERY careful with the .htaccess file and any modifications as these can easily make the entire site inaccesible to users and scripts and cause OJS to return many errors or completely stop functioning.

public_html/php.ini controls much of how php in general runs on the site, such as memory size limits, timeouts, and other parameters

public_html/ojs/config.inc.php controls the parameters of OJS, many of which change during upgrades.

Most configuration file setting changes go into effect immediately, thought I've seen a few that take 30-60 min (for some server to reset normally?) to go into effect.

Transferring to new hosts/providers

The the entire journal site can be successfully copied over to another web hosting server with some careful tweaks. I've gotten it working on http://nadabrahma.org/ojs/index.php/era (a SustainableWebsites.com site) with the following steps:

1. Swap the ojs and "ojs down" directories so no one can make any changes to the current database while you are doing the swap.
2. Copy the current mysql database to your local drive by backing up in the host's cpanel backup page, e.g. https://erajournal.org:2083/frontend/x3/backup/index.html
3. Download a backup of the entire OJS directory, "ojs down", old versions of ojs, and php.ini from the current host.
4. Upload the OJS and php.ini files to the new host in the www or public_html directory (actually the same thing).
5. Create a new database on the mysql page of the new host and note the name for the new database (arbitrary, but make it informative). e.g. http://nadabrahma.org:2082/frontend/x3/sql/
6. Note if there is a different host name or address for the mysql database. Sometimes it defaults to the same host as our server (i.e. 'localhost') but sometimes the top of the mysql page will say something like:
   1. "Remote MySQL Host
   2. The mysql server's address is 192.168.2.7. When connecting to the mysql server you must specify this host."
7. Create and note a new user and password for the new database, add them to the previously created database, and give them all access privileges.
8. Upload the mysql database from your backup file in the backup cpanel page of the new host, e.g. http://nadabrahma.org:2082/frontend/x3/backup/index.html
9. Make sure the DB upload worked by checking the mysql page to see if the size is correct (this never registered correctly on SustainableWebsites for some reason, even though the DB seemed to work fine, so the next test may show it uploaded OK too)
10. Edit the ojs/config.inc.php file on the new server (either by a direct edit that some FTP clients allow, or edit your local copy and re-upload it) to put in the mysql host, database name, username, password, base_url, and any mail settings that may be different.
11. Fire up the new system at http://newhostname.com/ojs/index.php/era and test it extensively.
12. If all is well, change the MyDiscountDomains to point to the new host instead of the old one and hopefully no one will notice the move.

After some tweaking with the mysql settings it seemed to work smoothly, even sending email correctly, so we can relatively easily transfer over to another host.

Bandwidth and space seems to be our biggest issues/requirements with new hosts. Our bandwidth which is actually at 98 GB/month (!) for some reason which is well beyond what some hosts like http://SustainableWebsites.com allow (between 10-20 GB for the packages we were looking at), so we'd wind up paying about $40/month extra or $800/year on http:/sustainablehosting.com for the additional storage and bandwidth.

Sep 2009

Aug 2009

Jul 2009

Jun 2009

May 2009

Apr 2009

Mar 2009

Feb 2009

Jan 2009

Dec 2008

Nov 2008

Oct 2008

Sep 2008

The great crash of late 2009

On Aug 19, 20, or 21 something was changed on inmotionhostings servers, in one of our config files, or the MySQL database was corrupted in such a way that review request and response emails sent through OJS were sent but always caused a DB error to show up. This is documented in the support forum http://pkp.sfu.ca/support/forum/viewtopic.php?f=8&t=3981 and is copied here. It's not clear what finally solved this issue but probably a combination of time, fixing the .htaccess file back to it's default, and turning of the allow_envelope_sender option in the config.inc.php file, though since this has been an intermittent problem, it's hard to know what changes fixed which errors, though it seems like the envelope_sender, upgrading all the files at once, and time have healed most wounds!