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.

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.

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

  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.

• Custom theme

  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.

• Language files

  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

• Password encryption

  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.

• Display FAQ

  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.

• Outdated files

  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.

• Safe mode

  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.

• URI upload removed

  The URI upload feature has been removed from cpg1.4.x to cpg1.5.x, as it wasn't actually doing what many users thought that it would do: when using URI uploads people expected the file to remain at the URI that they entered into the upload form and not be transfered to the webspace where their Coppermine gallery resided on. Subsequently, they thought that they could safe webspace. This was a misconception and in fact just wishfull thinking: using URI uploads in cpg1.4.x, the file actually was uploaded to the Coppermine webspace no matter what.
  Therefore, the actual feature "URI upload" was removed in cpg1.5.x. However (depending on the operating system of your client) you can (ab)use the regular http upload form to accomplish a similar thing in cpg1.5.x: when entering the URL of a file accepted by Coppermine into the http upload form, the file will get downloaded to your client's temporary folder and then a regular http upload from your client to your server will be performed. This is not actually a feature built into coppermine, but rather a feature of your OS/browser and therefore it goes unsupported. However, there is no action required when performing the upgrade - this paragraph is just meant to inform you that the feature was dropped.

Upgrading from older versions of cpg1.5.x to the most recent version of cpg1.5.x

There are no additional steps to follow when upgrading from an older version of cpg1.5.x to the most recent version of that family. Just performing the basic instructions discussed above in Steps needed to perform when upgrading Coppermine (from any version) will be enough.

What it does

• 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.

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 safely 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 safely 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.