Paloose configuration is done through a single file. This file can be called anything (in the current sites case it is paloose-ini.php in the root directory of the site). If you wish to change the name then this change must be reflected in the .htaccess file, We will look at this in more detail below.
This configuration information is only applicable to Paloose versions after 1.5.0. Earlier versions are no longer supported and are deprecated.
Configuration is basically a question of telling Paloose where everything is. There are a set of constant definitions which need setting for correct operation. If you leave them commented out Paloose will assign defaults, (see the lib/Paloose.php file to see default values.
The following definitions can all be changed if required. The values shown below are those that I use in the Paloose site.
Change the PALOOSE_DIRECTORY address here to indicate where you have put the main Paloose folder. It can be relative to your application site folder. It is possible to change between different versions of Paloose merely my changing this line.
Where the main log4php logger configuration file is kept. You can use Paloose pseudo protocols here. In the example below the log file configuration file is in user's site in the sub-directory "configs/". Now that the logging code is separate from the main Paloose code the constant LOG4PHP_DIR points to where the root of the log4php code is held (relative to the site path).
This is where the Paloose caches are held. It does not include the images cache directory. Paths are relative to the base directory of the Web site — where the paloose.php file is in your project. Make sure that this directory has the correct permissions — probably safe to allow write to all. In the following the cache is held relative to the Web site root.
Normally should not have to change this. The directory is always the top level user directory. The site root directory is the location of your sites file and where the root sitemap sites (as well the configuration file that you are looking at).
The error page to give back for User errors (errors in sitemap etc). They are not run time errors (such as missing page, 404). If you override these to your area make sure that you use an absolute directory path — you can use the 'context://' pseudo-protocol here.
Be careful of the path for USER_EXCEPTION_STYLE — it looks like an absolute one, but is actually relative to the Apache root document directory. It must always have a leading path separator.
The file that contains the gallery information in each gallery directory. See the examples page on the gallery for more information. The ImageMagick directory is there if the PATH on the server is not set to pick up correct ImageMagick binaries.
The error page to give back for internal (programming) errors (errors in sitemap etc). These should not need to be overridden.
Be careful of the path for INTERNAL_EXCEPTION_STYLE — it looks like an absolute one, but is actually relative to the Apache root document directory. Must always have a leading path separator.
The following definitions should not be changed unless you have a really good reason and are interested in Paloose deep-magic.
This should not need to be changed unless you plan to use another sitemap schema or want to change the source writing and directory results (DirectoryGenerator).
Change these with caution — they should only be changed for a different translation mechanism. It requires deep understanding of Paloose internals.
Only change this if you want to replace the current page hit mechanism.
This is the Paloose namespace that will never need to change unless there is a very good reason — subtext for, it won't change.
Definitely do not change these lines unless you really, really know what you are doing. Users of versions 1.40 and earlier will note this as the most significant change in how Paloose is called.