# Coppermine Photo Gallery v1.5.x: Documentation and Manual

# Upgrading

Please note: as there have been changes both in the coppermine files and the database from previous versions to cpg1.5.x, users of older versions than cpg1.5.0 will have to apply all steps mentioned below: both the files have to be replaced and the update.php script has to be run once.

## Why upgrade?

There are major and minor releases of Coppermine. Major releases have so far been cpg1.0, cpg1.1, cpg1.2.x, cpg1.3.x and cpg1.4.x. The next major release will be cpg1.5.x (which currently is in the dev pipeline - no scheduled release date yet) - you're just reading the preliminary docs for cpg1.5.x. Minor releases (the third number in the version numbering scheme) represent updates, also known as "maintenance releases". Major releases contain new features (compared to the previous major release), minor releases do not contain new features, but only bug fixes and slight improvements (like additional language files).

To understand the release policy of the coppermine dev team you have to understand how bugs are being fixed: we maintain a repository where the core code of each major release is being constantly being improved. Major and minor bugs that are reported on the coppermine support board are being fixed in that repository. Once a new package is being bundled, all fixes that have been made in that repository go into the new maintenance release.

There is a good reason for every new maintenance release: they are usually being packaged when a new bug or vulnerability is being discovered that is relevant in terms of security. As suggested above, there are several minor bugfixes that go into each new release as well, not only the one major bug or vulnerability that lead to the maintenance release. Therefore, it will not be enough to just fix the single vulnerability that has been the initial reason for a new package to be released. Instead, always upgrade to the most recent stable release as soon as it has been announced.

### Reasons for package releases

This is a list of minor releases of cpg1.5.x and the reason why they have been released. It is meant to explain why you should upgrade as soon as possible to the most recent stable release if you are running an outdated version.

Details

Package | Reason for release | Release Date
--- | --- | ---
cpg1.5.2 | Beta release. First public release for testing and evaluation. Do not use for production! No support available yet. Announcement thread | 2009-11-16
cpg1.5.1 | Alpha release for testers and translators. This version is not a public release - it has only been released to a closed group of users for testing and translation purposes. | 2009-07-24
cpg1.5.0 | This version was never released as a package - the version number 1.5.0 was just reserved for the initial development stage of the cpg1.5.x series before the feature freeze stage started. There is no package available, nor has there ever been one - only Subversion checkouts have been possible. | Never

As you can see, the coppermine dev team is constantly fixing and improving coppermine. Every non-trivial piece of software contains bugs, so there is no guarantee that the version that currently is the most recent one will be the final, ultimately bug-free version to be released in the cpg1.5.x series. It is absolutely vital that you perform regular updates as soon as new packages are being released.

### Changelog

Details on the changes that went into a release can be found in the changelog that comes with each package. The changelog file can be found in the root directory of the coppermine package. The changelog contains more information on additional languages and the time and date of the fix as well.

The changelog is a plain-text file that can be read using a simple editor - on Windows-driven machines, notepad.exe is fine.

## Steps needed to perform when upgrading Coppermine (from any version)

The instructions here apply for all Coppermine udpates/upgrades, so please read them carefully.

- Download the most recent stable version existing in the download section of the official Coppermine homepage
  Don't assume that you have the most recent version, especially if you have installed Coppermine using a control panel app provided by your webhost. The coppermine dev team doesn't recommend using such auto-installers - please download the original from the official Coppermine homepage.
  If you're not sure what package to use (i.e. if there are several archive types), choose the zip archive, as Windows XP and better out of the box come with support for zip archives.
- Make a backup (dump) of your database
  Recommended tools for creating a database dump are mySqlDumper or phpMyAdmin - refer to the section Tools recommended by the devs: Database manipulation for details.
  Creating a backup is not mandatory in terms of functionality, but just a precaution in case anything should go wrong. It's advisable to make frequent backups anyway.
- Backup your include/config.inc.php file, your anycontent.php file and your "albums" directoy as a safety precaution if anything should go wrong.
  Usually, you just download your entire coppermine folder to your local hard drive or any other safe backup location using your FTP app. A fresh Coppermine package doesn't contain a config file anyway (that file has being created during install on your server), so you can't actually replace an existing config file with an empty one from the package; again, the backup is only a safety precaution.
- Unpack the coppermine package you downloaded
  Similar to fresh installs, you need to extract the packed archive into a temporary folder on your local hard drive (preserving the folder structure within the package). Most modern operating systems come with an unarchiver that is capable to extract zip archives.
- Except for the "albums" directory, upload all of the new files and directories, making sure not to overwrite your anycontent.php file or the albums directory.
  In fact, you could upload the albums folder as well - the one that is contained in the package is empty anyway. The recommendation not to upload this folder is only meant as a pre-caution for some users who have "funny" settings for their FTP apps: some exotic FTP applications delete folders existing on the server and then re-create an empty folder on the server-side. This would of course be a disaster, as you would lose all your uploaded files in your gallery. However, the number of FTP apps that is set up in that strange way is small and therefore, it won't hurt for most to upload the albums folder as well. If you're not sure, use one of the FTP clients recommended by the devs.
- Run the update script
  To run the PHP-file "`update.php`" (i.e. the update script), just enter the URL into the address bar of your browser. The file "`update.php`" resides in the coppermine directory, so to run it you will need to point your browser to `http://yourdomain.tld/your_coppermine_folder/update.php` (if you have installed Coppermine into the root of your web site, you will have to run `http://yourdomain.tld/update.php` accordingly). This will update your coppermine install by making all necessary changes in the database.
- If you have made a custom theme, apply the changes that were introduced in the themes structure to your custom-made theme
  Please refer to the theme-upgrade guide for details.

To make this absolutely clear:

there is no such thing as a separate upgrade package - coppermine always comes as a complete package that can be used both for a fresh install as well as an upgrade.

## Additional actions for updating from particular versions

Depending on the version you're updating from, there are additional actions you need to perform:

### Upgrading from version cpg1.0, cpg1.1, cpg1.2.x or cpg1.3.x to cpg1.5.x

Support for a direct upgrade from cpg1.0, cpg1.1, cpg1.2.x or cpg1.3.x to cpg1.5.x has been dropped - if you still have such an ancient version running, you will have to upgrade in a two-step-process (from your version to cpg1.4.x and then on to cpg1.5.x)

### Upgrading from cpg1.4.x to version cpg1.5.x

- Plugins made for cpg1.4.x usually can no longer be run on cpg1.5.x, so you'll need to turn them off while you're still running cpg1.4.x (before you start upgrading). Some features that have been a plugin for cpg1.4.x went into the core of cpg1.5.x, so you may not need your plugins any longer. The safest way to make sure that plugins don't interfere is by disabling all plugins using the corresponding config option and then removing the content of the plugin folder using your FTP app. After performing the upgrade, get the plugin versions designed for cpg1.5.x and upload them, then re-enable the new plugins one by one.
- If you have made a custom theme, apply the changes that were introduced in the themes structure to your custom-made theme - refer to the theme-upgrade guide.
- You can not use language files from older versions of Coppermine as primary language (the language the admin will use) - make sure you only have the language files that come with this package inside of your lang folder (delete or rename all files from older versions within the lang folder).
  If you need to use a language that hasn't been translated for cpg1.5.x, you can try using the language file from cpg1.4.x, however there are certain caveats:
  - cpg1.5.x-phrases that don't exist in your old language file will go untranslated or show in english
  - Coppermine can't be administered using an old language file - the admin needs to use a "true" cpg1.5.x language file
  - You're free to try using old language files, however when running into issues or error messages, switch to US-English and see if the issue goes away then. Using outdated language files goes unsupported
- In cpg1.3.x, the passwords for the users used to be stored in plain text inside the database. This has been changed in cpg1.4.x - out of the box, cpg1.4.x used to store the passwords encrypted. However, there used to be an option for those who upgraded from cpg1.3.x to cpg1.4.x to skip the step of encrypting the passwords. In cpg1.5.x, the plain-text storage of passwords is no longer an option. If you're running such an old gallery that first was updated from cpg1.3.x to cpg1.4.x and now on to cpg1.5.x, the updater will automatically encrypt all the passwords of your users (including your own admin account). You don't have to mind anything specifically - the updater will do this automatically.
- The option to display a FAQ page to end users (by ticking the corresponding config option) that existed in cpg1.3.x and cpg1.4.x has been removed from cpg1.5.x, because it was hardly every used and only caused additional workload for translators. If you belong to those few users who actually used the FAQ menu item in Coppermine's navigation menu, you can easily come up with a custom page that uses coppermine's header and footer and display your individual FAQ there.
- Delete the outdated files that came with older versions of coppermine that no longer exist in cpg1.5.x.
  Again, this is just a precaution to make sure that your new gallery doesn't contain flaws from outdated versions that would allow malevolent attackers to exploit weaknesses in older versions. To find out what files need to be removed manually, take a look at the output at the bottom of the update screen (`http://yourdomain.tld/your_coppermine_folder/update.php`) - the updater will attempt to delete the files for you, but in most server setups it won't have the permission to do so, so you will have to manually delete the files using your FTP app. Another way to find out about the files that need to be deleted is the versioncheck page - the files that are scheduled for removal will be displayed there as well - the versioncheck page won't attempt to delete those files though.
- If your webserver is running in safe_mode and you have enabled "SILLY_SAFE_MODE" in include/config.inc.php, you will have to go to coppermine's config after performing above mentioned steps and enable "silly safe mode" there, as the setting in `include/config.inc.php` is no longer being taken into account in cpg1.5.x. The silly_safe_mode setting has been turned into a config setting instead.

## The update script

The updater is a script that will update your database and delete leftover files from outdated versions that are no longer used in your version. It can be accessed by clicking on the corresponding link inside the admin menu or by entering the URL into the address bar of your browser.

You can run the updater by entering `http://yoursite.tld/your_coppermine_folder/update.php` into your browser's address bar.

### What it does

The updater performs three things:

- Check the authorization of the visitor who accesses the script
- Run the mysql database queries that reside in the file `sql/update.sql` (replacing the generic table prefix with the one you actually chose during initial install)
- Delete some files that used to reside inside coppermine's core in previous versions. The script only deletes unneeded files, but it doesn't touch your custom files, so there is absolutely no reason to be alarmed.
- Convert your passwords from plain text to encrypted: in older versions of coppermine there used to be an option to allow the passwords of your users to be stored in plain text within the database. In cpg1.5.x, plain text passwords are no longer supported. Therefore (if you don't already use encrypted passwords), the passwords in your database will be encrypted by the update script.

### Purpose

The updater will perform the database update for you after you manually have replaced the sql file it is using. The updater will not detect for you if there is a new version of coppermine available, nor will it download anything from the coppermine website. The level of automation is not that advanced in coppermine (yet).

To find out about new versions of coppermine or maintenance releases, check the news from coppermine-gallery.net.

### Authorization check

In Coppermine versions before cpg1.5.x, the update script used to be publicly accessible, e.g. everybody was able to run it. While this was good for support purposes (supporters were able to run the updater for users looking for help if it was obvious that they had not done so), there was a slight chance that this accessibility for everyone could at some stage be a security risk. That's why the dev team members decided to protect the updater from being run by any visitor who accesses it - starting with cpg1.5x you need to supply admin credentials. This can happen in four different ways:

- If you're already logged in as admin and run the updater from the link in coppermine's admin menu, the updater should run without further prompts for authentification - it uses the "regular" cookie-driven authentification that the entire coppermine script is using
- If you're not logged in as admin or if the coppermine core components no longer work without running the updater first (usually happens when upgrading major coppermine versions), you are prompted for credentials - enter the coppermine admin account details that you set up when installing coppermine in the first place
- If you can not remember your standalone coppermine admin credentials, you can supply your mysql credentials - you needed them when you installed coppermine in the first place. If you have forgotten them, read them up in the file that is used to store the mysql database connection details: download `include/config.inc.php` from your webserver to your client and then edit it with a plain text editor - you should see the mysql credentials in that file. If they have changed, your webhost should be able to help you retrieving them.
- If everything else fails, there is a toggle inside the code of the update script that you can use to skip authentification - to switch that toggle, download the update script (`update.php`) from your webserver to your client, find `// define('SKIP_AUTHENTICATION', true);` and replace with `define('SKIP_AUTHENTICATION', true);`. Safe your changes and upload the edited file to your webserver, overwriting the version that already resides on your server. Remember to restore the file as it was after having successfully performed the update.

### When must the updater be run?

You need to run the updater every time you upgrade/update, i.e. each time the file `sql/update.sql` is being replaced with a new version.

It doesn't hurt to run the updater several times in a row, so if you're in doubt, run it again.

## The version check tool

Since the release of cpg1.3.2 Coppermine comes with an additional version checking tool to help you resolve issues with upgrades and updates easily. To launch the versioncheck, simply add `versioncheck.php` to your browser's address bar after being logged into coppermine as admin (example: `http://yourdomain.tld/your_coppermine_folder/versioncheck.php`). With version 1.5.x, you can run the versioncheck utility from the Admin menu.

The versioncheck tool does not perform an actual update: it does not download newer versions of coppermine for you, nor does it install any fixes - it just is meant to make you aware of newer versions and help you to determine wether you performed an upgrade correctly.

### What it does

The script "versioncheck" is meant for two purposes:

- If you have upgraded from a previous version, you should perform versioncheck to see if your upgrade worked as expected
- Use versioncheck to make sure that your coppermine version is up-to-date

This script goes through the files on your webserver and tries to determine if the local file versions on your webserver are the identical to the ones at the repository of http://coppermine-gallery.net. Files that do not match are displayed and are the files you should update as well.

Compared to previous versions, the versioncheck page has been re-designed for cpg1.5.x both in terms of visuals as well as functionality.

### First run

When run for the first time, you will see the option screen first. For a start, default options should be OK, so just submit the form. The script will then determine the coppermine version you're currently running, an try to look up the XML file on the coppermine repository that corresponds to your version. If successfull, it will compare all files that exist on your server against the most recent files that are recommended to use (trying to obtain that data from the repository). Subsequently, you should see a list of folders and files that are supposed to exist on your server and an explanation if the file versions you have are the most recent. For details how to interpret the output, read on.

### Options

There is a small number of options available on the versioncheck page that should be pretty self-explanatory:

- #### Display output

  Determines wether the full output with formatting is used, or only a reduced plain-text output
  - Full-screen
    Use this by default. It will display as much detail as possible and has a nicer layout
  - Text-only
    If a supporter asks you to post your versioncheck-output, switch to this options, so you can easily copy the output and paste it into your posting on the coppermine support board. Only do so if a supporter explicitely asks for it! Another potential use for the text-only output is resources-consumption: if you suffer from time-outs, try using the plain-text option, as it consumes slightly less resources.

- #### Only show potential errors

  If you have no idea what all the output is supposed to mean or if a supporter asks for it, you might want to tick this option to only display the folders/files that have issues.

- #### Hide images

  When enabling this option, the many graphical resources that come with coppermine (i.e. all the icons and other images) are not being taken into account for display on the versioncheck page - a filter is being applied. Use this option to make the output less cluttered: images usually are not security-sensitive, so if you're only concerned about files that have an impact on security, you can savely hide the images.

- #### Don't check for modified files

  This filter will hide the column "modified" from being displayed and will result in a slightly less cluttered output. The check for modified files will not be performed when the script is being run. Only enable this option if you have performance issues with the script or if all your files are being reported as modified.

- #### Do not connect to the online repository

  If you check this option, the versioncheck script will not attempt to connect to the online repository and use the local XML file instead. Only use this option if connecting to the online repository doesn't work for you (e.g. if you're on an intranet and your server doesn't have internet access). The main drawback of not connecting to the online repository is the fact that you won't know about possible updates and most recent releases, so you better find the cause for your inability to connect to the online repository.
  During the development stage (between releases), the online repository usually is not being updated frequently, so only if you're using SVN checkouts (i.e. if you're a developer), you should tick this option.

The options screen lets you configure the versioncheck, or rather what is being displayed. The options aren't saved anywhere, so you will have to adjust them each time you run versioncheck. The default options should be OK for most users - only change them if you have good reasons to do so.

### Version comparison

There is a lot of information packed into a small space. Here's an example of a possible output and what the output means:

- #### Path

  The folder- and file name

- #### Missing

  If nothing is being displayed in this column, the folder/file exists on your server. If this is not the case (i.e. the folder/file does not exist on your server or is inaccessible), the column "Missing" will be populated with the result of this first, basic check.
  Note: there are some folders/files that are mandatory to have; others are optional. Anyway, if you perform a fresh install or upgrade, you should make sure to upload all folders/files. You can then later delete some of the optional files if you want, although this doesn't save much webspace.
  If a file is missing, all other steps that are next in the loop will not be performed - a missing file can't have a version number or similar. If versioncheck complains about missing files, use your FTP app to review if they are actually missing or inaccessible. If they are missing, re-upload them. If they are inaccessible, you will have to assign the needed permissions.
  Some files that existed in older versions might have gotten removed later. Those that might be a possible security issue will be displayed with the word "removed" in the "missing"-column. If you come across such a file, use your FTP-app to remove the file that versioncheck output complains about. Leaving the file where it is (ignoring the suggestion given by versioncheck) might pose a security risk and therefore is not recommended.

- #### Permissions

  Displays the permissions assigned to the folder/file. For some folders, write permissions are needed, while for others read permissions are enough. If the permission level of a folder is good, the result will be displayed together with a remark (in brackets) like "OK" (may differ in your language). Using a script like versioncheck to actually check permissions on folders works OK, while it may or may not work very well on files. This being said, you should mostly be concerned about folders that don't have sufficient permissions. If files are being reported to have an improper set of permissions assigned, don't be to alarmed if the rest of your gallery is working just fine.
  If permissions on folders need reviewing, read up the permissions section of the docs and do as suggested there.

- #### Version

  The version of the file on your server. If it is identical to the version indicated in the repository, you should see an "OK". If you're running an oudated version on your server you should get a fresh package and perform an upgrade.
  Note: folders don't have version numbers, nor do binary files (like graphics) have one, that's why the column "Version" displays "n/a" for folders and binary files. Only files that contain textual content can have a version number, so don't be alarmed by the many "n/a (OK)"-messages.

- #### Revision

  The revision of the file on your server. If it is identical to the revision indicated in the XML repository, you should see an "OK". If you're running an oudated revision on your server you should get a fresh package and perform an upgrade.
  Revisions are related to the versions - usually, if your version is OK, your revision should be OK as well. Only if you perform checkouts from the subversion repository, the revisions may "act up".
  The same thing that applies to version numbers applies to revisions as well: only textual files can have revision numbers - folders and binary files don't have a revision number.
  Confused? You don't have to: usually, you can savely ignore revisions - if you want to find out about what revisions are being used for, read the details on the subversion page.

- #### Modified

  If a file is accessible and the version and revision numbers match, the versioncheck script attempts to perform a check wether the file has been modified, compared to the original that comes with the coppermine package. This check is being performed by taking into account the MD5-hashes of the original file and your copy.
  When performing a fresh install or upgrade, there should be no modified files. If they are being displayed as modified, there are several possible reasons:
  - You deliberately modified the file (e.g. by applying a custom modification to it). In this case, it's OK to ignore the warning in the "Modified"-column and continue
  - Your file has not been transfered fully to the webserver. If this is the case, try to re-upload the file from your client to the server. If this doesn't help, your package might have gotten corrupt. Re-download a fresh one from the coppermine download section, un-archive it and re-upload the file. Make sure that your FTP app is configured to actually overwrite existing files
  - You have used an improper FTP-mode to transfer the file to your webserver. Using FTP apps, you can transfer files in binary or ASCII-mode. Most up-to-date FTP clients have a feature that will automatically select the proper FTP-mode for each file. If this is not the case, try the manual appoach and explicitely specify the FTP-mode for your file uploads.
  - Your webhost is injecting code into each file. Many free webspace providers (so-called "freehosts") do this to inject advertisments into your files. There's little you can do then except signing up with paid webhosting or ignoring the "Modified"-warning and hoping that things will work anyway.
  The output of the column "modified" can be filtered by enabling the option Don't check for modified files. This will result in a slightly increased performance of the versioncheck script.

- #### Comment

  The comment-column contains a short recommendation about what is supposedly wrong and what you should do to fix this. No comments usually means that everything is OK.

- #### Repository link

  The link to the SVN repository (web SVN) is meant as an additional feature for power-users and developers. Read the subversion repository instructions to find out more. If everything is fine, you don't have to worry about the link anyway.

### Things that could go wrong using versioncheck

As the actions performed by the versioncheck script are complex, there are several things that can go wrong, depending on your webserver setup:

- No connection to the online XML repository
  If your server resides behind a proxy or a web filter that requires authentication or doesn't have internet connection at all (e.g. on a company's intranet), the versioncheck script may not be able to connect to the online XML repository. Use the corresponding option to keep the script from trying. The caveats mentioned in the options section applies.
- I get a white page, or a page without actual content
  The script probably times out, as it consumes huge resources. You'll have to live without versioncheck then on your server setup, unless the server is yours to configure, so you can assign more memory and execution time to the script.
- I get an error message
  Error messages like `Fatal error: Maximum execution time of 60 seconds exceeded in /path/to/webroot/coppermine_folder/include/versioncheck.inc.php on line 276` are an indicator for the script consuming too many resources on your server. Try disabling some output options. If this doesn't help, you simply can not run the versioncheck script on your server.

Versioncheck is being provided as a courtesy to end users. As there are several factors that have an impact on it, it may or may not work on your server setup. If the versioncheck tool does nothing at all, this is probably the case for you - you don't have to be alarmed in this case: just make sure to keep your coppermine install up-to-date, preferably by enabling the config option "Display news from coppermine-gallery.net". Only if individual issues are being reported by the version check tool (i.e. only if some lines contain a remark in the comments column), you should be alarmed and take a closer look.

### Wrong expectations

To some this may sound trivial, for others it might be an important piece of information: naturally, files that you have not replaced during the upgrading process (e.g. `anycontent.php`) will show as outdated in versioncheck's output. This is of course to be expected. It doesn't hurt if you performed the upgrade exactly as suggested, as the files you're supposed to keep during that process don't actually contain code that needs updating. As an example, `anycontent.php` doesn't actually contain code at all (at least the file that comes with coppermine out of the box). It can contain custom code if you decide to use it. For details on the usage of `anycontent.php`, refer to the section "Using anycontent.php".

The versioncheck tool doesn't actually download newer file versions from the internet - it just checks the files you have on your server against a list of most recent files. The versioncheck tool doesn't check nor sanitize your site against hacking.

## Upgrading FAQ

- ### How do I find out about new Coppermine releases?

  There are various tools that allow you to stay up to date and make sure that you don't miss a release:
  - Leave the config setting "Display news from coppermine-gallery.net" enabled: this feature will alert you about news concerning releases and security issues on your coppermine-driven gallery. The news are only visible for you as admin, so your end users won't even notice.
  - Subscribe to the package on the sf.net project pages
  - Subscribe to the announcements board (by clicking on "notify" when being logged in). You will then get an email whenever a new posting is made on the announcement board.

- ### What's the difference between updating and upgrading?

  The words "update" and "upgrade" are often being used as synonyms. There is a slight difference though in the definition of the coppermine developers: upgrading usually means increasing the major version number, e.g. from cpg1.4.x to cpg1.5.x; while updating usually refers to minor version increases, e.g. maintenance releases from cpg1.5.x to cpg1.5.y.
  However, the usage is not that strict, so you might find places both in this document as well as other media (like the official coppermine forum) where the terms are being used the other way 'round. In fact, the words are pretty much synonyms as far as we're concerned.

## Downgrading from cpg1.5.x to an older version

CPG1.5.x incorporates many new features (compared to older versions), so we encourage all users to upgrade. However, there may be some who want to test cpg1.5.x and decide later that they want to go back to an older version. You have to keep in mind that a full upgrade changes the overall layout of coppermine's database that includes converting the encoding to unicode. This process can't be reverted: once you have done the conversion, the only way back is to restore a complete mySQL database dump (of course you have to create this backup before you upgraded in the first place). Creating mySQL dumps (backups) is recommended anyway, so you should do so now.

To make this absolutely clear: you can only downgrade if you used to have cpg1.4.x before and upgraded this version to cpg1.5.x. If you have made a fresh install of cpg1.5.x, you can not downgrade at all!

To actually perform the downgrade, replace all cpg1.5.x files on your server with the files from the older version (as if you were doing an upgrade, see above). Then restore your database dump that you must have made before upgrading. If you don't have a database dump (backup), you can't go back!